企业官网建设流程全解析

简介：人脸识别作为计算机视觉的重要分支，通过提取人脸特征实现身份验证，已广泛应用于安防、金融等领域。在教室考勤场景中，传统点名方式效率低、易错，而基于边缘计算的人脸识别方案将深度学习模型部署在本地设备，利用NPU或图像处理单元加速推理，无需依赖云端，从而保障数据隐私和实时性。借助OpenCV进行图像预处理，结合深度学习模型完成人脸检测与特征提取，可以实现无感知的自动考勤记录。该技术适用于学校、培训机构等离线环境，能有效降低人工核对成本，提升管理效率。本文以一个基于Python和OpenCV的开源项目为例，阐述如何从硬件选型、模型部署、业务逻辑到优化完整构建一套教室人脸识别考勤系统，并分享工程实践中的关键经验。 做教室考勤系统，最早是因为自己本科的时候被辅导员拉去统计课堂出勤，那种感觉太一言难尽了。一张点名表传半个班，代答、漏掉、忘写，统计完还要手工录入Excel，一学期下来光核对数据就要花掉好几天。后来转去搞嵌入式AI开发，第一件事就是想把这个场景彻底改掉：在教室门口放一块边缘设备，通过人脸识别自动确认谁到了、谁没到、谁是踩着点进来的。整套系统用Python写，源码可以自己改自己部署，基于OpenCV和深度学习模型实现了从人脸检测、特征提取到考勤记录落库的完整链路。

这个项目适合三类人看：一是要做嵌入式AI落地开发，但不想只跑官方Demo的Python开发者；二是学校或培训机构的信息化管理人员，想找一个能离线部署、不依赖云端的考勤方案；三是正在做毕业设计或课程设计的学生，需要一个结构清晰、能真跑起来的“人脸识别考勤系统源码”做二次开发。我不太想把这篇稿子写成纯理论科普，所以下面会按项目的真实搭建顺序来讲：需求取舍、硬件选型、算法模块、考勤逻辑、部署优化，最后把源码结构和复现方式一起放出来。

1. 这个项目要解决的真实问题：教室考勤的现状与AI落地的切入点

1.1 传统考勤的三个真正痛点

先别急着谈人脸识别的技术细节，如果对业务痛点理解不到位，做出来的系统再炫也没用。传统教室考勤的主要问题其实总结起来只有三点。

第一是代点和不点。纸质点名表传一轮，谁喊一声“到”根本没法核实，有些课程人多教室大，老师只能靠脸熟判断，一个学期下来漏记错记很常见。第二是数据汇总困难。今天这节课是Excel表，明天那节课是微信群接龙，最后统计平时分要把所有来源手工合并，这是我在辅导员办公室亲眼见过的场景。第三是时间成本。一节课45分钟，点名点掉5分钟，对大课来说这点时间不痛不痒，但对频繁有多个教学班的老师来说，一天花在点名上的时间累积起来很可观。

所以这个项目的目标很明确：不追求人脸识别领域那种高大上的技术指标，而是要把“这堂课谁来了、谁没来、谁迟到、谁早退”这件事用机器自动记录清楚，并且让老师随时能查到统计结果。

1.2 为什么这次选择“嵌入式AI+本地识别”而不是云端API

这里有一个关键的方案取舍问题。市面上很多考勤系统会把摄像头画面传到云端，再调用云端人脸识别接口，然后把结果回传给本地。这种方式的好处是算法模型可以很大很准，坏处也很明显：教室网络不稳定时系统就瘫了，而且学生的人脸数据全部上传，家长和学校在隐私合规上很难接受。另外，云端API按调用次数收费，一个学校几百个教室，每天几万次调用，成本不低。

我选择的是嵌入式AI方案，也就是把模型和推理全部放在教室里的边缘设备上。整条链路不需要外网，摄像头画面不出教室，识别结果直接写入本地数据库。这套思路在行业里叫“端侧智能”或“边缘推理”，对考勤这种延迟敏感、隐私敏感、网络条件不稳定的场景特别合适。

当然，本地识别不等于不用好模型。嵌入式设备算力有限，后面我会详细讲如何通过模型量化和推理速度优化，让人脸识别在边缘设备上也能跑到可用的帧率和准确率。

1.3 项目边界和能跑起来的完整范围

做一个项目必须明确边界，否则做着做着就失控了。这套系统的核心范围我控制在四块：人脸注册、人脸识别、考勤记录、统计报表。人脸注册解决“系统怎么知道你是你”的问题，需要导入学生照片和学号；人脸识别解决“当前教室里是谁”的问题；考勤记录解决“这堂课他算不算签到”的问题；统计报表解决“老师怎么看结果”的问题。

第一版我没有做活体检测的高级功能，但会在后期预留接口。也没有做复杂的多人跟踪系统，因为教室门口的考勤场景通常只需要处理单人连续通过或小范围队列，不需要像安防项目那样跟踪每个人的运动轨迹。把范围缩小之后，代码量可控，源码的可读性也更好，别人拿过去二次开发时知道该改哪里。

2. 智能教室考勤系统的整体架构：从硬件选型到数据流设计

2.1 边缘设备选型：我用了什么，为什么不用另一块

嵌入式AI开发的第一个硬骨头是硬件选型。很多人一上来就买最贵的开发板，结果发现项目根本用不到那么强的算力，还白白增加了散热和功耗成本。也有人图便宜买了性能太弱的板子，跑起模型来一秒钟处理不了一帧，最后整个项目推倒重来。

我当时在备选列表里放了三块板子：树莓派4B、Jetson Nano、瑞芯微RK3588开发板。树莓派4B大家最熟悉，生态好、教程多，但CPU跑人脸识别模型非常吃力，不加硬件加速器的话基本只能做低分辨率、低帧率的演示。Jetson Nano自带128核心的Maxwell GPU，可以跑TensorRT加速，老款算力约472 GFLOPS，在当年的入门级边缘AI设备里非常能打。瑞芯微RK3588属于近几年国产平台里热度很高的板子，NPU算力到6 TOPS，跑INT8量化模型表现不错，而且接口丰富，价格也比Jetson系列稳定。

最终我用了RK3588开发板作为主部署平台，因为它的NPU对INT8量化模型支持得比较好，跑人脸检测和特征提取两个模型都能拿到不错的实时性能，同时内存选了8G版本，跑Python推理进程加上Web服务完全够用。Jetson Nano的部署我也做过，代码只要改一下推理后端就能适配，后面源码里会留出配置开关。

2.2 软件栈和通信链路设计

硬件定了之后，软件栈的选型就比较顺理成章。操作系统我用Ubuntu 20.04，Python版本3.8。为什么要强调Python版本？因为很多深度学习推理库的预编译包对版本有要求，3.8在部署兼容性上最省心，我建议后续复现时也固定在这个版本。

整个系统的软件模块分四层。最底层是摄像头驱动和图像采集模块，通过V4L2接口读取USB摄像头画面。第二层是AI推理模块，负责加载人脸检测模型和特征提取模型，并把原始图片转换成特征向量。第三层是考勤业务模块，处理课程表、签到时间窗口、状态更新等逻辑。最上层是数据存储和Web展示模块，用SQLite保存结构化考勤数据，用Flask提供一个简单网页给老师查看统计结果。

通信链路设计上，摄像头的原始图像只存在于本机内存中，不走网络。RK3588板子上跑一个Python主进程，完成从取帧到识别到写库的全部操作。其他终端设备通过局域网访问板上Flask服务，这样老师用手机浏览器就能看到考勤情况，不需要安装任何客户端。

2.3 数据流：一帧画面怎么变成一条考勤记录

理解了整个数据流，源码再长也不会觉得乱。我把一帧画面的处理链路简化成下面这个顺序：

摄像头取帧 → 人脸检测 → 人脸对齐预处理 → 特征提取 → 特征向量比对 → 课程时间判断 → 写入考勤记录 → 更新Web页面

摄像头取到的是一帧1280x720的BGR图像。人脸检测模型先框出画面里的人脸位置，然后我从原图上裁出人脸区域，做缩放和归一化，输入特征提取模型得到512维的特征向量。这个向量代表这张脸的数值特征，我们需要和数据库中已注册的学生特征做余弦距离比较。距离小于阈值，判定为同一人，然后再检查当前时间是否在有效签到窗口内，如果是，就写入一条考勤记录。

这里有一个容易忽视的细节：不是每一帧识别成功都要写入数据库。如果同一个学生连续出现在视频流里，每一帧都写一条记录，数据库会爆炸。所以考勤模块里设置了“已签到”状态去重，同一个学生在同一堂课上只会被记录一次，但每一帧识别结果都会留下来做人脸质量统计和调试日志。

3. 人脸识别核心模块：检测、特征提取、比对的工程化实现

3.1 人脸检测：MTCNN在教室场景里的表现

人脸识别首先要解决“人的脸在哪”的问题。早期OpenCV自带的Haar级联检测器在教室场景里表现非常不稳定，侧面、低头、光线变化都很容易漏检，误检率还高。所以我没用传统方法，而是选用MTCNN做第一版检测方案。MTCNN是来自学术界的经典人脸检测模型，包含P-Net、R-Net、O-Net三个级联网络，能同时输出人脸框、五个关键点和置信度。在教室门口场景下，它的漏检率比Haar低很多。

后来做嵌入式优化时，我发现MTCNN的三个级联网络在端侧跑起来还是偏慢，就把它换成了单阶段轻量级检测模型，导出成ONNX格式后用RKNN工具链转换。最终检测部分在板子上的单帧耗时大约15到25毫秒，完全能满足考勤场景的需求。

下面是人脸检测模块的核心代码结构。代码逻辑不复杂，重点是处理好输入图片的尺寸和输出坐标的还原。

import cv2 import numpy as np class FaceDetector: def __init__(self, model_path, input_size=(320, 320)): self.input_size = input_size self.net = cv2.dnn.readNetFromONNX(model_path) def detect(self, bgr, conf_threshold=0.5): h, w = bgr.shape[:2] blob = cv2.dnn.blobFromImage( bgr, 1.0 / 128.0, self.input_size, (127.5, 127.5, 127.5), True ) self.net.setInput(blob) output = self.net.forward() boxes = [] for i in range(output.shape[2]): conf = output[0, 0, i, 2] if conf < conf_threshold: continue x1 = output[0, 0, i, 3] * w y1 = output[0, 0, i, 4] * h x2 = output[0, 0, i, 5] * w y2 = output[0, 0, i, 6] * h boxes.append((int(x1), int(y1), int(x2), int(y2), float(conf))) return boxes

3.2 特征提取：ArcFace的512维特征向量

检测到人脸以后，下一步是把人脸区域转换成可比较的数值特征。我选择ArcFace作为特征提取器，输出512维的特征向量。ArcFace在分类任务里通过角余弦裕度让同类特征更紧凑、类间特征更分散，比早期FaceNet在遮挡和角度变化下更稳。模型本身不大，适合部署到嵌入式设备。

特征提取前要对人脸区域做预处理，通常叫人脸对齐。MTCNN输出的五个关键点包括左眼、右眼、鼻尖、左嘴角、右嘴角，ArcFace训练时用的是按关键点对齐后的112x112输入。如果不对齐直接丢进模型，识别率会明显下降。源码里我写了一个preprocess_face函数，先用关键点计算仿射变换矩阵，再裁切缩放。

import cv2 import numpy as np import onnxruntime as ort class FaceRecognizer: def __init__(self, model_path): self.session = ort.InferenceSession( model_path, providers=["CPUExecutionProvider"] ) self.input_name = self.session.get_inputs()[0].name def preprocess(self, face_img): face_img = cv2.resize(face_img, (112, 112)) face_img = face_img.astype(np.float32) / 127.5 - 1.0 face_img = np.expand_dims(face_img, axis=0) face_img = np.transpose(face_img, (0, 3, 1, 2)) return face_img def get_embedding(self, face_img): blob = self.preprocess(face_img) emb = self.session.run(None, {self.input_name: blob})[0] emb = emb.reshape(-1) norm = np.linalg.norm(emb) return emb / norm if norm > 0 else emb

3.3 比对逻辑与阈值校准

得到特征向量后，判断“他是谁”用余弦距离。两个向量距离越近，代表两张脸越像。注册的时候，每一位学生会在程序里生成一个512维特征向量存到数据库。识别时，程序把当前帧的特征向量和库里所有特征向量逐一计算距离，选出最小距离，再和阈值做比较。

阈值选多少，是整个系统准确率的关键。阈值太严，真人会被误判为不认识，造成大量漏签；阈值太松，长得像的人可能被认成同一个。实际操中根据教室现场的光线和摄像头位置，我会用一批真实采集的样本校准，通常取0.3到0.4之间的值。源码里我默认放的是0.35，这个值在多数室内环境下表现比较均衡。

def match_embedding(emb, db_vectors, threshold=0.35): min_dist = float("inf") min_id = None for student_id, db_emb in db_vectors.items(): dist = float(np.linalg.norm(emb - db_emb)) if dist < min_dist: min_dist = dist min_id = student_id if min_dist < threshold: return min_id, min_dist return None, min_dist

3.4 注册流程：别让库里混进质量太差的人脸

再好的比对算法，遇到烂注册照片也没辙。人脸注册模块我设置了最基本的质检逻辑：注册照片的目标人脸置信度必须大于0.9，人脸区域过小或者模糊直接拒绝入库。每个学生注册时采集多张不同角度、不同光线的照片，每张都生成特征向量，最后在数据库里存多条记录。这样识别时只要任意一条匹配成功就算学生本人，能显著降低漏签率。

我在源码里放了一个tools/register_students.py，用法很简单，传一个学生ID和照片路径即可。值得提醒的是，不要在注册时给系统喂网络下载的、分辨率差异很大的照片，同一个学生的多张注册照片应该是现场摄像头拍摄，否则特征分布不一致，后续识别会不稳定。

4. 考勤业务逻辑与时序设计：怎么才算一次有效签到

4.1 考勤规则：不是“看到脸”就算签到

技术模块跑通之后，业务逻辑才是让系统“像人一样判断”的关键。我第一版做出来时，一条考勤记录非常简单：识别到脸就写入“已到”，结果发现完全不能用。比如课间有别的班学生路过教室门口，也会被识别成该班学生并签到成功，这显然不对。

后来我把考勤规则和课程表绑定起来。系统里有一张course表，记录课程代码、课程名称、上课时间、签到开始时间和签到截止时间。比如某节课9:00开始，我可以配置8:45到9:15为签到窗口，只有在这个时间窗口内识别成功才记为“正常签到”，之后识别成功记为“迟到”。如果这个时间段内完全没有识别记录，则标记为“缺勤”。

源码里考的勤状态设计为四种：未签到、正常签到、迟到、缺勤。默认状态是未签到，每日自动生成的考勤记录会先把所有选课学生的状态置为缺勤，识别成功后再根据时间窗口把状态改成正常签到或迟到。这样老师看到的永远是最终结果，不需要自己再去猜“没记录是不是没来”。

4.2 数据库表结构与状态机

数据库我用的是SQLite，主要是为了零配置、单文件、方便迁移。真到多教室并发上报数据时再换MySQL也不难，因为业务逻辑层已经和数据库解耦了。

核心表有三张。student表保存学号、姓名、特征向量；course表保存课程信息和签到时间窗口；attendance_record表保存每一次识别记录和最终考勤状态。另外保留一张capture_log表，记录摄像头每次识别的时间、人脸置信度和处理耗时，用于后期排查问题。

考勤状态更新我设计成一个简单的状态机。当一帧识别成功后，业务逻辑会按这个顺序判断：先检查识别结果是否属于这门课的学生名单，再检查当前时间是否在签到窗口内，然后检查这个学生今天是否已经有一条“正常签到”或“迟到”状态。如果已经存在，则只更新识别次数，不重复写入新记录。这个设计避免了一堂课刷出几十条签到记录的脏数据问题。

4.3 简易活体检测思路：挡住照片和屏幕

教室考勤场景虽然没有金融支付那么高安全要求，但学生拿一张同学的照片或手机屏幕来刷脸的可能性确实存在。完整的人脸活体检测需要专门的RGB和红外深度相机，普通USB摄像头只能做比较基础的动作活体。

我在源码里做的是“多帧动作校验”的简化版。要求被识别者根据屏幕提示完成一次轻微转头，或者等待摄像头连续采集5帧，计算两帧之间的面部关键点位移和遮挡变化。如果特征向量的方差过小，也就是这人动都没动，系统直接判定为照片。对于手机屏幕，屏幕会产生摩尔纹和高光反射，我对图像做了一次傅里叶变换检查高频分量，多数手机屏幕能在这里被拦下。

这个逻辑不是万能的，但能把“拿一张打印照片放在摄像头前”这种最低成本的作弊方式挡掉。如果教室预算允许，后期可以换成带深度传感器的摄像头，活体检测效果会好得多。

4.4 给老师使用的报表与前端

考勤数据只有变成老师看得懂的信息才有价值。后端我用Flask起了两个页面：一个是班级概览页，展示当前这节课的各状态人数卡片；另一个是个人详情页，展示某个学生最近半个月的签到记录和出勤率。

数据库里生成报表的核心是一个聚合查询。按课程分组统计出勤次数、迟到次数、缺勤次数，然后算出勤率。源码里我直接用SQL完成这一步，没有引入额外的ORM查询框架，因为这种复杂查询写原生SQL反而更清晰。

5. 嵌入式设备上的部署与优化：从能跑到跑得稳的完整过程

5.1 模型转换与加速：ONNX-TensorRT/INT8量化

模型在电脑上跑得好，不代表在板子上跑得好。嵌入式部署的第一步是格式转换。我在电脑上用PyTorch训练好的模型先导出成ONNX格式，再把ONNX模型交给RK3588的RKNN工具链，转换成NPU能直接运行的rknn格式。这里有个关键点：转换时要指定量化类型。

浮点模型（FP32）精度最高，但在NPU上速度优势不明显，显存占用也大。FP16可以把模型体积和带宽消耗直接减半，精度损失很小。INT8量化需要先准备一批校准图片，让工具统计每层激活值的范围，然后用整数计算替代浮点计算。实测下来INT8模型在RK3588上推理速度比FP32快两到三倍，准确率下降不到1%，人脸识别这种任务完全能接受。

转换之后我额外做了一次精度验证：把同样的测试集分别喂给原始模型和量化模型，对比输出特征向量之间的余弦相似度。这一步很容易被忽略，但如果不做，模型在板子上很可能出现“误识别率突然变高”的诡异问题。

5.2 推理流水线的多线程设计

嵌入式设备上，最容易犯的错误是把采集、推理、数据库写入全部放在一个循环里串行跑。这样做会导致帧率极不稳定，某一帧处理慢了，后面画面排队，卡顿越来越严重。我在源码里采用了典型的生产者-消费者模型。

摄像头线程负责不停取帧，把帧放进带锁的任务队列。推理线程从队列里取出帧，执行人脸检测和特征提取。业务线程拿到识别结果后，负责更新数据库和签到状态。三个线程通过队列解耦，互不堵塞。队列长度设成5，满了就丢弃最旧的一帧，保证处理实时性。

这个设计还有一个好处：摄像头采集帧率可以稳定在30FPS，推理只处理最新帧，画面没有累积延迟。考勤系统不像实时监控需要保留每一帧，丢掉落后帧不会影响最终识别结果。

5.3 摄像头和图像采集的参数坑

图像采集看起来简单，实际坑最多。USR摄像头插上之后默认参数往往不适合人脸识别，比如曝光过度、白平衡偏色、自动对焦不停抽动。我在源码的config里预留了一组推荐的摄像头参数。手动关闭自动曝光、自动白平衡，改为固定亮度，然后设置焦距为手动。这样做之后，人脸检测率会明显上升。

摄像头安装位置也很重要。最佳位置是门侧墙壁，高度约1.5米，略低于成年人面部，拍摄方向稍微向下倾斜，保证人脸能占到画面的1/8以上。如果摄像头装太高，俯角太大人脸变形严重，识别准确率就会断崖式下跌。我调试时发现角度每增加10度，误拒率要上升好几个百分点。

5.4 稳定性：CPU温度、内存泄漏与断网点

嵌入式设备通常没有专门机房，放在教室墙角，散热条件堪忧。RK3588虽然性能强，但如果长时间满负荷推理，散热片温度能到80度以上，触发降频后帧率会掉一半。解决方法是给板子加一个5V的风扇，并在代码里做定时状态监测，当CPU温度超过75度时适当降低推理频率，给设备“缓口气”。

内存泄漏是Python项目在嵌入式上最容易翻车的点。OpenCV的Mat转numpy、ONNX Runtime的session输入输出、数据库连接的异常使用，都可能悄悄积累内存。我在启动脚本里加了一个定时log内存占用的模块，一旦发现内存占用持续增长，就重点排查哪个模块在泄漏。

最后是断电问题。教室晚上会统一断电，板子直接掉电容易损坏数据库。我接了一个带电源管理的UPS模块，并在代码里监听GPIO断电信号，收到信号后先把内存中的考勤数据flush到磁盘，再执行shutdown。这个操作不复杂，但对连续运行的项目来说属于必修课。

6. 源码结构、复现步骤与踩坑记录

6.1 目录结构和关键文件说明

整套源码的目录结构我尽量保持清晰，模块之间不相互嵌套，方便二次开发。

smart-class-attendance/ ├── configs/ │ └── cfg.yaml # 全局配置：模型路径、课程时间、阈值 ├── core/ │ ├── camera.py # 摄像头采集线程 │ ├── detector.py # 人脸检测模块 │ ├── recognizer.py # 特征提取模块 │ ├── anti_spoof.py # 简易活体检测 │ ├── attendance.py # 考勤业务逻辑和状态机 │ └── pipeline.py # 多线程流水线主入口 ├── database/ │ ├── db.py # SQLite连接和初始化 │ └── schema.sql # 表结构定义 ├── web/ │ ├── app.py # Flask服务 │ └── templates/ # 前端页面 ├── tools/ │ ├── register_students.py # 学生注册 │ ├── calibrate_threshold.py # 阈值校准 │ └── export_report.py # 导出考勤报表 ├── models/ # 放人脸检测和特征提取模型 └── requirements.txt

关键文件里，pipeline.py是整条流水线的粘合层。它把camera、detector、recognizer、attendance串起来，直接运行它就可以启动考勤系统。web/app.py是给老师看的页面，和识别进程可以分开部署。tools下的脚本都是命令行调用，功能相对独立。

6.2 从零跑起来的安装与配置

复现这套系统，我建议按下面三步来做。第一步准备环境，在开发板上装好Ubuntu系统后，执行pip安装依赖。

pip install -r requirements.txt

requirements.txt里的核心依赖有opencv-python、onnxruntime、numpy、flask、pyyaml。模型文件因为体积原因没有直接放Git仓库，需要单独下载DNN人脸检测模型和ArcFace ONNX模型，放到models目录下。

第二步修改configs/cfg.yaml。重点配置三样东西：摄像头编号、课程签到时间窗口、识别阈值。第三步先运行注册脚本，把班级所有学生的照片导入，再运行pipeline.py启动识别。整个过程如果顺利，10分钟就能在板子上看到实时识别和考勤入库效果。

6.3 我踩过的三个典型坑

第一个坑是ONNX Runtime在RK3588上默认走CPU，没有NPU加速。我一开始以为只要安装onnxruntime-gpu就能自动用上NPU，结果完全不对。后来单独装了RKNN-Toolkit2，把模型转成rknn格式，才真正调用NPU。这里提醒一句：不要被开发板厂商的“默认支持AI”宣传带偏，CPU推理和NPU推理是两条不同的部署链路。

第二个坑是人脸检测模型的输出坐标归一化方式不同。有的模型输出值范围是0到1，有的是1到1，有的中心坐标格式和角点坐标格式不同。我第一版里直接把所有模型输出当成0到1的范围处理，结果检测框全乱。所以切换模型前，一定要先读模型文档，看输出层的定义，再用单张图做短测试，验证坐标映射逻辑。

第三个坑是线程安全问题。Python的列表和字典在多线程读写时，如果没有加锁，会出现“识别结果时不时丢数据”的情况。考勤状态更新那部分，我用了一个threading.Lock包住关键代码段，效果立竿见影。源码里凡是涉及共享状态的代码都加了锁，复现时不要觉得多余。

6.4 后续扩展方向

这套系统目前已经能稳定完成“识别、签到、报表”整个闭环，但还有不少可以继续深入的地方。如果后续要把系统扩展到整个教学楼，可以引入MQTT做多设备消息汇聚，把每间教室的考勤数据实时汇总到服务器。如果对识别精度要求更高，可以收集更多教室场景的样本，用自己的数据微调特征提取模型，把特定教室里的戴帽、低头、逆光情况都覆盖进去。

我自己目前正在做的改造是把识别结果按天归档，并接入学校的课程表API，让签到窗口自动跟随调课通知调整，不用人工改配置文件。这些都是在这个源码骨架之上继续演进的方向，也说明当初把边界控制住、把模块解耦清楚，后面扩展起来才会轻松。

本文还有配套的精品资源，点击获取