为什么这类项目容易翻车
「扫个码填个表，存下来能导出」——这是听起来最没有技术含量的需求，也是实际交付中投诉率最高的一类。
常见问题集中在四个地方：
一、照片存储
身份证照片属于敏感个人信息，不能放在公开可访问的路径下。很多简单实现直接把图片存到静态目录，任何人拿到 URL 就能看。
正确做法是私有存储 + 签名访问：后台鉴权通过后签发一个有时效的临时地址，URL 无法被猜测或长期复用。
二、导出
看起来是「把数据导成 Excel」，实际有几个坑：
- 图片怎么在 Excel 里体现？通常是写入文件名，再单独打包 zip
- 数据量大时同步生成会不会超时？需要评估是否需要异步任务
- 导出的字段要不要脱敏？后台看脱敏，导出给业务方用完整值，这是两套逻辑
三、校验口径
身份证号 18 位格式校验、校验位计算、手机号 11 位校验——这些是基础。
但要注意不要过度承诺：格式校验不等于实名核验。如果要确认「这个身份证号确实是本人的」，需要接实名三要素接口，那是另外的对接工作和费用。
四、重复提交
这里必须提前跟甲方确认清楚：同一个人能不能提交多次？
- 如果业务上允许，那每条记录独立编号，不做拦截
- 如果不允许，需要设计去重规则（按手机号？按身份证？）和冲突处理
这一条没谈清楚，上线后必然扯皮。
典型的系统结构
H5 填写端
├─ 表单（固定字段 / 动态配置）
├─ 格式校验与必填拦截
├─ 照片上传（压缩 + 格式校验）
└─ 提交成功页（订单号可复制）
后台管理端
├─ 登录与鉴权
├─ 列表（分页、脱敏展示）
├─ 多条件搜索与时间筛选
├─ 详情（完整字段 + 照片预览）
└─ 导出（Excel + 图片包）
服务端
├─ 订单号生成（唯一索引保证）
├─ 私有存储与临时签名 URL
├─ 频控与防刷
└─ 导出任务
工期与规模
这类系统功能边界清楚、技术风险低，正常规模在 10–15 个工作日内可以完成开发和部署。
影响工期的变量主要是：
- 字段数量和校验规则的复杂度
- 是否需要接第三方接口（OCR、实名核验、短信）
- 甲方的环境是否就绪（服务器、域名、备案、SSL）
最后一条经常被低估。如果甲方环境没准备好，开发完了也部署不了，这部分等待时间不应该计入开发工期，合同里要写清楚。
适合什么场景
如果需求是「收集一批信息，后台能查能导出」，且不需要复杂的审核流转和多角色权限，那这类系统是最优解——比买现成的 SaaS 便宜（数据在自己手上），比定制大型系统快得多。