凌晨两点，服务器报警邮件又响了。这次不是客户的项目挂了，是我自己写的口罩监控脚本把药店小程序的接口给刷爆了。IP被暂时封了十分钟。我盯着屏幕，脑子里第一个念头不是怎么修复，而是“妈的，这频率限制阈值设得还挺低”。
这事起因特别简单。业主群里有人问，附近哪个药店还有口罩。下面跟着几十条“同求”。我翻了翻，发现药店的小程序会不定时补货，但时间完全没规律，全靠人肉刷新。那一刻我技能焦虑的老毛病又犯了——这种重复、有明确规则、需要即时反馈的活儿，不就是爬虫最该上的场景吗？什么团队管理，什么项目交付，那些破事先放放。我急需一次纯粹的技术执行，来对冲白天被各种“人”的问题消耗殆尽的精力。
技术栈选型上我走了最野的路子。药店小程序是微信生态里的，传统爬虫抓不到它的数据包。我先用Fiddler抓了真机请求，发现核心数据走的还是HTTP/HTTPS，只是加了一层自定义的Header校验和登录态。关键点在于那个`session_key`，它被放在请求头的`X-Auth-Token`里，有效期大概两小时。我的思路是，先用一个固定账号模拟登录，把token拿到，然后写个定时任务去轮询几个关键药店的商品详情页接口。
轮询策略上我踩了坑。一开始太激进，每十秒请求一次，很快触发了对方服务器的频率限制。后来改成阶梯式：正常情况每分钟一次；一旦检测到某个SKU的库存`inventory`字段从0变成大于0，立刻进入“战斗状态”，每五秒请求一次，持续一分钟，确保能抓到补货的瞬间。数据解析倒不难，返回的是JSON，库存数字就在`data.productList[0].stock`里。难的是异常处理。小程序接口不稳定，经常返回`{“code”: 500, “msg”: “系统繁忙”}`。我加了重试机制，三次失败后标记该药店为“不可用”，等下一个周期再试。
信息推送我用了最土但最有效的方法：邮件+微信群机器人。脚本跑在我的阿里云ECS上，用Python的`requests`和`schedule`库。检测到补货，就调用SendGrid的API发邮件，同时通过一个我早些年写的微信机器人，把“XX药店，XX口罩，库存N”这样的格式化消息丢到业主群里。为了不扰民，我设了规则：同药店同商品，十分钟内只提醒一次。
效果比我想象中猛。消息第一次弹出来的时候，群里静了几秒，然后炸了。有人问“真的假的？”，有人已经点开小程序了。五分钟后，有人说“抢到了，谢谢大神”。那种感觉很奇怪。白天我带着团队给客户做几十万的项目，汇报时客户眉头还是皱的。晚上这几行破代码，解决的是人最基础的生存焦虑——能不能买到口罩，能不能安全点。技术剥离了商业包装，直接撞上真实需求时，它发出的光有点刺眼。
当然，问题接踵而至。有人私信问我能不能监控更远的药店，有人问能不能加酒精和消毒液，还有人说邮件提醒太慢，要短信。善意开始变成新的需求，新的“项目”。我赶紧在脚本里加了个`config.json`，把监控列表和推送频率做成可配置的，然后在群里发了个公告：“工具纯公益，能力有限，目前只监控本街道三家主要药店。源码我整理后发Github，有技术的邻居可以自己改。” 我得给自己划条线。2020年了，我不能再掉进“因为开头是好的，所以就必须无限交付”的陷阱里。团队管理的泥潭还没爬出来，不能再给自己套上一个7×24小时的技术支持枷锁。
脚本还在跑，IP解封后我调低了频率。看着监控日志一条条刷过去，大部分时候都是“库存: 0”。但偶尔跳出那一个“库存: 200”，紧接着就是邮件发送成功的提示。那一刻没有成就感，只有一种很深的疲惫，和一点点释然。技术这东西，当它从谋生的手艺，暂时变成连接人与人之间一点微弱互助的工具时，才依稀能看到它最初吸引我的样子。虽然我知道，天一亮，我还是得回去面对那些没完没了的合同、工资表和令人头疼的员工绩效。
