课堂点名系统开发实战：Flask+SQLite二维码签到与防代签

200人的大课，老师拿着花名册一个一个喊名字，底下一片"到"声，后排还有人代答。5分钟过去，名单念了一半，老师无奈地说："刚才后半截没听清，咱们再从头来一遍。"这不是段子，是我帮朋友代课后的真实感受。期末统计平时分的时候，助教从一沓纸质签到表里翻名字，翻到怀疑人生。

也就是从那一刻起，我决定做一个课堂点名系统，把点名这件事从"每次5分钟的体力活"变成"30秒的数据采集"，顺便把考勤数据沉淀下来，跟平时分、课堂表现挂钩。这个项目整体是一个前后端分离的 Web 应用：老师端可以创建课程、导入学生花名册、发起点名、查看考勤统计；学生端扫码或者在点名页面上确认签到；后端负责二维码生成、签到时间校验、防重复提交和考勤数据存储。我用的是 Python Flask + SQLite + 轻量前端，整体部署成本很低，普通笔记本或者一台校园服务器都能跑起来。

如果你正在做课程设计，或者想在班级/团队里落地一套考勤工具，下面这套实现思路和排查记录应该能帮你少走不少弯路。时间戳错乱、SQLite 并发写入锁死、二维码被转发代签——每一个都是我实际踩过的坑，我会把完整排查过程写出来，而不是只丢结论。

1. 点名这件小事，为什么值得做一个系统

1.1 传统点名的四个失控瞬间

先说传统点名到底哪里"失控"，不把痛点想清楚，后面做的系统大概率只是换个形式重复老问题。

第一个问题是时间成本太高。大课堂点名很容易吃掉5到10分钟，一学期下来，光点名就浪费了好几节课的课时。碰上那种念到一半有人起哄、老师重新念的场景，时间直接翻倍。

第二个问题是身份核验不可靠。纸质花名册靠"听声辨人"，代答、替答、漏答太常见了。我在大教室里见过最离谱的操作，是一个人压着嗓子替三个人答"到"，后排的同学根本听不出区别，老师更是看不清脸。点名这个动作本身变成了形式，失去了它应有的约束力。

第三个问题是数据没法沉淀。纸质签到表最后要么扔进抽屉，要么变成期末统计时的一张张模糊照片。某学生缺勤几次、迟到几次、请假几次，全靠助教手工誊录。誊错一行，一个学生的平时分可能就变了。出勤数据是评价学生过程表现的依据，但纸质记录几乎没法做任何有效统计。

第四个问题是被忽视的：过程数据没有反馈价值。一份考勤记录如果能按时间、按课程、按个人拆开看，它其实是很好的教学数据。举个例子，某学生前6周出勤率直线下降，大概率是状态出问题了，任课老师如果能看到趋势，可以提前介入。但纸质记录做不到这些，数据躺在纸上等于没有数据。

所以我给自己的定位不是"做一个电子点名工具"，而是"把考勤变成可查询、可导出的结构化数据"。这个定位一直指导着后面的表结构设计，后面的所有功能都是为了这个目标服务的。

1.2 这个系统到底要做什么

动手写代码前，我先列了一份需求清单。这份清单后来被证明是整个项目里最值钱的一步——课程项目最容易犯的错就是一上来就写代码，写了一半发现缺功能，回头改表结构，改得想哭。我最后悔的不是没早点写，而是没早点把需求写细。

我的核心功能清单是这样的：

1. 老师可以注册账号、登录后台；
2. 老师在后台创建课程，并通过 Excel 导入学生名单；
3. 每次上课时，老师发起一次点名，系统生成带有效期的二维码；
4. 学生扫码或访问签到页确认签到，系统记录签到时间；
5. 老师可以按课程、按学生查看出勤统计，并导出 Excel；
6. 助教或老师可以为特殊情况补签，补签必须留备注，不能学生自己改。

非功能性需求我也列了几条：

• 部署要简单，最好一台普通电脑就能跑，别搞复杂环境；
• 学生端操作成本要低，不需要装App，扫码进浏览器直接点一下；
• 要能防代签，这是整个系统最容易翻车的地方；
• 数据要能导出，后续要跟成绩系统对接。

有了这份清单，后面所有技术选型都有依据了，不会被花哨的方案带跑。

2. 技术选型：为什么我没选人脸识别，也没选GPS定位

2.1 主流方案对比，我为什么最终选了二维码

敲代码之前，我花了大概半天时间把主流的点名方案过了一遍。这里先放一张对比表，再解释我的判断逻辑，因为很多人一上来就会被"智能化方案"吸引，但落地之后才发现成本扛不住。

可能有人会问：人脸识别现在这么成熟，为什么不用？我的判断依据有两个。

第一是使用门槛。人脸识别点名需要提前给每个学生采集照片、建立人脸库。一门课动辄一两百人，这个前置成本已经超过它节省的时间。而且考勤数据本身涉及隐私，拍下的面部数据一旦管理不当，风险远大于它解决的那点"代签"问题。

第二是误识别成本。人脸识别做不到百分百准确，尤其是教室这种光线不均匀、人坐得远的场景。一旦误识别，学生明明到场却显示缺勤，老师还得反过来解释和纠正，反而增加了沟通成本。

GPS和蓝牙定位方案就更只是看着热闹。教学楼里 Wi-Fi 信号交错，定位跳动大，而且虚拟定位工具遍地都是，学生想绕过太容易了。真用起来会陷入"理论可行、实战被绕"的尴尬。

最后我定的方案是：二维码+服务端时间校验+现场助教辅助核对。二维码方案的本质不是从物理上防止转发，而是把转发成本抬高，同时通过短有效期、IP 限制、投屏核对等手段，把代签控制在可接受的范围内。这个方案解决的是"90% 的问题"，剩下 10% 交给现场助教盯一眼，整体性价比很高。

2.2 具体技术栈以及我的选择理由

技术选型同样遵循"够用且好维护"的原则，下面逐项说清楚。

后端用的是 Python Flask。Flask 比 Django 轻，路由和视图写起来直观，一个文件能跑起来，非常适合课程级别的项目。而且 Flask 的扩展生态很完整：登录用 Flask-Login，数据库操作用 SQLAlchemy，生成二维码用 qrcode 库，导出 Excel 用 openpyxl，都是久经考验的库。这些库的文档和社区资料非常充足，真出问题也能快速查到解决方案。

前端分成两块。管理端用 Vue 3 + Element Plus，因为管理页需要大量的表格、表单、对话框，用现成的组件库能省下大量时间，视觉上也干净。学生签到页则用原生 JavaScript，只有一个按钮和一行状态文字，用原生代码反而更稳，不用等框架加载完才能操作。签到场景里，少一秒钟加载时间，体验就好一截。

数据库用 SQLite。我是刻意没有一上来就上 MySQL 的，因为教室点名这个场景，实际并发量并不大，SQLite 完全够用。它还有两个明显优势：一是零配置，不用单独装数据库服务；二是备份就是一个文件，学期末归档特别方便。在我后面的压测里，WAL 模式下能扛住 60 人同时签到，而一个班往往也就一百来人，实际同时挤在签到页的其实就头一分钟那几十个人。

认证体系选了 Flask-Login + Session，没有用 JWT。这个项目是传统服务端渲染 + API 的混合模式，Session 的方式已经足够安全，也避免了 JWT 在移动端刷新、过期管理的额外复杂度。用 JWT 不是不好，是这里不需要。

这套组合在校园网环境下跑得非常稳，而且任何一个环节出了问题，网上资料都很好查。课程项目和外包工程有一个重要区别：可维护性和可解释性，比性能更重要。你的代码是要给同学讲解、给老师验收的，用一堆复杂组件堆出来的酷炫系统，如果自己都讲不清原理，反而会打折扣。

2.3 一些我不推荐做的事

我见过不少同学做类似系统时，一上来就上 Redis 缓存、RabbitMQ 消息队列、Docker K8s 部署，整套东西看着阵容豪华，实际上把项目复杂度推高了好几倍，最后连自己都讲不清楚。点名系统的真正瓶颈不在并发和分布式，而在"签到链路是否闭合、防代签是否有效、数据统计是否准确"这三个核心问题。这三个问题用再简单的技术栈也能解决；反过来，再豪华的架构也救不回一个设计混乱的签到链路。

另外还有人喜欢在项目里堆一堆"看起来很有必要"的字段，比如注册时要求学生填手机号、身份证号、寝室号，这些都是隐私负担。我的原则是：只需要老师和学生的名字、学号/工号、登录密码就够用，多余字段一律不加。

3. 数据库设计：我用五张表，而不是一张大宽表

3.1 表结构与字段说明

数据库是整个系统里我花时间最多的地方，因为它直接决定了后面的功能能不能顺畅扩展。我最终设计了五张表：

几个关键设计的思路我展开说说。

users 表的 role 字段，用 "teacher" 和 "student" 区分，而不是拆成 teacher 表和 student 表。原因很简单：老师和学生除了核心操作不同，登录、改密码、资料维护这些逻辑完全是一致的。拆成两张表反而会让权限系统变得僵硬。如果未来有助教角色，只需要加一个角色枚举值，不需要动表结构。

attendance_sessions 表的意义很多人会忽略。初学者往往直接做一个"考勤记录表"，字段就是 course_id、student_id、status、time。这个设计有个致命问题：你无法表达"某一次点名"这个整体概念。比如这一次点名是几点发起的、签到截止时间是多少、签到码是什么、是谁发起的。没有 session 表，你连"这节课多少人出勤"都查不出来，只能靠日期去猜。所以我把"点名会话"单独抽成一张表，每次老师发起点名就插入一条记录，学生签到则挂在 session_id 下面。这样统计"第12周这次课的出勤率"，就是查一个 session 的全部记录，非常自然。

attendance_records 表我建了 (session_id, student_id) 的联合唯一约束。这个约束保证了同一个学生在一轮点名中只能产生一条考勤记录，是防重复签到的最后一道代码防线。就算有人绕过前端直接调接口，也插不进去第二条数据。

另外还有一个实际经验：建议在 attendance_records 表的 sign_time 字段上建索引。因为统计个人出勤记录和按时间范围导出都是用这个字段来排序和筛选的，没有索引，数据量大了之后查询会明显变慢。虽然几百条记录感觉不出来，但这是一张会持续增长的表，早点建索引没坏处。

3.2 踩过的坑：先写了一张大宽表

这里要特别说一个反面教材。我第一次设计这个系统的时候，为了省事，把 course、student、attendance 全塞进了同一张表，结构大概是这样的：

code复制id | course_name | teacher_name | student_name | student_no | date | status | sign_time

结果显而易见：一门课有200个学生，course_name 和 teacher_name 就在表里重复了200次。老师改名，就要 UPDATE 200 行；学生换课，就要动一大堆历史记录。更麻烦的是，我想统计"这学期某门课每周出勤趋势"时，因为日期和课程揉在一起，SQL 写得极其痛苦，写到最后自己都分不清 SELECT 到底要按哪个字段分组。

后来我把这张表拆开，才真正意识到一个老生常谈的原则：先画实体关系，再写建表语句。用户、课程、选课关系、点名会话、考勤记录，这五个实体之间的边界清晰之后，建表就是顺理成章的事。用最初那版宽表，做十个功能有九个在给自己挖坑。这个教训我后来讲给好几个做课程设计的同学听，他们也都栽在同样的地方。

4. 核心功能实现：从登录到签到的完整闭环

4.1 登录与会话管理

教师和学生共用一个登录逻辑。我用 Flask-Login 管理登录状态，在此基础上封装了一个角色校验装饰器，用来保护老师专属接口：

python复制from functools import wraps
from flask_login import current_user, login_required
from flask import abort

def role_required(role):
    def decorator(func):
        @wraps(func)
        @login_required
        def wrapper(*args, **kwargs):
            if current_user.role != role:
                abort(403)
            return func(*args, **kwargs)
        return wrapper
    return decorator

这个装饰器的用法很简单：给创建课程、发起点名、考勤统计这些接口都加上 @role_required("teacher")，学生身份访问就直接返回 403。权限判断一定不能只在前端做，因为前端代码是可以被绕过的，接口层必须兜底。这是我最初版本踩过的坑，当时只在页面里隐藏了"发起点名"按钮，结果有学生直接拿接口地址访问，照样能发起点名，好在只是测试环境。

4.2 发起点名：生成一个会失效的二维码

每次老师点击"开始点名"，后端做三件事：生成一个随机字符串 qr_secret，用 secrets.token_urlsafe(16) 保证不可预测；把课程 ID、当前时间、qr_secret 写入 attendance_sessions 表，设置过期时间（默认60秒，可配置）；把包含 session_id 和 secret 的签到链接返回给前端，前端把它渲染成二维码投屏展示。

为什么签到链接里不能只放课程 ID？因为课程 ID 是固定的，学生只要记住这个 ID，以后每节课都能直接访问签到页，那就不叫点名了。加入 qr_secret 这个一次性随机数之后，每次点名的链接都不同，旧链接过期后立即失效，这是第一道防转发屏障。

核心代码示意如下：

python复制import secrets
from datetime import datetime, timedelta

def create_attendance_session(course_id, expire_seconds=60):
    session = AttendanceSession(
        course_id=course_id,
        start_time=datetime.now(),
        expire_time=datetime.now() + timedelta(seconds=expire_seconds),
        qr_secret=secrets.token_urlsafe(16)
    )
    db.session.add(session)
    db.session.commit()
    sign_url = f"/sign/{session.id}?s={session.qr_secret}"
    return session, sign_url

expire_seconds 我没写死，因为不同老师习惯不同。有的老师喜欢 30 秒快速点名，有的希望给学生多一点反应时间，放到课程设置里让老师自己配就行。这个参数后来被证明是使用率最高的配置项之一。

4.3 学生扫码签到：四步校验逻辑

学生的签到接口是整个系统最核心的一段程序。我把它拆成四步：

1. 判断 session 是否存在，不存在直接返回"点名已结束"；
2. 校验 qr_secret 是否匹配，防止学生把链接里的参数改了；
3. 判断当前时间是否在 start_time 和 expire_time 之间，过期后拒绝签到；
4. 检查 (session_id, student_id) 是否已有记录，有则拒绝重复提交，提示"你已签到"。

python复制@attendance_bp.route("/sign/<int:session_id>", methods=["POST"])
def sign(session_id):
    data = request.get_json()
    secret = data.get("s", "")
    session = AttendanceSession.query.get(session_id)
    if not session:
        return {"ok": False, "msg": "点名会话不存在"}, 404
    if secret != session.qr_secret:
        return {"ok": False, "msg": "签到链接无效"}, 403
    now = datetime.now()
    if now < session.start_time or now > session.expire_time:
        return {"ok": False, "msg": "不在签到时间范围内"}, 403
    record = AttendanceRecord.query.filter_by(
        session_id=session_id, student_id=current_user.id
    ).first()
    if record:
        return {"ok": False, "msg": "你已签到，请勿重复提交"}, 200
    new_record = AttendanceRecord(
        session_id=session_id,
        student_id=current_user.id,
        status="normal",
        sign_time=now,
        ip=request.remote_addr
    )
    db.session.add(new_record)
    db.session.commit()
    return {"ok": True, "msg": "签到成功"}

状态字段我用的字符串 normal / late / leave / absent，而不是数字。虽然字符串稍微占点空间，但可读性极好，导出报表时不用再写一层翻译逻辑。对一个小型系统来说，字符串状态的维护成本远低于数字状态的映射成本。

这一步还要注意一个细节：数据库操作和数据校验必须放在事务里，任何一步校验失败都不能写入记录。最开始我没用唯一约束，只是在代码里先查再插，结果并发请求时出现了极低概率的重复记录，后来加了唯一约束才算根治。

4.4 统计看板与导出

统计功能我做了三个维度：按课程看每次课出勤率，按学生看个人出勤记录，按日期看整体趋势。三个维度的核心逻辑都是"先按维度分组，再聚合计数"。

比如统计某门课程各次点名的出勤率，SQLAlchemy 查询大概长这样：

python复制from sqlalchemy import func

rows = db.session.query(
    AttendanceSession.id,
    AttendanceSession.date,
    func.count(AttendanceRecord.id).label("signed_count")
).outerjoin(
    AttendanceRecord,
    (AttendanceRecord.session_id == AttendanceSession.id) &
    (AttendanceRecord.status.in_(["normal", "late"]))
).filter(
    AttendanceSession.course_id == course_id
).group_by(AttendanceSession.id).all()

这里要注意一个细节：为什么用外连接而不是内连接？因为有可能存在"发了点名但没人签到"的极端情况，内连接会把这种 session 过滤掉，导致统计缺失。外连接加计数，才能保证每次点名都有一条统计行。

导出功能我用 openpyxl 直接生成 Excel。导出时必须先把数据按 course_id 和 date 排序，否则老师打开表格看到一团乱麻，体验会很差。这个排序逻辑虽然简单，但我最初版本漏掉了，被试用老师吐槽"这表格没法用"。另外，导出的文件名里最好带上课程名和日期范围，比如"软件工程_2024上学期考勤_20240901-20250110.xlsx"，这样归档时不会混淆。

5. 实测遇到的三个怪问题，以及完整的排查过程

这一节我特意放在最后面写，因为这三个问题都不是翻文档就能避开的，它们只在真实运行时才会暴露。每一个我都按排查链路写清楚，你可以直接复现这个排查思路。

5.1 时间戳全乱了：本地正常，部署上服务器就迟到8小时

系统上线后第一周，老师和学生反馈说"签到时间全都差了8小时"。学生在晚上8点签到，后台记录显示的却是中午12点。我当时第一反应是前端传时间格式不对，因为那天刚改过签到页的代码。

排查链路是这样的：

1. 先在本地复现，结果本地完全正常，这就排除了前端代码问题；
2. 到服务器上直接查数据库里的 sign_time，发现确实差了8小时，证明写入时就已经错了；
3. 在服务器上执行 date 命令，发现服务器系统时间本身是对的；
4. 于是怀疑 Python 进程的时区设置，最终定位到环境变量 TZ=UTC，Flask 内部一直用 UTC 时间；
5. 把服务器环境里的时区变量改为 Asia/Shanghai 并重启服务，问题消失。

这个坑的根源是我自己部署时在环境变量里把时区设成了 UTC，本意是"为了统一标准"，结果给自己挖了坑。除了改环境变量，我还做了一个分层约定：数据库统一存 UTC 时间，页面展示的时候统一转成东八区。这样即使以后服务器搬到别的区域，数据也不会乱，而且有迹可循。这里我强烈建议任何涉及时间的 Web 项目都采用这个约定，它省去了后续一大半的时间错乱排查。

5.2 30个人同时签到，SQLite 直接报 database is locked

第二次事故发生在一次120人的课堂上。前20个人签到很顺利，到了第21个人开始，前端陆续报 "database is locked"。我一开始以为是代码里事务没提交，检查了一遍发现每个 db.session.commit() 都正常。后来去翻了 SQLite 官方文档，才意识到这是写锁冲突。

SQLite 同一时刻只允许一个写事务，当多人同时点击签到，多个写请求挤到数据库层，后到的请求会立刻收到锁错误。解决方式是启用 WAL 模式：

python复制from sqlalchemy import event
from sqlalchemy.engine import Engine

@event.listens_for(Engine, "connect")
def set_sqlite_pragma(dbapi_connection, connection_record):
    cursor = dbapi_connection.cursor()
    cursor.execute("PRAGMA journal_mode=WAL")
    cursor.close()

WAL 模式让读操作和写操作可以并行，同时允许多个写请求排队而不是立即报错。启用之后我压测了一下：60 人同时点击签到，基本都能在 2 秒内完成写入，不再报锁错误。

这里分享一个排查经验：遇到这类问题，一定先看完整错误日志，再去查官方文档，最后才搜社区。如果你一上来就搜"SQLite database is locked"，大概率会看到一堆让你换成 PostgreSQL/MySQL 的答案，听起来很吓人，但这个问题其实只差一行 PRAGMA 配置。先理解数据库本身的机制，再判断要不要换方案，能省掉很多无谓的架构升级。

5.3 二维码被转发，代签防不住

最头疼的是这个问题。一开始我把二维码有效期设成 60 秒，以为够短了。结果发现班级群里照样有人转发——在秒数还剩 40 多秒的时候截图发群，群里的同学点开链接依然能签到成功。这证明单靠短有效期是不够的，转发是在有效期内完成的，根本没有触发过期逻辑。

我最终的防代签组合拳是这样的：

• 二维码有效期从 60 秒缩短到 30 秒，并增加"刷新二维码"按钮，老师可以在大屏上随时重新生成；
• 同一 IP 在同一个 session 内只能签到一次，记录 IP 并做重复性判断；
• 签到时必须登录，不允许游客直接填学号，这个在最初版本就做了；
• 最关键的一点：老师端可以设置签到后 10 秒内在教室投屏上滚动显示已签到学生名单，谁到了谁没到一眼就能看出来。

最后一条其实是防代签最有效的措施，因为它从"技术对抗"变成了"现场威慑"。学生看到投屏上名字实时滚动，就会意识到代签会被当场发现，这比任何加密算法都管用。实测下来，这一个功能让代签率肉眼可见地下降了。

6. 从"能跑"到"好用"：我后来补的几个细节

6.1 投屏实时反馈

第一次用系统点名，老师反馈说学生扫完码不知道自己签上了没有，没签上也是一脸懵。这促使我加了投屏模式。老师发起点名后，可以投屏展示一个页面，学生签到成功后，页面上的名字会实时增加，并打上绿色的对勾。

这里没有用 WebSocket，用的是最简单的 1 秒一次轮询接口。原因很朴素：教室网络环境下，1 秒的延迟完全可接受，而 WebSocket 需要维护长连接、处理断线重连，复杂度高，收益却很低。对于这个场景，轮询已经足够"实时"。有时候"最先进"的方案不是最优解，"最合适"的才是。

6.2 补签与请假的合理流程

考勤系统里，"异常处理"反而成为最容易被忽略却最重要的功能。我在设计补签流程时遵循一个原则：正常签到走学生端口，补签和请假只开放给老师或助教。

老师选择某个学生后，必须填写备注才能提交，比如"迟到10分钟，人已到课""病假，附请假条"，然后状态标记为 late 或 leave。这样设计有两个目的：一是防止学生自主改签，否则代签防了也白防；二是保证考勤数据的可追溯性，期末有争议时能拿得出依据。补签时间也会记录，方便老师查看操作痕迹。

6.3 学期末数据归档与隐私

每学期结束后，我会导出一份全量考勤存档，然后清空当学期的考勤会话记录，保留课程基本信息和学生选课关系。这样数据库不会越积越重，查询速度始终保持稳定。归档文件统一按"学期_课程名_考勤记录.xlsx"命名，放到独立的归档目录里。

考勤数据涉及学生个人信息，我处理时有一条底线：只存点名和签到所需的最少字段，绝不额外采集。系统里没有手机号、身份证号、家庭住址之类的字段，因为一旦数据泄露，这些字段带来的风险远大于它们带来的便利。拿来做课程设计时，这一点也经常被老师问到，我每次都把这条设计原则讲清楚，老师普遍认可。

7. 如果再让我做一遍，我会在哪些地方做得不一样

7.1 早一点做接口和页面分离

最初版本是 Flask 直接渲染 Jinja2 模板，前端逻辑写在 Python 代码里。后来加了很多交互功能，比如投屏刷新、导出预览、状态筛选，Jinja2 模板越来越臃肿，最后不得不花两个晚上改成了 Vue 3 前端。如果一开始就前后端分离，虽然初期开发会慢一点，但后续调整会轻松非常多。技术债就是这样，早还晚还都得还，晚还的利息更高。

7.2 把自动化测试补上

说实话，这个项目的自动化测试覆盖率是比较低的。重构期间，我全靠手动点点点来回归，结果好几次把正常的签到流程点坏了。如果你要长期维护这个系统，我强烈建议至少给签到接口的四个校验逻辑补上单元测试，尤其是"重复签到""过期签到""伪造 qr_secret"这三个边界场景。测试代码写起来很枯燥，但它能在你大改代码时兜住底线，不用每次改完都靠人工把所有流程过一遍。

7.3 尽早问问真实使用者的意见

我最开始设计的统计页面，是按照"我以为老师想看什么"来做的。结果用了两周后老师跟我说，他平时根本不看那堆折线图，他只关心这节课谁没到。后来我把列表强化、图表弱化，使用率立刻上来了。这个教训比任何技术细节都重要：工具是做给使用者用的，不是做给自己的技术自嗨。尽早拿给真实使用者试用，听他们的反馈，比闷头加一百个你觉得酷炫的功能有用得多。

最后分享一个小技巧。如果你打算把这个系统作为课程设计或者开源项目，一定要在 README 里写清楚部署步骤，尤其是时区环境变量、WAL 配置、二维码防转发的排查说明。我后来把这次开发的几个坑整理成一个"踩坑记录"文档放进项目，提交到开源社区之后收到了不少同学反馈，说光看这个文档就帮他们省了两三天时间。这个习惯我一直保留到现在，每次做项目都会顺手把坑记下来，既是对自己负责，也能帮到后来人。