三条底线
- 最小必要：不收集用不上的字段，收集了就负有保管责任；
- 敏感数据加密存：身份证、token、健康信息别明文落库；
- 可被遗忘：用户要求删除时，能真正删（含备份与日志）。
设计时就考虑
- 字段级别区分「公开 / 内部 / 敏感」，敏感字段单独权限；
- 日志别打全量请求体，手机号、密码必须脱敏；
- 第三方共享前想清楚目的与范围。
两个坑
- 匿名化不彻底：删掉姓名仍可能靠其他字段定位到人；
- 备份忘了删：主库删了，备份里还在，等于没删。
数据分级与流转清单
合规落地最有效的工具是一张“数据台账”，至少包含四列：字段、级别、存储位置、保留期限。
- 分级：把数据分为公开、内部、敏感与高敏感四级，不同级别对应不同的加密、脱敏与访问控制要求；
- 最小单元治理：以字段而不是“整张表”为单位评审，能避免“这张表是内部的所以无所谓”这类模糊判断；
- 流转追踪：记录数据从采集到删除经过了哪些系统（日志、数仓、第三方 SDK），任何一个环节都可能成为泄露点；
- 权限与审计：高敏感字段的访问应逐次记录，且默认不可批量导出；
- 定期复审：每季度核对一次台账与实际，删除已无用途的字段与副本，数据留在那里就是风险，不会自己消失。
这套做法不仅满足合规，也能显著降低泄露事件的处置成本：出事时能立刻回答“哪些数据受影响、影响多少人”。
面向开发者的日常检查
- 提交前检查示例数据：测试数据与截图常被直接提交或分享，其中可能包含真实用户信息。应使用合成数据，并在分享前脱敏。
- 谨慎引入第三方依赖：前端引入的分析与埋点工具会把数据发往外部，应明确其采集范围并纳入隐私说明，避免无意中扩大了数据外流的范围。
- 权限默认收紧：内部工具也应默认最小可见范围，需要时再申请，而不是全公司可见后靠自觉不去查看。
- 导出要有记录与限制：批量导出是高风险的敏感操作，应记录操作人、范围与时间，并对单次导出量设置上限。
- 删除请求要可验证：删除后应能确认数据确实不再可读，包括缓存与检索索引，而不只是主存储不可见。
这些检查都不复杂，但需要成为日常习惯。隐私问题通常不是由一次重大错误造成的，而是由许多看似无害的小疏漏累积而成。