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