数据最小化三原则，核心只有一句话

能不收就不收——数据最小化三原则的核心，就这几个字。听着像合规部门才关心的术语，落到建站和运维上一点都不玄：数据收进来之前先问一句，不收它，业务还转不转得动？转得动就别收；实在转不动再收，但收完得想清楚什么时候扔、谁能看。收多少、留多久、给谁看，这三件事串起来才是完整的，缺一块都等于没做。

数据最小化三原则的核心，是「不收就不会丢」

出过事的库翻多了会发现一个规律：真正要命的字段，往往不是业务天天在用的那几个。身份证号、家庭住址、紧急联系人、手持证件照，一堆注册时随手加的栏，几年没人读过一次，却稳稳躺在表里等着被人拖走。这些字段本来就不该进库。不收，就没有泄露风险，不用做脱敏、不用做加密、不用为了它写一份评估报告。省下的不是钱，是后面一连串说不清的麻烦。

所以别把最小化理解成「把数据删干净」，它更像一道门槛，卡在数据进门之前。门卡住了，后面所有环节都会轻一点。

表单少问两栏，用户和风险都松一口气

注册页面是最容易失控的地方。手机号、生日、公司名、职位、来源渠道，一列排下来看着挺专业，其实大部分没人用。邮箱能发信、能找回密码，核心流程就跑通了，多问的那几栏用户填的时候会犹豫，转化掉不掉不好量化，但数据库里多出来的敏感列是实打实的。真要发券、要办活动，下一层再单独收，别在注册这一步一次性囤满。

还有一个细节：很多表单把「选填」标成了必填。这个改起来最快，成本也最低。

留存期限要写进流程，靠记性一定漏

留存这块最常见的场面是——没人说得清哪张表到底存了多久。订单表一直涨、日志表没人删、备份目录堆了几十个G的文件，文件名还带着日期，一清二楚。定个期限不难，难的是谁来执行。比较稳的做法是给每类数据写一个「到期动作」：到期直接删、到期做匿名化（手机号置空或者换成哈希）、到期挪到冷存储只留统计口径。然后把它塞进定时任务里，别写在文档里。文档没人看，crontab 会自己跑。

具体留多久，不同业务差别很大，法规里也有各自的要求，以适用的法规条文和服务商、官方页面说明为准，别照抄别人家的数字。

权限最小化，比前两条更容易翻车

数据收得少、删得快，但数据库账号发给了七八个人，前面两条全部白做。最小权限说起来是句废话：能查单表的只给单表，能读的不给写，临时排障开一个只读账号，干完就收。现实里听到最多的一句是「图省事直接用 root 连」，生产库的 root 密码在群里传过一圈，谁都能连。这不是技术问题，是习惯问题。

流程不用多复杂，群里说一句申请也行，但要留个记录：谁、什么时候、拿了什么权限、什么时候还回来。真出了事，这份记录能救你。

日志和备份，是数据最容易失控的两块

日志容易被忽略的地方在细节：访问日志记了完整 URL，URL 里带着手机号或者订单号；报错页面把整条请求参数原样打出来。留七天和留半年，风险差着一个量级。日志脱敏这件事，早做比晚做省事，正则写好了就是一次性的。备份同理——备份文件躺在 /data/backup 下面，权限 644、文件名带日期，谁扫到目录就能整个下载走。备份也要讲最小化：只备需要的库、加个密码或者加密、旧的定期清掉。备份不是越多越安全，堆着不动的备份本身就是一份风险清单。

三张清单，把一句话落到地上

不建议一上来就搞制度手册，没人看。三张表格够用。第一张列「收了哪些字段、为什么收、不收会怎样」，这张表能挡掉大部分没用的需求。第二张列「每类数据存多久、到期谁做、怎么做」。第三张列「哪些角色能碰哪些表、能读还是能写」。三张加起来一两页，改起来也快。每季度拿出来对一遍，发现新上的字段没在表里，说明流程漏了口子。

它不是一次性运动，是每次上线前的一道问

最小化最容易死在「做过一次」这件事上。新功能上线，加了个表单、加了个字段、加了个导出按钮，没人再过那道问，半年后表里又多出几列没人读的数据。可以在代码评审里塞一条硬规矩：新增字段必须写清楚用途，写不清楚就不合。研发嫌烦，但这条比开会讲合规有效。

今天就能做的一步：打开数据库，挑一张用户表，把字段从头到尾看一遍，问自己哪几列是「收了但从来没被读过」的。列出来，确认代码里没有人读它——grep 一遍字段名比开会讨论靠谱——下一版就删。删掉一列，你就少了一份以后要解释的东西。