这是我在 2021 年参与的一个实际项目。项目围绕新乡市重点场所的信息管理展开，包含场所申请、二维码生成、人员扫码登记、行业规则、分级权限和统计分析等功能。相比单纯练习技术 Demo，它第一次让我真正面对业务规则、交付期限与多人协作。
现在回头看，项目最难的并不是某个页面或接口，而是如何把行业、区域、角色和数据范围组合成一套能解释、能实现、也不容易出错的权限逻辑。
一、项目背景
2021 年 4 月中旬，疫情防控进入常态化阶段。学校、医院、菜市场和部分休闲娱乐场所逐步恢复开放，但人员出入仍需要登记与健康信息管理，“出入请扫码”也成为当时常见的管理方式。新乡市重点场所管理项目正是在这一背景下产生。
这篇文章记录的是当时的项目背景与实现方式，不代表今天仍在使用相同的防控政策、数据字段或管理流程。
二、项目需要解决什么问题
重点场所工作人员管理
- 收集重点场所工作人员当日登记与身体状况信息。
- 场所管理员查看人员登记状态和汇总统计。
- 对没有按时完成登记的工作人员发送短信提醒。
隔离点管理
- 维护隔离点、隔离房间以及相关人员信息。
- 区分工作人员与隔离人员使用的二维码及登记流程。
行业规则管理
- 由行业管理员维护对应行业的管理要求。
- 根据行业与区域范围查看场所和人员登记情况。
- 维护当时业务中使用的有效核酸时间等配置。
三、系统角色与业务对象
项目中同时存在场所、行业、行政区域、部门、角色、管理员、工作人员和隔离人员等对象。它们不是简单的一张用户表加几个菜单权限，而是共同决定一个人可以管理什么。
行业：38 类重点场所
区域：市 → 县区 → 乡镇
角色：超级管理员 / 行业管理员 / 区域管理员 / 场所负责人
对象：普通重点场所 / 隔离点
人员：场所工作人员 / 隔离人员
最终数据范围 = 行业范围 ∩ 区域范围 ∩ 角色权限菜单可见不等于数据可见。真正复杂的是：即使两个管理员看到同一个页面，他们能够查询、导出和修改的数据也可能完全不同。
四、移动端流程
移动端采用 Vue 3，主要承担场所申请和人员扫码登记。
1. 申请场所二维码
- 场所负责人扫描平台统一提供的注册二维码。
- 填写行业类型、所属区域、单位、负责人姓名和电话等信息。
- 普通场所申请工作人员二维码。
- 隔离点分别申请工作人员二维码和隔离人员二维码。
- 后台审核通过后，二维码才可以正式投入使用。
2. 工作人员扫码登记
工作人员每日出入时扫描所属场所二维码，填写姓名、手机号码、身份证号码、当日体温和工作区域等当时业务要求的信息。隔离点的登记表还包含相关症状信息。
3. 隔离人员登记
隔离点使用独立二维码区分人员类型，避免工作人员与隔离人员进入同一套登记流程，也方便后台按对象分别查询和统计。
五、管理端功能
管理端使用 Vue 3，并基于 gin-vue-admin 的现有能力进行开发。框架提供了后台项目常见的用户、角色、菜单和基础 CRUD 能力，项目工作主要集中在具体业务规则和数据权限上。
项目截图：管理端总览
1. 用户与权限
- 超级管理员配置 38 类重点场所的总管理员权限。
- 行业或区域管理员在自己的管理范围内创建下级账号。
- 角色决定功能权限，部门层级与行业归属共同决定数据范围。
2. 场所与行业
- 审核场所申请，并支持查询、新增、编辑、删除和导出。
项目截图：场所管理
- 维护行业分类及当时业务要求的相关配置。
项目截图：行业管理
3. 人员与扫码记录
- 查看场所工作人员及其每日登记状态。
- 查询单次扫码详情，并按行业、区域和场所筛选。
项目截图：场所人员管理
4. 统计分析
系统对登记完成情况进行汇总，方便管理员发现未登记人员，并按权限范围进行监督和提醒。
六、核心业务流程
平台提供注册入口
↓
场所负责人提交申请
↓
后台按行业与区域审核
↓
生成并启用场所二维码
↓
工作人员或隔离人员扫码登记
↓
系统保存记录并进行汇总
↓
管理员在权限范围内查询、统计与提醒二维码只是入口，真正决定流程能否成立的是二维码背后的场所状态、人员类型、行业配置和审核状态。二维码即使被转发，也必须通过后端规则判断当前请求是否有效。
七、项目中的几个难点
难点 1：二维码生成与展示
不同场所类型需要生成不同用途的二维码，并在审核通过后才能启用。二维码内容、场所状态和登记页面之间需要保持一致，不能只在前端控制是否可见。
难点 2：大文件上传
项目还涉及大文件上传。相比普通表单，它需要考虑大小限制、上传进度、失败重试、服务端校验与最终文件状态，不能把上传成功简单等同于浏览器请求结束。
难点 3：多维权限
管理员权限由角色、角色级别、所属行业和部门层级共同决定。一个管理员能看到哪些菜单、哪些场所和哪些扫码记录，需要在接口层统一计算。只在前端隐藏按钮并不能阻止越权访问。
canAccess(user, record) =
roleAllows(user.role, action)
&& industryContains(user.industryScope, record.industry)
&& regionContains(user.departmentScope, record.region)难点 4：时间紧、任务重
商业项目有明确交付时间。那段时间经常能听到催进度的电话，团队也经历了持续加班，甚至通宵。短期内确实推进了交付，但回头看，加班并不能替代清晰的需求边界、任务拆分和风险预警。
八、当时没有想透的困惑
功能做完，是否等于问题解决
项目可以生成二维码、收集登记信息和输出统计，但真正的管理效果还取决于信息是否真实、人员是否愿意配合、异常是否有人处理，以及线下流程能否跟上。软件只能承载流程，不能自动保证流程有效。
收集越多信息，是否就管理得越好
当时的表单包含手机号、身份证号、体温和症状等敏感信息。工程上不仅要考虑“能不能收集”，也要考虑哪些字段确实必要、谁可以查看、保存多久、如何脱敏以及何时删除。数据越多，责任和风险也越大。
通用后台框架能解决多少问题
gin-vue-admin 覆盖了大量后台基础能力，显著减少了重复开发。但框架提供的是工具，行业、区域和部门交叉形成的数据权限仍需要团队理解业务后自行建模。越复杂的权限，越不能只依赖页面配置。
赶进度与留质量如何平衡
时间紧时，团队容易把“先完成”放在第一位，却没有及时沉淀决策、测试边界和项目总结。短期节省的时间，往往会在后续回忆、排错和交接时重新付出。
九、如果重新设计，我会重点关注什么
- 把角色权限与数据权限拆开，使用统一的后端授权策略。
- 为行业与区域范围建立清晰、可测试的继承规则。
- 对身份证号、手机号和健康信息执行最小化、脱敏与访问审计。
- 二维码使用不可猜测标识，并由后端校验状态、用途和有效性。
- 短信提醒设计幂等、频率限制、失败重试和发送记录。
- 导出操作单独授权，限制范围，并记录操作人与导出条件。
- 为关键流程补充自动化测试、异常状态和数据恢复方案。
- 在项目结束时立即完成架构、权限、问题和经验复盘。
十一、收获与不足
收获
- 第一次参与商业性质的真实项目，对需求、分工、开发和交付流程有了完整认识。
- 在实际业务中使用 Vue 3 和 gin-vue-admin，比脱离场景练习提升更快。
- 理解了角色、部门、行业和数据范围共同构成的复杂权限模型。
- 团队配合顺畅，学长们在流程和交付上提供了很多帮助。
不足
- 当时对技术栈还不够熟练，需要边做边补基础。
- 对商业项目流程缺少经验，需求和进度判断不够主动。
- 没有在项目结束后立即总结，后来回忆细节花费了更多时间。
- 更关注功能实现，对数据最小化、权限审计和长期维护思考不够。
十二、结语
这个项目的技术实现并不算最难，但它让我第一次清楚地意识到：真实系统的复杂度往往不在代码数量，而在业务边界、权限关系、数据责任和交付协作。二维码、表单和后台页面很容易被看见，真正需要反复推敲的，是谁能做什么、能看到什么，以及系统为何要收集这些数据。