火锅店门口排队的叫号声能传到三楼，我书房里只有服务器风扇在转。这单是给一个做3C的TOP卖家做的，他们要求监控京东、天猫、苏宁、拼多多四家平台，二十个核心SKU的实时到手价，包括满减、优惠券、PLUS会员价，每五分钟跑一次。春节前是价格战最乱的时候，活动规则一天变三次。
最恶心的不是数据抓取，是反爬。京东的页面结构2019年大改过一次，之前靠xpath能稳定定位的价格区块，现在被拆成了七八个动态加载的模块，还掺了一堆随机生成的class name。你得先模拟滑动到底部触发懒加载，再用正则去匹配那个藏在脚本里的价格数据。天猫更绝，部分价格信息直接走图片渲染，普通爬虫根本读不出来。我最后是用puppeteer开无头浏览器，截取价格区域的图，再用Tesseract做OCR识别，识别率还得靠自己训练的字体库来提。为了绕过频率限制，我布了二十个阿里云的轻量应用服务器，每个IP配不同的UA和cookie池，用redis做任务队列分发。
比价逻辑本身就有坑。比如“到手价”的计算，京东的“满299减50”和天猫的“跨店满减”算法不一样，前者的优惠是按商品分摊的，后者是按订单总金额门槛触发。你得把商品加入购物车，模拟结算流程，才能拿到真实的最终价格。我写了个自动加购、跳转到结算页、提取总价的模块，但天猫的结算页有滑块验证，高峰期触发率30%。没办法，只能接打码平台，一次验证两分钱，一天光验证码成本就两百多。
最要命的是数据一致性。四家平台的时间戳不是统一的，苏宁的价格更新有缓存延迟，拼多多的百亿补贴频道价格独立于普通搜索页。你监控到的“最低价”可能是个过时的缓存页面。我在数据库里加了数据有效性校验，同一个SKU，如果五分钟内从两个不同IP抓到的价差超过10%，就自动触发第三次校验请求，用更干净的住宅代理IP去抓。这一套下来，每天处理的数据点超过五十万个，MySQL的索引优化调了三次。
那卖家老板每周给我发一次数据报表，用红色标出价格劣势的SKU。他说这套系统帮他春节档多赚了两百万毛利，因为总能比对手早半小时调价。我算了算，这套东西的开发、部署、维护，前后折腾了两个月，收了他八万。听起来不少，但扣掉服务器、代理IP、打码平台的成本，再算上我每天凌晨三点起来处理异常报警的工时，时薪可能还不如火锅店的服务员。
书房窗外的霓虹灯把“年夜饭预订”几个字映在玻璃上。我盯着监控后台不断刷新的日志流，突然觉得这种“清冷”才是真实的。人潮是他们的，数据是我的。只是不知道，这些精确到小数点后两位的价格数字，和空气里那股越来越浓的牛油火锅味，到底哪个更能代表这座城市的春节。
