数据“干净度”这词儿，是我上周盯着数据库里那堆乱码和重复条目硬生生憋出来的。凌晨两点，客户在群里发了个截图，问“为什么这个商品价格采集出来是负数？”，我后背瞬间就湿透了。不是紧张，是那种被自己蠢到的燥热。爬虫跑了三天三夜，几百万条数据，因为一个该死的类型转换没做边界检查，价格字段里混进了“暂无报价”的字符串，Python 默认转换失败直接给了个负数。交付前最后一步，全盘重跑。
这已经不是第一次了。2017年那会儿做 SEO 内容站群，用 Scrapy 抓竞品文章，就因为一个 XPath 路径写死了，对方页面结构微调，我这边抓回来的全是“查看更多”的链接文本，堆了十几万垃圾数据进库，直到用的时候才发现。那时候觉得，跑得快就行，脏数据后面再洗。现在带团队了，成本不一样了。三个程序员加班两天写的清洗脚本，抵不上写代码时花二十分钟加个断言。
我开始强制推行单元测试，从爬虫的解析函数开始。不是那种花架子，是极其具体的、针对“脏现实”的测试。比如，价格解析函数，我的测试用例包括：正常数字字符串“129.00”、带人民币符号的“¥129”、带逗号分隔的“1,299”、中文“一百二十九”、混了空格的“129 . 00”、以及“暂无报价”和“价格面议”。每个用例都要明确通过或者抛出我能处理的特定异常。HTTP 请求模拟超时、403、以及返回完全非结构化的 HTML 垃圾。数据入库前，必须过一道校验层，字段长度、类型、枚举值范围，不符合的立刻丢进死信队列，发告警给我。
团队里的小孩不理解，觉得繁琐，拖慢开发进度。有个小伙子直接跟我说：“Flovico，咱们先跑通，有问题再修呗，这样写太慢了。” 我把他叫到屏幕前，打开了那个负数价格的数据库日志。“你看，这就是‘先跑通’的结果。我们不是个人黑客了，跑一次的成本是三个人的工时、服务器费用，还有客户信任。现在慢的这二十分钟，将来能救我们三天的命。”
我管这叫“数据消防栓”。以前着火（出问题）了，才着急忙慌去找水管（写清洗脚本）。现在我在每个可能着火的地方，预先装好消防栓（单元测试和校验规则）。看起来前期投入时间，但系统越复杂，数据源越多，它的回报就越大。尤其是接微信小程序后台，用户行为数据一点都不能错，错一点，推荐算法就歪了，用户流失你连原因都找不到。
慢就是快。这句话我现在才嚼出真味。不是动作慢，是思考前置，把“可能会怎么错”想透。这周开始，所有核心数据流水线，覆盖率必须过 70%，否则不准上线。抵触情绪还是有，但我态度坚决。这跟管理没关系，这是血淋淋的教训买来的生存直觉。你代码可以写得丑，但数据出去必须是干净的。这是底线。
