说个听起来有点夸张但真实发生在我身上的事某天晚上九点多我眼睁睁看着一款热门游戏主机在某平台显示“有货”还在犹豫要不要下单等我把结算页打开库存已经变成0。第二天早上看到朋友晒出的开箱照说实话当时心里只有一个念头——不想再手动刷新网页了。我就是为了这件事写了AnyPS5一个基于Python的商品监控小工具。AnyPS5定时去抓你指定的商品页面解析库存状态和价格一旦发现补货或者降价马上把提醒推送到你的手机或邮箱。它不帮你下单也不会绕过任何平台的规则只做一件最基础也最有用的事替你去盯梢。如果你也经历过抢不到首发、错过补货、被第三方价格背刺这篇文章应该能帮到你如果你正想做一个爬虫定时监控的小项目同样可以照着这套思路复现。1. 手动刷新三天的教训决定写AnyPS5的完整动机1.1 抢不到货的本质你缺的不是网速是信息同步速度热门游戏主机的放货节奏通常是不定期的。官方商城偶尔放一批库存第三方店铺也会不定期补货调价你根本不知道下一批货出现在什么时候、哪个页面、什么价格。手动刷新本质上是在用自己的时间赌平台上库存出现的那一刻。我当时连续三天在几个平台之间来回切换浏览器标签页开了一堆吃饭吃到一半突然想起来要去看一眼晚上躺床上还要再刷一遍购物车页面。结果呢货依然没抢到人倒是先崩溃了。后来我想明白了一个关键点抢不到货的根因不是手速而是信息同步速度。库存更新到页面、页面刷新出来、你看到按钮变亮、点进去结算这一整条链路只要中间任何一个环节慢了几秒货就是别人的。真正拉开差距的不是谁的手更快而是谁先知道“有货了”这个消息。AnyPS5要解决的就是把这个信息延迟压到最小。1.2 手动盯页面的三种常见姿势与各自缺陷在没有脚本之前大家盯货基本靠这三种方式人肉刷新法不断按F5盯着一两个平台反复刷新看购物车按钮是否从灰色变成可点击。这个方法最直接但缺陷也很明显你的注意力被死死绑在电脑前离开一会儿就可能错过。购物车僵持法先把商品加入购物车然后反复打开结算页期待某一次刷新时库存变成可用状态。这个办法看似聪明实际上很多平台的购物车库存不是实时同步的有时候页面上显示有货真正提交订单时照样报错。情报账号蹲守法关注各种发补货提醒的社交账号等别人发文通知。问题在于从“检测到补货”到“编辑发出去”再到“你恰好看到”时间差可能已经拉长到分钟级。更别提情报账号通常只盯着头部几个平台覆盖面有限。这三种方式我都试过最直接的感受是它们都把“盯”这件本该由程序做的事硬生生塞给了人。1.3 AnyPS5的边界盯梢是它的全部下单不是做这类工具很容易被人问为什么不直接帮我下单我的答案很明确不做。任何绕过正常下单流程的自动化对平台和普通用户都不公平而且很容易触发风控轻则账号被限制重则直接波及支付渠道。我见过太多人因为用抢单机器人导致账号被平台封禁最后连想买的东西都买不成。AnyPS5的定位不是一个代抢机器人而是一个情报员。它只负责检测和通知把“要不要买、什么时候买”的判断留给人。名字里的“Any”才是这个项目的核心它不只是盯游戏主机任何你能看到正在售的商品页——数码硬件、限量球鞋、演唱会门票、日常消耗品——只要目标页面公开可访问都可以接入监控。游戏主机只是我第一个落地的监控品类罢了。2. 技术选型与整体架构轮询方案为什么最适合这种场景2.1 为什么是Python选择Python不是因为它在所有方面都强而是因为这个场景刚好踩中了它的优势区间。先说请求部分Python有非常成熟的httpx和requests几行代码就能完成带超时、带重试、带自定义请求头的页面抓取。再说解析部分BeautifulSoup加上lxml这套组合处理HTML解析非常顺手CSS选择器和XPath都能支持写起来直观。定时调度方面APScheduler用起来很省心interval模式就像闹钟一样到点执行。连最不起眼的发邮件功能Python标准库里的smtplib和email就能搞定完全不用引额外的依赖。相比之下Node.js配Puppeteer也能做浏览器自动化能力很强但日常监控完全不需要那种重量级的渲染能力。Go并发性能好编译出来一个二进制文件扔服务器上就跑但解析HTML需要额外找第三方库开发速度没那么快。选Python本质上是拿一点性能换开发效率对分钟级监控来说这完全是划算的买卖。2.2 数据获取方式对比轮询、长连接与公开接口我一开始也想过有没有比定时轮询更“高级”的方案于是我把几种常见的数据获取方式拉了一张对比表。数据获取方式延迟实现成本稳定性适用场景定时轮询秒到分钟级低高依赖基础HTTP能力个人监控、小规模数据同步官方开放接口准实时中需要申请权限高但接口策略可能变化有官方支持的场景逆向内部接口准实时高需要抓包和维护加密逻辑低平台一改版就崩强烈不推荐风控风险极高WebSocket长连接准实时高需要逆向协议受页面实现影响大团队级别的深度集成最后我还是选了最“土”的定时轮询。理由很简单平台不欠我一个公开接口我也没必要去逆向那些加密的内部协议。逆向接口最大的风险是维护成本平台的前端代码一周变三次你的解析逻辑就得跟着改三次。轮询虽然看起来不够酷但它依赖的只是最普通的HTTP GET请求只要页面还能在浏览器里打开脚本就大概率能抓可维护性最好。2.3 五层架构采集、解析、检测、通知、存储AnyPS5的代码结构我没有做得很复杂但分层很清晰。一个监控任务拆成五个阶段采集层按配置的频率抓取目标商品页的HTML。解析层从HTML里提取库存状态、价格、标题这些关键字段。检测层把解析结果和上一次的结果做对比判断当前是否值得通知。通知层通过邮件、Webhook把变化推送出去。存储层把每次采样的结果写入SQLite留作历史数据分析。这五层里最容易被人忽略的是检测层。很多新手做监控会把采集和解析当成核心实际上检测层才决定了工具好不好用。通知发太多和发不出去一样让人崩溃这层后面会细说。具体的目录结构我也贴出来方便参考。anyps5/ ├── config.yaml # 监控任务配置 ├── monitor.py # 主程序入口 ├── fetcher.py # 采集层 ├── parser.py # 解析层 ├── detector.py # 检测层 ├── notifier.py # 通知层 └── storage.py # 存储层2.4 一次监控任务的完整生命周期整个流程用文字描述是这样定时器触发先进入采集层fetcher去抓商品页HTML然后解析层从HTML里提取关键字段检测层把这些字段和上一次成功采样的结果做比较。如果没有任何变化就把当前采样写入历史数据然后静默结束。如果发生了变化先判断是否命中告警规则——比如从缺货变为有货或者价格低于某个阈值——命中规则就发送通知更新缓存同时写入历史数据。这个流程看着简单写代码时会遇到几个边界问题。第一次执行时没有缓存怎么办我的做法是先完整地抓一次把字段存下来但不通知避免刚部署就收到一条意义不明的提醒。网络异常怎么办重试几次之后如果还是失败这次采样就不要覆盖上次成功的缓存否则会把一次网络抖动误判成页面改版。目标平台改版导致解析失败怎么办这种情况不能默默忽略解析层拿不到关键字段时应该单独告警提示“选择器可能失效了”让你知道需要去更新配置。3. 核心代码拆解抓取、解析、变化检测与提醒通知3.1 抓取层超时、重试与请求头伪装采集层最简单的版本就是构造一个带超时和重试的GET请求。直接看代码。# fetcher.py import time import requests HEADERS { User-Agent: ( Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0 Safari/537.36 ), Accept: text/html,application/xhtmlxml,application/xml;q0.9,*/*;q0.8, } def fetch(url, timeout10, retries3): for attempt in range(retries): try: resp requests.get(url, headersHEADERS, timeouttimeout) resp.raise_for_status() return resp.text except Exception as exc: if attempt retries - 1: raise time.sleep(2 * (attempt 1))这里有几个细节值得说明。User-Agent必须设置成常见浏览器的格式不然不少站点会直接拒绝陌生客户端。timeout也不能省目标平台偶尔会出现响应缓慢的情况如果不设超时任务可能卡在那里后面所有调度全部堆积。重试之间的延迟我用的是递增策略第一次失败等2秒第二次等4秒给临时网络抖动一个恢复窗口又不会对目标平台造成密集请求。3.2 解析层如何稳定地提取“库存状态”和“价格”解析层的思路是让选择器可配置。同一个站点的商品页结构通常是固定的但不同站点之间千差万别所以我把选择器写到配置文件里而不是硬编码在代码中。# parser.py from bs4 import BeautifulSoup def parse_product(html, selectors): soup BeautifulSoup(html, lxml) stock_node soup.select_one(selectors[stock]) price_node soup.select_one(selectors[price]) return { stock_text: stock_node.get_text(stripTrue) if stock_node else unknown, price: price_node.get_text(stripTrue) if price_node else unknown, }拿到库存字段之后还需要做一个语义判断。不同平台表达缺货的词不一样有的是“缺货”有的是“补货中”有的是“暂时售罄”还可能出现“需预约”。所以判断逻辑用了一个状态词黑名单。def is_in_stock(info): blacklist (缺货, 售罄, 补货中, 预约, 补貨) return not any(word in info[stock_text] for word in blacklist)这比写死“如果等于有货”要稳得多。页面只要出现“已售罄”三个字判断立刻生效不需要精确匹配整句。3.3 检测层用字段签名而不是整页哈希最早我做变化检测时走了弯路直接对整个页面HTML做哈希页面变了就通知。结果可想而知广告位每天更新促销倒计时每秒在跳随机推荐商品每次都不一样通知多到让人想把手机扔进垃圾桶。后来改成只对关键字段做签名只比较自己关心的内容。# detector.py from hashlib import md5 def build_signature(info): raw f{info[stock_text]}|{info[price]} return md5(raw.encode()).hexdigest() def has_changed(current, previous): if previous is None: return False return build_signature(current) ! build_signature(previous)字段比对天然忽略非关注区域广告怎么变、推荐位怎么换都不影响判断。这个改动让误报率直接降了九成以上。3.4 通知层邮件与Webhook的通用实现通知可以做成两种渠道方便不同场景接入。存粹的邮件通知用SMTP通用性最好。# notifier.py import smtplib from email.message import EmailMessage def send_mail(config, subject, body): msg EmailMessage() msg.set_content(body) msg[Subject] subject msg[From] config[from] msg[To] config[to] with smtplib.SMTP(config[host], config[port]) as server: server.starttls() server.login(config[from], config[password]) server.send_message(msg)Webhook方式更通用适合接到自己的消息机器人上。核心就是一条POST请求。import requests def send_webhook(url, text): requests.post(url, json{text: text}, timeout5)建议通知内容里带上商品名称、库存状态、价格、页面链接别只发一句“有货了”。我看到提醒之后还要再打开浏览器找页面那体验就差太多了。3.5 调度层从手动运行到无人值守定时调度最简单的方式就是APScheduler的interval模式配置一个秒数到点就跑一次。from apscheduler.schedulers.blocking import BlockingScheduler scheduler BlockingScheduler() scheduler.add_job(run_all_tasks, interval, secondsconfig[interval]) scheduler.start()服务器上也可以直接用cron但对秒级间隔支持不好而且没有依赖管理。我建议把任务执行时间跟状态检测逻辑分开调度只负责触发检测逻辑始终独立运行。这样即使某一次执行卡住了下一次调度也不会受到影响。4. 部署两周里踩过的坑误报、反爬与通知轰炸4.1 页面是动态渲染的requests抓到了空壳第一次把脚本部署到服务器时我兴冲冲地跑了一个任务结果发现解析出来全是unknown。打开抓回来的HTML文件一看整个页面的商品信息区域空空如也只有一堆loading占位符库存状态和价格都是前端JavaScript加载完之后才渲染出来的。这种页面用requests是抓不到真实内容的。解决方案是引入浏览器自动化工具做兜底。我用的是无头浏览器让它打开页面、等待渲染完成、再拿到完整的HTML源码。但这里有个代价无头浏览器非常占用资源每一个任务都启动一个完整浏览器实例会让服务器内存吃紧。我的做法是复用浏览器实例——启动一次多个页面共用同时只在配置里标记为“dynamic”的任务才走浏览器路径其余任务仍然用轻量的requests。4.2 请求太勤被平台识别为异常流量刚开始我对抓取间隔的判断是越快越好。结果把间隔设成了5秒跑了不到半小时目标平台开始返回验证码页面。这说明对方的风控已经注意到这个IP的请求频率异常了。这个教训让我把请求频率控制到了很保守的程度。普通商品页默认间隔30秒以上高价值商品页间隔1分钟以上同时给每次请求加一个随机延迟——在固定间隔基础上下浮动几秒避免请求节奏过于规律。低频率不仅是对平台的尊重也是为了自己工具的长久稳定。频率越高越容易被封被封了反而什么都监控不到。还有一个底线问题robots.txt。如果站点明确写了不允许爬取某些路径那就不要碰。个人监控工具虽然请求量很小但规矩还是要守。4.3 页面局部变化导致误报某个任务跑了一个星期后我发现通知频率逐渐升高。排查下来发现问题出在页面里的促销倒计时模块剩余时间倒计时每秒都在变而我的检测逻辑是对整个页面HTML做哈希所以每次抓回来哈希值都不一样每次都判定为“变化”。解决方法是把检测范围收窄到商品详情区域或者直接用第3章说的字段签名。字段签名只比较库存状态和价格这两个真正关心的字段其他地方随便变都当作没有发生。4.4 连续补货通知把我手机震成了按摩仪有一次平台在五分钟内分批放了三批货库存状态在“缺货”和“有货”之间来回切换一个晚上我的手机收到了六条一模一样的通知。后来我甚至在纠结是把通知关掉还是把脚本关掉。最终决定在通知层加一层冷却期控制。同一个任务在指定时间窗口内对同一种状态变化只通知一次。比如五分钟内已经通知过“有货”那下一次还是“有货”就继续沉默。真正再次触发通知的条件是状态完全跳变后经过足够长的时间或者价格又下降到另一个阈值区间。4.5 服务器上的日志、守护与资源占用个人监控工具跑到服务器上有几个容易被忽视的细节。日志必须做滚动切割不能一个文件无限写下去。我用的方案是logging模块配合定时切割按天归档保留最近一周。服务守护用systemd的Restartalways进程意外退出后会自动拉起不用自己写一个while True死循环看护进程。资源占用方面纯requests模式跑几十个任务内存占用通常不到50MB完全可以接受。但无头浏览器不一样一个实例就要几百MB内存所以我的策略是核心任务全部走requests只有在确认页面是动态渲染时才启用浏览器方案。服务器系统时间也要校准。调度依赖系统时钟如果服务器时间偏移任务执行时间就会乱掉补货预测直接雪崩。5. 从“盯一款”到“盯一批”配置化、历史记录与主动查询5.1 配置化一个YAML文件管理所有监控目标项目跑通单商品监控之后第一个需求就是同时监控多个商品。总不能每加一个商品就改一次代码吧。所以我把监控任务全部改成配置文件驱动。tasks: - name: store_a_console_black url: https://example.com/product/111 selectors: stock: #stock-status price: .price alert_rules: in_stock: true price_below: 3500 interval: 60 dynamic: false - name: store_b_console_white url: https://example.com/product/222 selectors: stock: .stock-word price: .sale-price alert_rules: in_stock: true dynamic: true主程序启动时读一遍配置文件为每个任务创建独立的运行状态。新增监控目标只需要追加一段配置代码完全不用动。这套配置文件化的改造几乎是所有个人监控项目必须走的一步早做比晚做好。5.2 SQLite历史表降价还是假促销看数据就知道存储层我选了SQLite零配置单文件适合这种轻量场景。每次采样任务不管有没有触发通知都会把当次的数据写入历史表。CREATE TABLE IF NOT EXISTS price_history ( product TEXT, price REAL, stock_status TEXT, checked_at DATETIME DEFAULT CURRENT_TIMESTAMP );历史数据最大的价值是判断一次降价是不是真的降了。有些第三方店铺会在促销前先抬高价格再打一个看似诱人的折扣。把商品最近两周的价格拉出来最高价、最低价、均价一目了然。用一条SQL就能完成SELECT MIN(price) AS low_price, MAX(price) AS high_price, AVG(price) AS avg_price FROM price_history WHERE checked_at DATETIME(now, -14 days);对比一下历史均价和当前标价就知道这次促销到底是真便宜还是数字游戏。5.3 最轻量的价格走势看板有人问我要不要接Grafana我直接回绝了。一个家庭级监控项目没必要引入那么重的可视化组件。我后来用Python脚本定时读取SQLite把最近N天的价格记录生成一份带简单折线的HTML挂在一个静态页面上手机浏览器也能看。或者更轻量一点直接在命令行里输出最近几次采样的表格。看板的核心作用是解答“这个商品现在处于历史什么位置”而不是比拼图表炫不炫。5.4 主动查询让机器人反馈当前状态通知是被动推送只能等脚本发现问题来告诉你。可用户想主动问一句“现在有货吗、多少钱”怎么办我在通知层扩展了一个简单的主动查询接口。实现思路是接收一段文本解析出要查的商品名从SQLite里读最新一条记录再把库存状态和价格拼接成回复文本发回去。def handle_query(message: str) - str: product parse_product_name(message) row db.get_latest(product) if row is None: return f{product} 还没有监控记录 return f{product} 当前状态{row[stock_status]}价格{row[price]}检查时间{row[checked_at]}这个功能一加工具就从“单向告警器”变成了“随身助手”。想确认的时候随时问一句而不是守在手机旁边等通知。5.5 合规意识策略克制工具才走得远整篇讲了很多实现细节最后必须强调一条监控工具能跑多久取决于你对目标平台有多克制。我给自己定了几条硬规矩只监控公开页面不碰需要登录才能看到的数据。遵守robots.txt明确被禁止的路径绝不抓取。请求间隔不低于30秒不做并发轰炸。绝不实现自动下单功能不欺骗任何风控机制。测试阶段使用占位URL或者自己的演示页面不拿真实平台练手。这些规矩不是道德绑架而是现实的自我保护。一旦越过任何一条平台修改策略、封禁IP、限制账号工具立刻失去作用之前做的所有东西都白费。一个能长期稳定运行的监控工具前提是先做一个“礼貌的访客”而不是一个无情的抓取器。最后分享一个我自己的体会AnyPS5跑起来之后我最满意的时刻并不是哪次成功抢到商品而是发现自己终于不再每小时打开一次购物车页面了。做监控工具真正的难点不在抓数据而在控制自己——控制请求频率、控制通知数量、控制功能欲望。一个成熟的提醒工具应该学会安静只在关键的时候开口。刚开始我恨不得让它每分钟都汇报“没货”后来设好冷却期和阈值它反而在我真正需要的时候才出现。这大概就是自动化该有的样子把重复交给程序把判断留给自己。