简介这份Python项目源码以驾驶员面部特征为切入点实现疲劳检测面向计算机视觉初学者、课程设计学生以及需要完成毕业设计的人群提供从人脸识别到疲劳状态判定的可运行实现。项目可服务于车内驾驶监控、交警摄像头巡查及高速收费站等场景帮助读者理解视频帧读取、面部区域定位、眼部或嘴部状态判断与疲劳提醒之间的处理链路。压缩包共24个文件、约68.33MB主体为5个Python源码文件并配有XML配置、Markdown说明、Word文档、音频提示与数据文件目录中包含源码模块与说明材料便于按模块阅读、调试和二次开发。已有1360人学习下载适合作为毕业设计参考也能为视觉检测类项目提供可复用的工程骨架、配置组织方式与排错思路。1. 从一帧摄像头画面说起这套疲劳检测源码跑起来能看到什么摄像头对准驾驶位画面里的人正常睁着眼控制台上的 EAR 数值在 0.28 上下浮动一次眨眼把它压到 0.17眨眼计数器加一连续两秒低于阈值报警音响起。这套 Python 人脸识别疲劳检测系统源码做的就是这件事先把人脸关键点抓出来再换算成睁眼度、张嘴度、头部俯仰角三个可以计算的量最后用时间窗口判断驾驶员是不是真的困了。它属于典型的毕业设计项目源码结构不复杂但要跑稳、要调得准里面有不少细节值得拆。适合正在找疲劳检测方向毕设课题的学生、想快速搭一个视觉监控原型的开发者以及需要把人脸识别从「能认出脸」推进到「能读懂状态」的工程人员。2. 拆开代码包人脸关键点、EAR/MAR 与判定逻辑怎么串起来拿到压缩包先别急着装环境先看清楚代码是怎么组织的。这类项目的主干一般很清晰一个视频采集入口一个关键点检测模块一个指标计算模块一个状态判定模块最后一个报警输出模块。真正决定检测效果好坏的不是代码行数而是关键点怎么选、指标怎么算、判定窗口怎么定。2.1 关键点选型的差异68 点与 468 点怎么选市面上做人脸疲劳检测关键点方案基本集中在两条路线上差异不只是点的数量。一条是传统的 68 点人脸关键点模型配合 dlib 的检测器。点的编号是固定的左右眼各 6 个点分别落在 36 到 41 和 42 到 47嘴巴外轮廓是 48 到 59内轮廓是 60 到 67。这意味着 EAR、MAR 这两个公式可以直接按固定索引写死不用做任何点位映射代码短、可读性高答辩的时候也容易讲明白。另一条是 468 点的人脸网格模型配合轻量的推理框架。点更密能拿到更细的眼睑轮廓和嘴角轮廓对侧脸、低头这类姿态的容忍度更好。代价是索引要靠自己定义官方给的只是拓扑连接关系眼睛用哪几个点、嘴巴用哪几个点需要你对照文档一个个挑出来。下面这张表是我在实际项目里总结的对比选型时可以直接参考维度68 点方案468 点方案依赖体积需要额外下载约 100MB 的模型文件模型内置在包里安装即用单帧耗时普通 CPU约 4080ms约 1530ms侧脸鲁棒性一般超过 30 度偏转容易丢点较好60 度以内仍能出点点位索引固定公式可直接写死需自行对照拓扑定义二次开发难度低改公式即可中需要先做点位筛选项目标题里给的是 Python 人脸识别 检测系统的组合这类毕设源码绝大多数走的是 68 点路线原因是依赖链清楚、代码短、调试直观。如果你拿到的是 68 点版本下面的所有公式可以直接套如果是 468 点版本思路一致只是把索引换成你自己挑出来的那几个编号。2.2 EAR 与 MAR 的几何含义两个能把表情变成数字的公式EAR 全称是眼睛纵横比思路很朴素眼睛睁开时上下眼睑之间的距离接近甚至超过眼睛的宽度眼睛闭上时上下眼睑贴在一起这个比值会迅速掉下去。公式写成这样EAR (|p2 - p6| |p3 - p5|) / (2 * |p1 - p4|)其中 p1 到 p6 是单只眼睛的 6 个关键点p1 和 p4 是左右眼角p2、p3、p5、p6 是上下眼睑的四个点。分子是两组上下眼睑距离之和分母是两倍的眼角距离。之所以除以两倍是为了让睁眼状态下的数值大致落在 0.3 附近方便设阈值。对应到 68 点模型左眼的 p1 到 p6 就是 36 到 41右眼是 42 到 47。代码里通常写成一个通用函数传两组索引进去就能算两只眼睛。MAR 是嘴巴纵横比思路一模一样只是换成嘴巴的上下开合距离和左右嘴角距离MAR (|p2 - p8| |p3 - p7| |p4 - p6|) / (3 * |p1 - p5|)68 点模型里嘴巴内轮廓是 60 到 67外轮廓是 48 到 59。用内轮廓算 MAR 更灵敏打哈欠时数值能到 0.6 以上正常说话时基本在 0.1 到 0.3 之间浮动。用外轮廓的话数值整体偏小阈值要跟着往下调。这个公式最容易被忽略的一点是它描述的是比例不是绝对距离。所以坐得远一点、坐得近一点EAR 的值基本不受影响这也是为什么它比直接量像素距离更适合做实时检测。2.3 主循环的数据流一帧画面怎么走完整个判定流程把上面几块拼起来主循环的逻辑大致是这样的读一帧转灰度检测人脸框在框内做关键点回归算左右眼 EAR 取平均算 MAR算头部姿态角把这几个值送进判定器判定器根据连续帧的状态决定要不要报警。下面是我平时用的骨架代码省略了报警和日志部分只保留数据流主干import cv2 import dlib import numpy as np from scipy.spatial import distance as dist # 68 点模型中左右眼与嘴巴内轮廓的索引 LEFT_EYE list(range(36, 42)) RIGHT_EYE list(range(42, 48)) MOUTH_INNER list(range(60, 68)) def eye_aspect_ratio(pts): # 垂直方向两组距离 v1 dist.euclidean(pts[1], pts[5]) v2 dist.euclidean(pts[2], pts[4]) # 水平方向眼角距离 h dist.euclidean(pts[0], pts[3]) return (v1 v2) / (2.0 * h) def mouth_aspect_ratio(pts): # 内轮廓三个纵向距离 v1 dist.euclidean(pts[1], pts[7]) v2 dist.euclidean(pts[2], pts[6]) v3 dist.euclidean(pts[3], pts[5]) h dist.euclidean(pts[0], pts[4]) return (v1 v2 v3) / (3.0 * h) detector dlib.get_frontal_face_detector() predictor dlib.shape_predictor(shape_predictor_68_face_landmarks.dat) cap cv2.VideoCapture(0) while True: ok, frame cap.read() if not ok: break gray cv2.cvtColor(frame, cv2.COLOR_BGR2GRAY) # 第二个参数是上采样次数1 表示放大一倍再检测小脸场景可以调大 faces detector(gray, 1) for rect in faces: shape predictor(gray, rect) coords np.array([[p.x, p.y] for p in shape.parts()]) ear (eye_aspect_ratio(coords[LEFT_EYE]) eye_aspect_ratio(coords[RIGHT_EYE])) / 2.0 mar mouth_aspect_ratio(coords[MOUTH_INNER]) cv2.putText(frame, EAR:{:.3f} MAR:{:.3f}.format(ear, mar), (20, 40), cv2.FONT_HERSHEY_SIMPLEX, 0.7, (0, 255, 0), 2) cv2.imshow(fatigue, frame) if cv2.waitKey(1) 0xFF 27: break cap.release() cv2.destroyAllWindows()逻辑说明部分detector(gray, 1)里的第二个参数是上采样次数值越大越容易检出小人脸但耗时也成倍增加驾驶位这种距离下用 1 就够。predictor内部是按人脸框做局部回归所以必须先有人脸框不能直接把整帧喂进去。EAR 取两只眼睛的平均值是为了避免单侧遮挡或者单侧光照造成的跳变。参数说明部分上面这段代码里没有任何硬编码阈值是因为这一版只负责把指标算出来并显示。真正的判定要放在下一层用连续帧的计数器和时间窗口来做这部分在第四章展开。有一段需要特别提醒shape.parts()返回的是整张脸的 68 个点索引和你传入的检测框一一对应但如果你在循环里对图像做了 resize坐标必须先换算回原图尺度再画框否则框和点会错位。3. 环境与首次跑通依赖版本、模型文件与摄像头参数的三个硬门槛代码看懂了不等于能跑起来。这类项目在环境这一步卡住的人最多卡点集中在三处编译型依赖装不上、模型文件找不到、摄像头读不出帧。这一章按顺序把三个门槛过一遍。3.1 依赖安装编译失败的四条排查路径核心依赖通常是四个OpenCV 负责图像采集和绘制dlib 负责检测和关键点回归NumPy 和 SciPy 负责数值计算和距离运算。前三个是二进制包装起来很快dlib 是 C 扩展在部分平台上需要本地编译。下面是我常用的安装顺序先装纯 Python 包最后装 dlib# 基础数值库与图像库 pip install numpy scipy opencv-python # dlib 优先尝试预编译轮子 pip install dlib # 如果上面这条报编译错误再考虑源码编译 pip install cmake pip install dlib --no-binary dlib逻辑说明先装cmake再源码编译 dlib是因为 dlib 的构建脚本依赖 CMake 生成构建文件不加--no-binary时 pip 会优先拉取对应平台的预编译包省掉编译环节。编译失败最常见的四种原因一是本机没有 C 编译工具链Windows 上表现为找不到 cl.exeLinux 上表现为 gcc 缺失二是 CMake 版本过旧dlib 的新版本对 CMake 有最低版本要求三是内存不足编译 dlib 的过程中峰值内存能到 2GB 以上虚拟机里很容易被杀掉四是 Python 版本太新预编译包还没跟上只能走源码编译。判断走哪条路有个简单办法装完之后执行一次python -c import dlib; print(dlib.__version__)能打印出版本号就说明装好了报 ImportError 就说明还没成需要看完整报错。提示如果只是跑通检测流程不打算改 dlib 内部实现可以优先找带预编译包的 Python 版本组合省下的编译时间足够你把参数调三轮。3.2 模型文件路径、校验与两种常见缺失68 点方案需要单独的模型文件文件名通常是shape_predictor_68_face_landmarks.dat体积在 100MB 上下。代码里dlib.shape_predictor(...)的参数就是这个文件的路径。两个最常见的翻车场景一是把 .dat 文件放在项目根目录但代码里写的是相对路径运行目录一变就找不到二是下载过程中断文件大小对但内容不完整加载时不报错检测时直接崩。校验的方法很简单加载之后打印一次点数import dlib predictor dlib.shape_predictor(models/shape_predictor_68_face_landmarks.dat) # 用一个已知的人脸图测试正常应输出 68 print(landmark parts:, predictor.num_parts)num_parts输出 68 说明模型加载正确。如果这里抛异常八成是路径错了或者文件损坏重新下载一次比继续排查更省时间。路径管理上我一般会做一层封装把模型目录做成可配置项而不是写死在代码里import os BASE_DIR os.path.dirname(os.path.abspath(__file__)) MODEL_PATH os.path.join(BASE_DIR, models, shape_predictor_68_face_landmarks.dat) # 启动时先做一次存在性检查避免跑到一半才崩 if not os.path.exists(MODEL_PATH): raise FileNotFoundError(模型文件缺失: MODEL_PATH)这段代码解决的是打包和迁移时的问题用__file__取当前脚本所在目录再拼相对路径不管你从哪个目录启动脚本路径都是对的。如果后面要打包成可执行文件这一层封装还能改成从临时解压目录读取。3.3 摄像头参数分辨率、帧率与首帧黑屏摄像头这一环看起来最简单实际上参数没设对会直接影响检测效果。默认分辨率下人脸在画面里可能只有一百多像素宽关键点回归的精度会明显下降EAR 抖动得厉害。我一般会显式指定分辨率和帧率并在启动后读一次实际生效的参数做校验import cv2 cap cv2.VideoCapture(0) # 期望的分辨率不是所有摄像头都支持设置后要读回确认 cap.set(cv2.CAP_PROP_FRAME_WIDTH, 640) cap.set(cv2.CAP_PROP_FRAME_HEIGHT, 480) cap.set(cv2.CAP_PROP_FPS, 30) real_w cap.get(cv2.CAP_PROP_FRAME_WIDTH) real_h cap.get(cv2.CAP_PROP_FRAME_HEIGHT) real_fps cap.get(cv2.CAP_PROP_FPS) print(实际生效: {}x{} {}fps.format(real_w, real_h, real_fps))参数说明set只是提出请求摄像头驱动不一定照办所以必须用get读回真实值。640×480 是这类检测的性价比区间再往上清晰度提升有限但单帧耗时线性上涨帧率设 30 是给后面的时间窗口留余量如果实际只有 15 帧那么「连续 20 帧闭眼」对应的真实时长会翻倍判定就会偏松。首帧黑屏是另一个常见问题。有些摄像头需要预热几帧才能出正常画面解决办法是在进入主循环之前先读若干帧丢弃# 预热丢弃前 10 帧避免首帧黑屏或过曝 for _ in range(10): cap.read()这个细节不影响算法但会直接影响你第一次运行时的观感也影响日志里第一段数据的可信度。4. 参数调优EAR 阈值、连续帧数与误报率之间的三角关系能跑起来之后下一个问题一定是「为什么老是误报」或者「为什么真困了却不报」。这类系统的调参本质是在三个量之间找平衡EAR 阈值决定单帧判断的松紧连续帧数决定时间维度的确认强度误报率是前两者共同作用的结果。三者改一个另外两个都得跟着看。4.1 EAR 阈值的实测标定别抄默认值网上流传的 EAR 阈值大多是 0.25 或 0.3直接抄过来往往不好用因为 EAR 的绝对值和人脸在画面里的尺度、摄像头的焦距、关键点模型的精度都有关系。我的做法是分三步标定。第一步让测试对象正常睁眼盯着镜头 30 秒记录 EAR 的均值 μ_open 和标准差 σ_open。第二步让他正常眨眼 20 次记录每次眨眼过程中的最低值。第三步把阈值定在 μ_open 减去 2 到 3 倍标准差的位置同时确保这个值低于正常眨眼的最低值、高于真正闭眼时的读数。import numpy as np # 从日志里读一段睁眼状态的 EAR 序列 open_ear np.array(open_ear_samples) mu open_ear.mean() sigma open_ear.std() # 阈值取均值减 2.5 倍标准差再和区间下限取大 threshold max(mu - 2.5 * sigma, 0.16) print(mu{:.3f} sigma{:.3f} threshold{:.3f}.format(mu, sigma, threshold))逻辑说明均值减若干倍标准差是统计学里常用的异常下限思路这里借用它来区分「正常睁眼的自然波动」和「闭眼造成的骤降」。max(..., 0.16)是一道保险防止样本里混入大量闭眼帧导致算出来的阈值过低。参数说明2.5 这个倍数可以调样本干净就用 2.0样本里噪声多用 3.0。0.16 这个下限对不同人脸不一定合适需要在测试集上再看一遍。注意标定用的样本必须来自实际部署的摄像头和实际光照条件换一个摄像头、换一个房间EAR 的分布都会变之前调的阈值基本作废。4.2 时间窗口与连续帧计数单帧判断为什么不可靠单帧 EAR 低于阈值就报警这套逻辑在真实场景里几乎不能用因为眨眼、低头看仪表、揉眼睛都会造成短暂的低值。可靠的判定必须在时间维度上做确认。常见的做法是双计数器一个持续计数专门对付长时间闭眼一个滑动窗口专门对付频繁眨眼。两者的区别在于前者衡量的是「闭了多久」后者衡量的是「眨得多频繁」。from collections import deque EAR_THRESHOLD 0.21 CONSEC_FRAMES 20 # 连续闭眼帧数约 0.7 秒 BLINK_WINDOW_SEC 60 # 眨眼统计窗口 BLINK_RATE_LIMIT 25 # 窗口内眨眼次数上限 closed_counter 0 blink_records deque() # 存每次眨眼的时间戳 fps 30.0 def update(ear, now): global closed_counter if ear EAR_THRESHOLD: closed_counter 1 else: # 从闭到开记一次眨眼 if 0 closed_counter CONSEC_FRAMES: blink_records.append(now) closed_counter 0 # 剔除窗口外的旧记录 while blink_records and now - blink_records[0] BLINK_WINDOW_SEC: blink_records.popleft() long_close closed_counter CONSEC_FRAMES high_rate len(blink_records) BLINK_RATE_LIMIT return long_close, high_rate逻辑说明closed_counter从 0 开始累加一旦 EAR 回升就置零在置零之前判断它是否落在「一次正常眨眼」的范围内是的话才计入眨眼记录。这样可以把长时间闭眼和正常眨眼区分开不会互相污染统计。参数说明CONSEC_FRAMES和帧率强相关20 帧在 30fps 下是 0.67 秒在 15fps 下就是 1.33 秒。如果代码里没有动态读帧率建议在启动时算一次实际帧率再换算别把帧数写死。BLINK_RATE_LIMIT的取值因人而异正常人每分钟眨眼 15 到 20 次疲劳状态下会降到 10 次以下或者出现长时间闭眼25 这个上限是配合持续闭眼检测一起用的辅助判据。4.3 光照、眼镜与头部角度三类会让阈值失真的场景调好的阈值换到另一个场景就失效通常不是算法的问题而是输入分布变了。三类场景最常见。逆光或者侧光。强光从背后打过来时人脸整体变暗关键点回归的精度下降EAR 会出现无规律抖动。解决思路是预处理阶段做一次直方图均衡把灰度分布拉开gray cv2.cvtColor(frame, cv2.COLOR_BGR2GRAY) # 限制对比度的自适应均衡比全局均衡更不容易过曝 clahe cv2.createCLAHE(clipLimit2.0, tileGridSize(8, 8)) gray_eq clahe.apply(gray)clipLimit控制对比度增强的上限值越大增强越猛但也越容易放大噪声tileGridSize是分块大小8×8 在 640×480 的画面下比较合适。戴眼镜。镜片反光会在眼睛区域形成高亮斑遮挡关键点。这个没有一劳永逸的解法实际操作里通常是把 EAR 阈值往下调一档同时把连续帧数调大用时间维度换单帧的可靠性。如果项目允许也可以在检测前加一层简单的反光检测命中就跳过该帧的判定。头部大角度偏转。低头超过 20 度时眼睛在画面里被压缩EAR 会自然变小容易误判成闭眼。这时候需要引入头部姿态角做补偿用关键点做一次姿态估计把俯仰角超过阈值的帧单独标记判定时降低权重或者直接不计入闭眼计数。# 用 68 点里的鼻尖、下巴、左右眼角做粗略姿态估计 # 这里只示意取点具体 solvePnP 的参数需要相机内参 image_points np.array([ coords[30], # 鼻尖 coords[8], # 下巴 coords[36], # 左眼角 coords[45], # 右眼角 ], dtypedouble) # rvec / tvec 由 cv2.solvePnP 求出后再转欧拉角判断俯仰这段代码只是把点位取出来真正的姿态解算需要相机内参矩阵和畸变系数。没有标定数据时可以用一个近似内参先跑起来精度差一些但足以区分「大幅低头」和「正常注视」。5. 避坑排查五类跑起来之后才会遇到的翻车前面几章讲的都是「怎么让它跑」这一章讲「跑起来之后为什么会坏」。下面五条是我在实际调试里反复遇到的每条按现象、原因、解决三段来写。5.1 摄像头能打开但一直读不到帧现象cap.isOpened()返回 True但cap.read()一直返回 False画面窗口是灰的。原因设备被其他进程占用或者索引选错了。笔记本上外接摄像头时内置摄像头通常是 0外接的是 1 或 2有些系统上虚拟摄像头会占据前面的索引。解决先把索引从 0 到 3 依次试一遍看哪个能读出非空帧再检查任务管理器里有没有其他程序占着摄像头。代码里加一层读帧失败的重试连续失败超过阈值再退出避免偶发失败直接终止程序fail_count 0 while True: ok, frame cap.read() if not ok: fail_count 1 if fail_count 30: print(连续读帧失败退出) break continue fail_count 0 # 正常处理5.2 人脸框跳动导致 EAR 剧烈抖动现象人坐着不动EAR 的显示值却在 0.18 到 0.32 之间来回跳报警时不时触发一下。原因逐帧独立做人脸检测相邻帧的检测框位置有细微差异关键点回归的输入跟着变输出就有抖动。这是检测器的正常特性不是 bug。解决两个方向。一是给检测框加平滑用上一帧的框和当前帧的框做加权平均二是给 EAR 序列加滑动平均用最近 5 帧的均值代替当前值参与判定。前者治本后者治标一般两个都上from collections import deque ear_window deque(maxlen5) def smooth_ear(raw): ear_window.append(raw) return sum(ear_window) / len(ear_window)maxlen5决定平滑窗口长度值越大越平滑但响应越慢。30fps 下 5 帧大约是 0.17 秒的延迟对疲劳检测这种秒级判断完全可以接受。5.3 戴眼镜或逆光时误报率飙升现象同一个人不戴眼镜时判定正常戴上眼镜后十分钟报八次。原因镜片反光遮挡眼睛关键点模型回归出来的点位偏离真实眼睑位置EAR 被人为压低。逆光同理整体灰度偏低导致关键点定位漂移。解决先做灰度均衡再把 EAR 阈值整体下调 0.02 到 0.03同时把连续帧数从 20 提到 30。这套组合的本质是用更保守的判定换更低的误报代价是对真正疲劳的响应变慢需要在测试里确认延迟可以接受。5.4 长时间运行内存持续上涨现象跑半小时之后内存占用从 300MB 涨到 2GB最后卡死。原因多半是 matplotlib 或日志模块在循环里反复创建对象没有释放也可能是把每一帧都存进了列表里做统计。OpenCV 的imshow本身不会泄漏但如果循环里每次都createCLAHE或者新建VideoWriter累积起来就很可观。解决把可以复用的对象提到循环外面创建统计用的容器设上限比如用deque(maxlenN)代替list。检查的时候可以在循环里每隔 100 帧打印一次psutil.Process().memory_info().rss看曲线是不是单调上升。5.5 打包成可执行文件后模型加载失败现象源码里跑得好好的打包之后一启动就报找不到 .dat 文件。原因打包工具把资源文件放进了临时解压目录运行时的工作目录和开发时不一样相对路径失效。解决运行时用sys._MEIPASS判断是否处于打包环境是的话从临时目录取模型否则从脚本目录取import sys import os def resource_path(relative): # 打包后资源被解压到 _MEIPASS 指向的临时目录 base getattr(sys, _MEIPASS, os.path.dirname(os.path.abspath(__file__))) return os.path.join(base, relative) MODEL_PATH resource_path(models/shape_predictor_68_face_landmarks.dat)同时要在打包配置里显式声明 .dat 文件为附加资源否则它根本不会被复制进去。6. 从能跑到能交差把检测结果落成日志、曲线和分级报警一个只会在屏幕上显示 EAR 数值的 Demo和一个能拿去答辩、能给别人演示的系统差距往往不在算法而在结果怎么呈现。我一般会给这类项目补三样东西结构化日志、趋势曲线、分级报警。日志这块别用print用 CSV 按帧落盘字段至少包含时间戳、EAR、MAR、闭眼计数、当前判定状态。这样后面画曲线、算统计指标、复盘误报都能直接读文件不用重新跑一遍视频。写的时候用追加模式程序中断也不会丢已写入的数据import csv, time with open(fatigue_log.csv, a, newline) as f: writer csv.writer(f) # 首行写表头实际使用时要判断文件是否已存在 writer.writerow([ts, ear, mar, closed, state]) # 循环内 writer.writerow([round(time.time(), 3), round(ear, 4), round(mar, 4), closed_counter, state])趋势曲线用 matplotlib 画横轴时间、纵轴 EAR把阈值画成一条水平参考线闭眼区间用底色标出来。这张图在答辩时比任何口头描述都有说服力评审一眼就能看出阈值定得合不合理。分级报警是我觉得最值得加的一点。不要只有一个「困了」状态分成三级一级是眨眼频率异常但还没长时间闭眼只记录不响铃二级是连续闭眼超过 1 秒播放提示音三级是连续闭眼超过 2 秒或者一分钟内触发多次二级报警音加强并写一条高优先级日志。分级的好处是误报的代价变小了一级误报只是多一条日志不会打扰驾驶。验证方法上我习惯用录制视频代替实时摄像头做回归测试把几段标注好的视频正常、轻度疲劳、重度疲劳各一段喂进程序看输出的状态序列和人工标注的重合度。这样每次改参数都能快速跑一遍不用每次都真人坐在摄像头前面演。血泪经验是早期图省事直接拿实时摄像头调参调一次要重新演一遍演得还不一样根本没法对比。从那以后我每次改判定逻辑都强制走一遍录制视频的回归参数改动前后各跑一次把两份日志对齐比较。希望这套流程能帮到你少走几轮弯路。本文还有配套的精品资源点击获取
