618 鏖战，表面是用户剁手，水面之下是卖家之间的军备竞赛。我团队现在接的单子，80%都是这种：甲方要我们盯着对手的价格，一毛钱变动，十分钟内必须触发预警。
去年这时候我还自己写爬虫，今年不行了，量太大。一个类目下几百个SKU，对手店铺几十家，平台还有京东、天猫、拼多多、苏宁。纯靠Python requests+BeautifulSoup去轮询，IP分分钟进黑名单。现在这套东西，是我们用Scrapy-Redis搭的分布式爬虫集群，挂了三百多个住宅代理IP，按平台规则模拟真实用户行为去“逛店”。
最毒的不是反爬，是平台的前端渲染。你以为页面价格就是DOM树里的文本？太天真了。很多关键价格数据是走异步接口加载的，甚至用Canvas画出来，就是为了防比价软件。我们得用Selenium配合无头浏览器，把页面真正渲染出来，再截取特定区域的图片，用Tesseract做OCR识别。光这一步，单次请求的耗时就从毫秒级拉长到秒级。
成本就在这里爆炸。一个无头浏览器的内存开销至少300M，我们同时开五十个实例，服务器内存就顶不住了。后来改用了Puppeteer，配合自己写的资源拦截规则，只加载必要的CSS和JS，把内存压到150M左右。但CPU占用还是高，因为OCR吃算力。为了抢那几分钟的预警窗口，我们租了八台高配的物理服务器，618前后这一个月，光机柜和带宽费用就烧了甲方小二十万。
预警逻辑更是个坑。不是价格一变就报警，那得吵死。我们设了多层规则：首先是“破价”，对手价格低于我方成本价多少百分比；其次是“跟价”，对手在半小时内连续调价两次以上，大概率是要打价格战；最阴的是“佯动”，对手先提价再降价，制造降价幅度大的假象。这套规则引擎是我们用Django搭的，实时流处理用Kafka，数据存时序数据库。报警不是发邮件，那太慢，是直接推送到甲方运营的钉钉群和微信企业号，附带竞品链接和价格历史曲线图。
今天凌晨三点，系统报警，某母婴大店的爆款纸尿裤突然降价15%。甲方老板直接在群里@我，问是不是爬虫出错了。我团队的小伙子爬起来手动验证，确实降了。十分钟后，甲方运营回复：“已同步调价，并启用备用优惠券。” 一场遭遇战，从发现到决策到执行，十五分钟结束。水面之下，没有硝烟，全是代码和服务器风扇的轰鸣。
团队现在七个人，五个技术，两个客服兼运营。我每天一睁眼就是这七个人的工资、服务器的账单、甲方的催命。赚了吗？流水看起来是去年的三倍。自由呢？没了。我成了整个系统里最大的那个单点故障，任何环节出问题，最后电话都会打到我这里。去年我一个人熬夜写脚本，困了倒头就睡。现在不敢睡，手机一震动就心悸，怕又是哪个爬虫节点被平台风控干掉了。
这就是2019年的我，31岁，一个亲手给自己造了一座监狱的产品经理。技术解决了效率，代价是把自己焊死在了效率机器上。
