数据最小必要原则：多收的每一条，都是风险

注册表单上凭空多出一个“生日”栏，起因往往只是运营在群里说一句“加上吧，以后搞活动能用”。加个字段确实不费事，几分钟的事。真过了两年做数据盘点，才发现这一列的填写率低得可怜，后台翻遍了也没几个人查过它。它没被用起来，却一直挂在库里，跟着备份一轮轮走，跟着导出表一份份流转，也跟着隐私声明一项项往外承诺。数据最小必要原则说的就是别让这种事发生，可惜不少团队都是先加上，后想起这条原则。

这词听着像法务写出来的，拆开讲没那么玄。收集的时候先问清楚这东西拿来干什么，能不能少收一点；存储的时候只留用得上的那部分，别整锅端；用完了该清就清，别拿“以后说不定有用”当挡箭牌。合规是它的一面，另一面挺工程化——少存一份数据，就少一份要保护、要备份、要解释的东西。

数据最小必要原则在表单里长什么样

最容易失控的就是注册、下单、报名、留言这几张表单。需求评审里有人来一句“多收几个字段，以后做画像方便”，开发一听，加一列的事，成本几乎为零。收集成本是零，持有成本可不是。字段一加上，就得进数据库、进备份、进日志、进各种导出脚本，出了问题还得有人替它解释。更麻烦的是，很多字段加上去之后就再没人回头看一眼。

落地没那么复杂。能选填的别设成必填，跟业务没关系的干脆不收；地址只要到城市一级的，别追到门牌号；年龄能用区间表达的，别存精确生日。这些不是死规矩，标准只有一条：每个字段都得对上一个具体的用途，对不上就先砍掉。

日志和埋点，是另一个漏水的地方

不少团队对表单还挺谨慎，对日志却大方得离谱。排查问题图省事，把请求体整个打进日志里，URL 上带的手机号、邮箱、会话令牌一起落盘；埋点更是能采就采，用户点了哪个按钮、停在页面上多久，什么都往里塞。日志本身没错，错在没画边界。

打点之前先想一遍：真出故障的时候，你实际要看的是哪几个字段？其余的能脱敏就脱敏，能只留个哈希值就别留明文。访问日志记下 IP 和 UA 通常够用，查询字符串整条落盘的，多半是习惯性动作。保留天数也得定下来，一周、一个月还是三个月，按排查需求来，别默认永久。还有个常被忽略的点，生产环境的日志级别别老开着调试模式，那玩意儿比谁都能装数据。

“先存着，以后可能用得上”最坑人

这句话在会议室里几乎没法反驳，因为反驳的人得为那个“万一”负责。于是历史订单、老版本用户资料、几年前的客服记录，全都躺在库里。真正危险的还不是数据库里那几份，是被导出成表格、散落在个人电脑和网盘里的副本。系统里的数据还能靠权限和审计管一管，一旦导出去，范围就彻底失控，想收也收不回来。

另一个坑是“临时表”。为了跑个数、做个报表，先拉一张宽表出来，说好用完就删，结果一直留着，还越用越顺手。数据这东西，留得越久，被翻出来的概率越大，和账号密码被人惦记是一个道理。

删数据比删代码难，难在没人敢拍板

代码删掉，提交一下就看不见了。数据不行，业务方说报表还要用，财务说对账要留着，开发说不知道哪张表还依赖它。最后变成谁都同意该清，谁也不敢第一个动手。现实一点的做法，是把保留期限写进流程，按数据类型分几档：登录日志、操作日志、订单明细、支付凭证，各归各的周期。到期不是靠人记得，而是靠定时任务去清。

配套还得有一张清单，写清楚哪张表存了什么、谁能访问、多久清一次。这张表不用多漂亮，能让人在出事的时候十分钟内查明白就行。很多事故的根子不在技术，在于没人知道数据到底散落在哪。还有不少表压根没有保留需求，只是没人提出来删。

用户问一句答不上来，就已经晚了

有几个问题是客服最怕遇到的：你们要我的身份证号干什么？这个手机号会保存多久？能不能把我上次填的资料删掉？如果这些答案都得临时拉个群去问，那就说明收集的时候压根没写清楚用途。一份像样的字段说明应该能直接回答：为什么收、存在哪、谁能看、留多久、怎么删。写这份东西花不了多少时间，但它能逼着团队把没必要的字段砍掉。这也是数据最小必要原则真正落地的地方，不是写进制度里，而是写在每个字段的备注里。

能马上动手的几件小事

不用等大项目立项。下一次产品说“顺手加个字段”时，先问一句这数据三年后谁来删。手上所有表单过一遍，把没用途的字段标出来；日志里的敏感字段补一条脱敏规则；把保留期限从口头约定变成配置；导出数据的审批流程收一收。几件事都不大，但每做完一件，将来要解释的东西就少一点。

数据这东西不是攒得多就值钱。多收的每一条，都在给以后埋一个要解释、要保护、要删除的坑。与其等着被用户或者检查的人问上门，不如现在就把该问的问题先问一遍。下次评审会上再有人提“多收一点以后有用”，不妨反问一句：三年后这数据谁来删。