这脚本跑起来，数据库里那些“数字石油”正被成片成片地物理删除。Delete语句执行的回车键按下去那一下，手是真抖。不是技术问题，是心在滴血——这些零散数据，三年前可是我们熬夜写爬虫、调API、甚至手动从Excel里一条条抠出来的“资产”。
GDPR这词儿，半年前还觉得是欧洲佬的矫情。直到上周见了个投资人，对方第一句话就问：“你们数据合规怎么做的？有清洗机制吗？” 我才意识到，哪怕只做国内业务，这玩意儿也成了新的门槛。以前那种“先存下来再说”的野蛮采集逻辑，彻底行不通了。
痛点在哪儿？不是写不出脚本。是发现数据库里藏了太多历史包袱。用户微信授权登录，我们图省事，把头像URL、昵称甚至部分openid关联的残缺手机号段，全扔进了一个叫`user_extras`的副表里。美其名曰“用户画像素材”，实际上除了两年前做过一次粗糙的群发推送，再也没用过。它们就像阑尾，平时没感觉，但真要合规审查，就是定时炸弹。
脚本逻辑必须够狠。第一层，遍历所有非核心业务表，用正则匹配出可能是手机号、邮箱、身份证号的字段模式，不管当前业务用不用得到，一律标记。第二层，对标记数据做决策：像头像URL这种完全不必要的，直接`DELETE`；像某些需要做用户去重校验的昵称，做单向SHA-256 Hash，原字符串彻底消失，只留一个不可逆的哈希值用于比对。这里有个细节坑，哈希前必须统一字符串的编码和大小写，不然同一用户“Flovico”和“flovico”会算出两个不同的哈希，失去意义。
最肉痛的是删那些残缺手机号。早年短信通道贵，我们只在支付环节验证完整手机号，其他场景用户有时只填后四位，我们也存了。现在看，这些数据毫无价值，却有极高的隐私风险。脚本跑的时候，控制台刷刷地滚着删除日志，每一条都像在割一块小肉。心里默念：这不是损失，这是交税，是为了以后能睡安稳觉的“合规税”。
技术向善，以前觉得是口号。现在被GDPR这种外部强制力一逼，才发现它本质是风险管理。最小化采集原则，意味着你要重构很多前端表单和后端接口，要跟产品经理吵架，说服他们“这个字段我们真的不需要”。这比写爬虫难多了，爬虫是技术对抗外部世界，这是技术对抗自己过去的贪婪。
跑完脚本，数据库体积小了近15%。看着监控面板里消失的数据曲线，有种诡异的轻松感。野蛮生长阶段，总觉得数据越多越安全；现在明白了，数据越少，包袱越轻，跑得才可能越远。这次自我阉割，疼，但值。
