简介这份PDF文档面向计算机、电子信息及人工智能相关专业的毕业设计学生提供一篇基于深度学习的水果图像识别系统论文范文可用于选题参考、论文结构梳理与答辩准备帮助读者理解从算法到硬件落地的完整项目表达方式。压缩包仅含1个PDF文件约895KB内容围绕稀疏化CNN网络设计、摄像头实时采集、开发板处理与结果显示展开并涉及USB、串口、网络接口、HDMI等硬件模块的搭建思路。文中还介绍了基于TIDL API的模型训练导入、目标水果信息获取与显示以及多角度识别、新零售自助结算、质量控制与食品安全等应用场景对撰写系统设计、硬件实现和软件流程章节有直接参考价值。目前已有365人学习下载适合需要借鉴论文框架、实验描述与答辩素材的读者按需查阅。1. 从一块开发板说起这套水果图像识别系统要交付什么做水果图像识别的毕业设计最常见的翻车方式不是网络画得太浅而是答辩前一天才发现模型只能在笔记本上跑搬到开发板上不是算子不支持就是帧率掉到个位数。这套基于深度学习的水果图像识别系统把交付物定得很死一个摄像头实时采集、一块异构开发板本地推理、一块 HDMI 屏实时显示分类结果与营养信息外加一条把识别结果推到手机端的传输链路。它适合两类人——要交毕业论文、需要网络设计加硬件搭建加软件部署完整流程的同学以及想做一套能演示的端侧视觉原型的从业者。整套方案的关键取舍不在“识别率能刷到多高”而在“精度、模型体积、单帧延迟三者怎么在板子上平衡”这条主线会贯穿下面所有章节。2. 网络结构设计十层卷积、五层池化与权重稀疏化怎么落端侧网络的第一个约束是内存带宽不是算力。一块 1GB DDR3 的开发板模型参数每多 1MB推理时就要多搬一次卷积核越大、通道越宽带宽压力成倍上升。所以这套方案走的是“中等深度 权值稀疏 低比特量化”的路子10 个卷积层、5 个池化层、1 个全连接层加 softmax听起来层数不少但每层的通道数压得比较克制再靠稀疏化把无效权重剪掉把有效计算量降下来。这一章把网络拆成三块讲数据怎么进来、卷积核怎么分工、稀疏化到底省了什么。2.1 输入预处理与数据组织从 256×256 采集图到 224×224 网络入口数据集的组织方式决定了后面训练脚本能不能一把跑通。采集阶段统一按 256×256 分辨率拍拍完不直接改名乱放而是按“类别标签_图片编号.jpg”的规则重命名全部塞进同一个文件夹。这个命名看着土但它是后面生成 LMDB、切分训练集验证集、排查错标样本的唯一索引——文件名前缀就是标签出问题时ls 苹果_*.jpg | wc -l一下就知道某类是不是漏了。拍 30 类、约 30000 张平均每类 1000 张。拍摄时要注意两件事一是同一类水果至少覆盖 3 个角度正面、侧面、带蒂一面都要有这就是多角度识别在数据层的落地光靠网络自己学旋转不变性不现实二是光照要杂自然光、室内灯、阴影下各拍一批不然演示现场换个灯就崩。整理脚本我一般这么写import os, shutil, random from PIL import Image RAW_DIR ./raw # 采集原图子目录名即类别 OUT_DIR ./dataset_256 # 统一尺寸后的输出目录 CLASSES sorted(os.listdir(RAW_DIR)) for cls in CLASSES: os.makedirs(os.path.join(OUT_DIR, cls), exist_okTrue) files [f for f in os.listdir(os.path.join(RAW_DIR, cls)) if f.lower().endswith(.jpg)] for idx, f in enumerate(files): img Image.open(os.path.join(RAW_DIR, cls, f)).convert(RGB) img img.resize((256, 256), Image.BILINEAR) # 采集尺度留给训练做随机裁剪 # 命名规则类别标签_图片编号.jpg标签必须与类别目录一致 img.save(os.path.join(OUT_DIR, cls, f{cls}_{idx:04d}.jpg), quality92) # 按 8:1:1 切分随机种子固定保证每次实验可复现 random.seed(2020) for cls in CLASSES: files sorted(os.listdir(os.path.join(OUT_DIR, cls))) random.shuffle(files) n len(files) for split, part in [(train, files[:int(n*0.8)]), (val, files[int(n*0.8):int(n*0.9)]), (test, files[int(n*0.9):])]: dst os.path.join(./splits, split, cls) os.makedirs(dst, exist_okTrue) for f in part: shutil.copy(os.path.join(OUT_DIR, cls, f), os.path.join(dst, f))脚本做三件事统一尺寸、规范命名、固定种子切分。尺寸统一到 256 是因为训练时要随机裁到 224留 32 像素的余量给裁剪和轻微平移这比直接 resize 到 224 更能提升泛化。切分比例 8:1:1 是常规做法验证集用来选模型测试集只在最后跑一次别拿测试集调参这是答辩时最容易被问穿的地方。训练时再做一次水平镜像增强水果左右翻转后语义不变等于白捡一倍样本。生成 LMDB 时注意两点一是训练集和验证集要分别生成独立的 LMDB不要混在一个库里靠索引区分二是标签文件labelmap的顺序必须与后面部署时输出层的类别顺序完全一致这个顺序错位是最隐蔽的 bug——模型看起来在跑识别结果永远差一位。2.2 两种卷积核的分工5×5 步长 2 与 3×3 步长 1 的通道规划网络里两种卷积核轮流用。第一种是 5×5、步长 2、边缘补 2 圈负责快速降分辨率、扩大感受野第二种是 3×3、步长 1、边缘补 1 圈负责在原分辨率上细化特征。很多人这里会算错一笔账补 2 圈只能抵消 5×5 卷积核带来的 4 像素收缩真正让特征图减半的是步长 2不是 padding。所以 224×224 进第一个 5×5/2 层出来是 112×112不是 224。完整的层序我按这个方式排阶段层类型核/步长/Pad输出尺寸说明输入——224×224×3LMDB 裁剪 水平镜像C15×5 conv5/2/2112×112×32权重稀疏化 BN ReLUP1max pool3/2/056×56×32窗口与步长一致不重叠C23×3 conv3/1/156×56×64同分辨率细化C35×5 conv5/2/228×28×64降分辨率P2max pool3/2/014×14×64C43×3 conv3/1/114×14×128C53×3 conv3/1/114×14×128P3max pool3/2/07×7×128C6–C103×3 conv ×53/1/17×7×512通道逐层翻倍P4/P5max pool ×23/2/03×3×512 → 1×1×512全局降维FC全连接—1×1×NN 为类别数Softmax分类层—1×1×N交叉熵损失5 个池化层把 224 压到 1×1全连接层只接 512 个特征参数量约 1.5 万整个模型的可训练参数控制在几百万量级。如果把全连接层直接接在 7×7×512 上光这一层就是 25088×N模型体积立刻涨到十几 MB端侧完全吃不消所以后段用池化把空间维度压干再进分类器。这个设计取舍值得在论文里单独写一段因为它直接解释了“为什么池化层要放 5 个”。权重初始化用 MSRA即高斯分布、均值 0、方差与 fan-in 相关。理由很实在ReLU 会把负值全部截成 0如果用普通的高斯初始化深层网络的激活值方差会逐层衰减训练到第 6、7 层梯度就没了。MSRA 按每层输入神经元数量缩放方差正好把这个衰减抵消掉。每个卷积层后接 BN把输出分布拉回均值 0 方差 1学习率可以设大一点收敛快也不容易炸。激活统一用 ReLU负值置零、正值直通单侧抑制带来的稀疏激活本身也能省一部分计算。2.3 稀疏化到底省了什么从 MSRA 初始化到 8-12 bit 量化稀疏化不是玄学做法是在训练损失里加一项对卷积层权重的 L1 正则让大量接近 0 的权重被压到真正的 0剪枝时整块剔除。损失函数大致长这样L softmax_loss λ * Σ|w_conv|λ 是稀疏强度系数取值太大会把有用权重也压掉、识别率断崖下跌太小则稀疏率上不去、白忙一场。经验值是先从 1e-4 起步观察训练日志里卷积层权重的直方图当大部分权重集中到 0 附近、且验证集准确率掉幅在 1 个百分点以内就认为这轮稀疏化是成功的。稀疏化之后接量化权重从 32 位浮点压到 8-12 bit 整数。这一步的收益体现在三个地方模型体积缩小到原来的 1/4 到 1/8、推理时内存带宽占用大幅下降、定点运算在 DSP 类加速核上的吞吐远高于浮点。但代价也很明确——量化和稀疏都会牺牲精度。这套方案在测试时橘子只有 0.708 的识别概率明显低于山竹的 0.992一部分原因就在这里模型复杂度被压下来了类间差异小的样本就分不动了。所以量化不能拍脑袋定 8 bit。我的做法是按层看量化误差先全部按 8 bit 导一版跑一遍验证集记录每一层输出与浮点版本的余弦相似度相似度低于阈值的层单独提到 10 或 12 bit其余保持 8 bit。校准用的样本必须覆盖全部类别、每类至少 20 张否则量化缩放因子会被某一类主导其他类的动态范围直接被截断。这套流程走下来通常能在体积和精度之间拿到一个能写进论文的折中点。3. 硬件链路设计摄像头、开发板、显示屏与网络口怎么连硬件这部分最容易在答辩时被追问细节因为评委一听就知道你是真焊过线还是纸上谈兵。整套系统的物理链路其实只有四条摄像头进、屏幕出、串口调试、网络传数据。四条链路各占一个板载模块互不干扰把它们的职责和占用关系列清楚后面联调才不会出现“插上摄像头屏幕就黑”这种低级问题。3.1 板卡资源盘点五个模块的职责与占用选用的是一块异构开发板主控为 Cortex-A15 加 DSP 加速核的组合配 1GB DDR3 内存、8GB eMMC 存储。接口资源包括 1 路千兆以太网、1 路工业以太网、1 路 USB3.0、1 路 USB2.0、CSI 摄像头接口、HDMI 输出、UART 串口以及一个 80pin 扩展口。这套配置在端侧视觉项目里属于够用不浪费的档位。模块接口在本系统里的职责占用与注意事项USBUSB2.0接 USB 摄像头实时采集视频流摄像头独占该口不要再挂 U 盘USBUSB1.0/3.0接键盘鼠标用于现场改参数叠层口物理上分上下两层串口UART打印运行日志、下发控制指令波特率 115200接 PC 的 USB 转串口网络千兆以太网调试期 NFS 挂载运行期 socket 传结果与 WiFi 二选一避免路由冲突显示HDMI输出识别类别、营养信息、单价分辨率别设太高会抢推理带宽无线WiFi 模块把识别结果推到手机端仅传结构化数据不传视频这里有个隐藏的带宽账要算HDMI 输出 1080p 画面本身就要占一部分内存带宽如果同时跑推理帧率会明显下滑。稳妥的做法是把显示分辨率降到 720p并且显示端只刷新识别结果区域不做全屏重绘。这个细节写进论文的“性能优化”小节很加分因为它体现你真的在板子上跑过不是抄了个框图。3.2 供电、启动与调试通路先把系统跑起来再谈识别供电走外部 5V从 USB Type-C 口输入。注意别用电脑前置 USB 口供电电流不够推理一启动就重启现象是串口日志突然从头开始打印第一次遇到会以为是程序崩了。启动方式由板上 SYSBOOT 引脚的上拉下拉电阻组合决定默认配置是从 SD 卡启动把系统镜像烧到 SD 卡插上就能跑。调试通路强烈建议用 NFS而不是反复插拔 SD 卡拷贝文件。SD 卡插拔次数多了触点磨损某天突然认不到卡数据全丢这是血泪经验。开发板上电后先确认网络通再挂载 PC 上的工作目录# 开发板侧先确认能 ping 通 PC再挂载共享目录 ping -c 3 192.168.1.100 # 创建挂载点把 PC 的 /home/work/fruit 挂到板子的 /mnt/work mkdir -p /mnt/work mount -t nfs -o nolock,vers3 192.168.1.100:/home/work/fruit /mnt/work # 验证能看到训练脚本和模型文件即成功 ls /mnt/worknolock是必须加的端侧内核精简文件锁服务经常没起不加这个参数会卡在挂载阶段。vers3是为了兼容老内核的 NFS 实现。挂载成功后PC 上改一行代码板子上重新执行即可迭代效率差好几倍。但要注意一点运行期如果网线被碰掉任何对/mnt/work的读写都会阻塞程序看起来像死机。所以正式演示时模型文件和配置文件一定要先拷到板子的 eMMC 本地目录只把/mnt留给开发调试用。串口是另一条命脉。程序启动的第一行日志、推理每帧的耗时、错误码全部打到串口。建议在代码里统一封装一个日志宏带上时间戳和等级出问题时直接看串口输出定位比盲猜快得多。3.3 从 HDMI 到手机端识别结果的显示与传输链路HDMI 屏上显示的不只是类别名。按新零售场景的设计一帧识别结果要带四类信息水果名称、热量值、营养成分、单价。前三个是静态查表单价是按重量算的动态值所以显示层要维护一张类别到信息的映射表识别出类别后查表拼字符串再刷到屏幕的固定区域。手机端的链路走 WiFi用 socket 传结构化数据不传图像。协议用最简单的长度前缀加 JSON服务端在开发板上监听一个端口手机 App 连上后按行读取import socket, json, time # 开发板侧把识别结果推给手机 App只传结构化字段 INFO_TABLE { 苹果: {calorie: 52, price: 8.8, vitamin: VC}, 香蕉: {calorie: 89, price: 5.5, vitamin: VB6}, # ... 其余类别按数据集 labelmap 顺序补全 } def push_result(host, port, label, weight_kg, confidence): payload { label: label, confidence: round(float(confidence), 4), # 置信度一起下发低置信度时 App 提示重放 weight: weight_kg, total: round(INFO_TABLE[label][price] * weight_kg, 2), ts: int(time.time()), } with socket.create_connection((host, port), timeout3) as s: body json.dumps(payload, ensure_asciiFalse).encode(utf-8) # 长度前缀避免粘包先发 4 字节长度再发正文 s.sendall(len(body).to_bytes(4, big) body) push_result(192.168.1.120, 9000, 苹果, 0.65, 0.9607)长度前缀这一步不能省。TCP 是字节流不做分帧的话两次识别结果可能粘在一起App 侧解析直接抛异常。置信度字段也建议一起传——当模型输出的最大概率低于阈值比如 0.6App 端可以提示“请重新放置”比硬给一个错误结果体面得多。这套链路跑通之后支付环节只是 App 侧对接第三方支付 SDK 的事与识别系统本身解耦答辩时点到为止即可别把重点放偏。4. 训练与端侧部署从数据集到推理 API 的完整流程训练环境和部署环境是两套东西很多人卡在“模型训出来了但板子不认”。这一章按顺序走一遍环境怎么搭、模型怎么训、导入配置怎么写、推理主循环怎么组织。每一步都给出可直接改参数复用的代码或配置。4.1 数据集构建与训练环境准备训练在 Ubuntu 上做依赖 git、python、opencv 和一套支持稀疏量化的 Caffe 分支。这套分支相比原版 Caffe 多了两个能力训练时对卷积权重加稀疏约束以及导出时支持定点量化参数。装环境这一步坑最多的是依赖版本python 用 3.6 或 3.7 比较稳opencv 用系统包管理器装别自己编译源码编译一次两小时起步。# 依赖安装按顺序来别跳步 sudo apt-get update sudo apt-get install -y git python3 python3-pip python3-opencv \ libprotobuf-dev protobuf-compiler libhdf5-dev # 拉取支持稀疏量化的 Caffe 分支并编译python 接口要开 git clone -b sparse-quant repo caffe-sparse cd caffe-sparse cp Makefile.config.example Makefile.config # 打开 Makefile.config 里的 WITH_PYTHON_LAYER : 1 和 CPU_ONLY无显卡时 make -j$(nproc) make pycaffe编译完成后把python目录加进PYTHONPATHimport caffe不报错就算过。训练超参我一般这么设batch size 32基础学习率 0.01每 10000 次迭代降 10 倍总迭代 40000 次动量 0.9权重衰减 5e-4。30000 张图、30 类这个配置在单卡上跑几个小时能收敛。训练日志里重点盯两个数验证集准确率是否还在涨、稀疏正则项的损失是否稳定——如果稀疏损失突然飙升说明 λ 设大了赶紧降一档重来。训练完输出两个文件模型结构定义和权重文件。这两个文件是后面导入工具的唯一输入命名建议带上日期和迭代次数别用默认名不然三天后你自己都分不清哪个是最新的。4.2 模型导入配置一份能跑通的量化导入清单把训练好的浮点模型搬到板子上中间要过一道导入工具把它转成加速核能直接执行的私有格式。这一步靠一份配置文件驱动配置里包含网络结构、量化方式、量化位宽、输入输出层名、权重路径五项。配置写错的表现通常是导入过程不报错但推理结果全是乱的所以每一项都要和训练时的定义逐字对齐。# 模型导入配置字段名随厂商工具不同逻辑是一致的 [model] input_net ./deploy.prototxt # 网络结构必须与训练时一致 input_params ./fruit_iter_40000.caffemodel output_net ./fruit_sparse_quant.bin [quantization] quant_style power2 # 定点缩放便于硬件移位实现 bit_depth 8 # 全局 8bit个别层在下面单独覆盖 calib_images ./splits/val # 校准集必须覆盖全部类别 calib_num 20 # 每类取 20 张 [layer_override] conv6.bit_depth 10 # 后段通道多的层提到 10bit减小量化误差 conv10.bit_depth 12 # 输出层最敏感给到 12bit [io] input_name data output_name prob mean_value 104,117,124 # BGR 均值与训练时预处理保持一致 scale 0.003921568 # 1/255三个字段最容易出事。mean_value和scale一旦与训练时不一致模型精度会莫名其妙掉一大截而且不报错属于典型的黑匣子问题calib_images如果只拿某一类做校准其他类的激活值会被截断测试时表现为“只有某几种水果识别得准”output_name写错的话后面推理代码取结果直接段错误。导入完成后先别急着上板子在 PC 上用同一批测试图跑一遍量化模型与浮点模型的结果对比逐类看准确率跌幅跌幅超过 3 个百分点的类回去查它的样本量和校准覆盖。4.3 实时推理主循环采集、推理、显示三段式板子上的主程序是典型的生产者消费者结构采集线程取帧丢进队列推理线程取帧送加速核显示线程读结果刷屏。三段解耦的好处是摄像头不会因为推理慢而丢帧屏幕也不会卡住推理。推理部分调用板卡厂商提供的推理 API接口名各家不同逻辑都是“初始化句柄、填输入张量、执行、读输出张量”。import cv2, queue, threading, numpy as np from edge_infer import Engine # 厂商推理库的封装换成你板子上的那套 frame_q, result_q queue.Queue(maxsize2), queue.Queue(maxsize2) engine Engine(./fruit_sparse_quant.bin) LABELS [l.strip() for l in open(./labelmap.txt)] # 顺序必须与训练一致 def capture(): cap cv2.VideoCapture(0) cap.set(cv2.CAP_PROP_FRAME_WIDTH, 640) cap.set(cv2.CAP_PROP_FRAME_HEIGHT, 480) while True: ok, frame cap.read() if not ok: continue if frame_q.full(): # 队列满就丢旧帧保证实时性优先 frame_q.get() frame_q.put(frame) def infer(): while True: frame frame_q.get() img cv2.resize(frame, (224, 224)) img img.astype(np.float32) - np.array([104, 117, 124]) # 与训练均值对齐 img img * 0.003921568 prob engine.run(img.transpose(2, 0, 1)[None]) # NCHW 输入 idx int(np.argmax(prob)) result_q.put((LABELS[idx], float(prob[0][idx]), frame)) def display(): while True: label, conf, frame result_q.get() text f{label} {conf:.3f} cv2.putText(frame, text, (20, 40), cv2.FONT_HERSHEY_SIMPLEX, 1.2, (0, 255, 0), 3) cv2.imshow(fruit, frame) cv2.waitKey(1) for fn in (capture, infer, display): threading.Thread(targetfn, daemonTrue).start() threading.Event().wait()队列长度设成 2 是关键。设大了延迟累积屏幕上显示的还是两秒前那颗水果设小了采集端频繁丢帧。maxsize2配合“满则丢旧帧”的策略能在推理慢于采集时自动降采样率保证画面始终接近实时。输入张量的排布也要注意训练时是 NCHW推理时如果传成 NHWC结果会全错但不报错这类问题只能靠单帧对拍浮点结果来排查。5. 常见问题排查识别率、部署与联调里最容易翻车的五处这一章把项目里实际踩过的坑按“现象、原因、解决”三段式列出来。这些问题不解决答辩现场大概率翻车解决了论文的“误差分析”章节也就有东西写了。5.1 识别环节的三类翻车第一处某两种水果互相认错且错得很有规律。现象是山竹被识别成李子红苹果和绿苹果偶尔互换识别概率在 0.7 上下晃。原因有两层一是表皮颜色接近网络在浅层学到的颜色特征占了主导二是池化层把局部纹理压掉了而区分这两种水果恰恰靠表皮的颗粒感和光泽。解决办法不是简单加数据而是加有区分度的数据——补拍带纹理特写的样本训练时把随机裁剪的尺度调小比如从 224 里裁 200 再放大回去逼网络关注局部细节同时输出改成 top-2置信度低于阈值时把第二名也显示出来让人工判断。第二处整体准确率不低但某一类低得离谱。测试里橘子只有 0.708明显低于平均水平。先查样本量如果这一类明显少于其他类就是类别不平衡解决方式是在损失里按类别频率加权或者对少数类做重采样如果样本量正常就查标注30 类 30000 张靠人工标错标漏标一定存在用模型挑出“高置信度但预测与标注不符”的样本人工复核一遍往往能揪出一批脏数据。第三处换了环境识别率骤降。实验室里好好的搬到答辩教室就不认了。原因是训练数据的拍摄条件太单一模型学到了光照相关的捷径特征。补救方式是现场做一次白平衡校正或者在推理前加一步直方图均衡化把输入分布往训练分布上拉。更彻底的做法是训练时就做光照增强包括随机亮度、对比度、加高斯噪声让模型对光照不敏感。5.2 部署与联调的两类翻车第四处量化后精度断崖式下跌。浮点模型测试准确率 0.93导入板子后掉到 0.6。原因几乎都是校准集没覆盖全类别或者均值方差与训练不一致。排查顺序是先在 PC 上用量化模型跑一遍测试集确认掉点发生在导入阶段而不是推理阶段然后检查配置文件里的mean_value、scale与训练时的预处理是否逐位一致最后扩大校准集每类至少 20 张且要包含不同光照角度。个别敏感层单独提位宽通常能救回 2 到 3 个百分点。第五处长时间运行后程序卡死或重启。现象是跑十几分钟画面定格串口日志停止输出或者直接重启。原因通常有两个一是散热板子没有风扇推理满载时芯片降频甚至保护性重启摸一下主控发烫就是它二是内存泄漏采集线程里的帧对象没释放队列积压吃光 1GB 内存。解决方式是加散热片或小风扇同时在主循环里打印内存占用用free -m定时采样跑两小时看曲线是否单调上升。这类问题在演示前必须做一次 30 分钟以上的连续跑测别等现场才发现。6. 验收与答辩把一张识别概率表讲成可复现的结论验收不是“能认出苹果就行”得有一张能摆上台面的指标表。我一般按这五项组织每一项都对应一个可执行的测试方法评委追问时能立刻答出测法指标目标值测试方法Top-1 准确率≥ 0.9019 类平均测试集 3000 张一次跑完输出混淆矩阵最差类别准确率≥ 0.70从混淆矩阵里挑最低的一类单独分析单帧端到端延迟≤ 200 ms采集时间戳到显示时间戳取 100 帧均值连续运行稳定性30 min 无重启串口日志 定时采样内存占用跨光照一致性换光源掉点 ≤ 5%同一批样本在两种光源下各测一次这张表的用法有讲究。答辩时不要从“准确率 0.9”开始讲要从约束讲起板子只有 1GB 内存、没有独立显卡、要实时出结果所以模型必须稀疏化加量化而这两步一定会牺牲精度——橘子的 0.708 不是 bug是这个约束下的必然代价。先讲清楚取舍再摆出数据评委会觉得你懂自己在干什么反过来一上来就吹准确率被问到最差类别是哪一类、为什么低就很容易卡住。演示流程也提前排练三遍先开机、等系统起来、确认串口日志正常、摆水果、看屏幕出结果、故意放一个模型没训过的水果看它怎么错。最后这一步是加分项主动暴露边界比藏着掖着更可信。手机端只演示数据推送支付环节一句话带过别在现场点支付网络一抖动就下不来台。从那以后我每次带这类端侧项目都强制走一遍“浮点模型、量化模型、上板推理”三段对拍同一张图在三个环境里输出的概率向量必须高度接近差得多的那一步立刻回头查配置。这一步花不了半小时但能挡掉后面百分之八十的诡异问题。希望帮到你。本文还有配套的精品资源点击获取
