寒水微痕开个玩笑，我真不是来帮酒店涨价或者教你写爬虫的——但也差不多。去年我接了个私人项目：一位经常出差的朋友想盯住特定航线和一个国际连锁酒店品牌的价格走势，方便在低价窗口出现时立刻出手。一开始他自己每天手动查两三次，后来发现酒店和机票的价格根本不是“每天变一次”的节奏，一天之内就能跳七八次。他受不了了，问我能不能做个本地自动采集的工具。我花了两周左右搭了一套“本地价格采集”方案，跑了大半年，稳定、省钱、可控，今天把完整思路和过程中踩过的坑分享出来。
这套思路适合谁？个人差旅规划、票代比价、酒店类自媒体做价格分析、小团队想建立自己的价格监控体系，都能用。不需要很高的编程门槛，主流程用Python + Playwright + SQLite就能扛起来，剩下的关键是搞清楚“采集什么、多久采一次、怎么判断变化是真是假”。
1. 为什么酒店机票价格会频繁波动：动态定价机制拆解
想做好价格采集，首先得理解你面对的数据为什么这么“不稳定”。这不是随机波动，背后是一套完整的收益管理逻辑。
1.1 价格不是“定”出来的，是算出来的
机票价格的制定核心是航空公司的收益管理系统（Revenue Management System）。它会根据航班的历史销售数据、当前剩余座位数、邻近航班的上座率、竞争对手价格、距离起飞天数、节假日效应等因素，通过预测模型实时调整每个舱位的价格。同一个航班，今天上午和下午查，可能是两个价；甚至你多刷新几次，价格也会有细微变化，因为系统会基于实时的购买行为动态调整。
酒店的逻辑类似。大型连锁酒店集团用的收益管理工具，会综合周边同等级酒店的入住率、当前预订速度、未来事件（演唱会、展会、旅游旺季）、取消率等数据，动态调整房价。尤其是带有“限时折扣”或“会员价”标签的房间，价格变动频率会更高。
所以一个核心结论是：价格是一个随时间变化的离散快照，每次查询都只是当时的瞬时值。这意味着：
- 你无法用“今天查一次”来了解真实的价格区间；
- 单独一次查询的价格没有参考价值，必须连续采集形成时间序列；
- 价格变化本身（涨了/跌了/跌了又涨回来）往往比绝对价格更有分析意义。
1.2 频繁波动对数据采集意味着什么
作为一个需要采集数据的人，这个特性直接决定了方案设计。举个例子，某条航线经济舱价格在一天内的变化可能是：
| 时间 | 价格（人民币） | 变化原因（推测） |
|---|---|---|
| 08:00 | 1850 | 剩余舱位充足 |
| 10:30 | 1980 | 同航线低价舱位被抢购，系统自动切换到高一级舱位 |
| 14:00 | 1850 | 有退票，低价舱位重新释放 |
| 19:00 | 2150 | 离起飞日期更近，系统调高价格 |
这种“降了又涨、涨了又降”的模式，如果你只做一天一次的采集，很可能恰好抓到最高或最低点，完全无法反映真实走势。所以采集频率不能太低。但频率太高又有两个问题：一是容易被目标网站识别为异常访问，二是可能被对方的风控策略拦截。
另一个影响是：当价格变化频繁时，你需要一种可靠的方式来区分“价格真变了”和“页面显示有误差”。我后面单独讲差异检测，这里先记住一点：时区、币种、缓存都可能导致你看到的价格“假变化”。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 本地采集方案的总体架构与设计取舍
明确了价格数据的特性之后，我们来设计采集方案。我采取的是完全“本地化”的方式——程序跑在自己的电脑或小服务器上，不依赖任何第三方在线数据服务。
2.1 为什么选择“本地”而非在线数据服务
市面上有一些现成的机票/酒店数据API，按查询次数收费，价格不便宜。对于个人监控几条固定航线和酒店的需求，一年下来的API费用可能高达数千甚至上万。而自己搭一套本地采集，唯一的成本是一台常开的电脑或云服务器（哪怕是几百块一年的入门级VPS都够用）和自己写的代码。
更重要的是可控性。第三方API返回的数据往往是聚合后的，不一