1. 为什么SaaS定价页比普通网页更难采集：需求边界与方案选型
先说说我为什么盯上这个需求。做SaaS竞品分析的人应该都有这种经历：今天打开某款项目管理工具的官网，Pro版还是49美元/月，下周再看，悄悄变成了59美元/月，中间没有任何邮件通知。更离谱的是有些产品会把新功能拆成独立计费项，或者把免费额度从5个席位砍到3个。等到你发现的时候，方案已经汇报上去了，预算完全对不上。这就是定价页历史版本采集的核心价值——你需要的不是某个时间点的定价快照，而是完整的变动时间线。
我最早的做法很原始：建了一个Excel表格，每周手动打开十几个竞品官网，把价格、套餐名称、功能描述挨个复制进去。坚持了三周就放弃了，原因很现实——手动采集不仅慢，而且容易漏。有些SaaS产品的定价页是动态渲染的，数据藏在接口里，肉眼看到的只是拼装后的结果；有些产品的定价页做了A/B测试，不同入口进去看到的价格可能不一样；还有些产品干脆把定价页做成了PDF或者需要登录才能查看。这些情况决定了"SaaS定价页采集"这个需求，和普通新闻文章采集完全是两回事。
1.1 动态渲染问题：为什么直接抓目标站点往往拿不到想要的东西
大多数现代SaaS官网用的是React或Vue这类前端框架，定价页的HTML骨架是空的，真正的价格信息通过JavaScript从后端接口拉取再渲染到页面上。你用requests直接请求定价页URL，大概率只能拿到一个空壳：一堆div标签，没有任何价格数字。想破解这个问题，要么用Selenium或Playwright模拟真实浏览器执行JavaScript，要么直接分析页面前的XHR请求，找到背后返回JSON数据的那个接口。两条路都能走，但都有代价。Selenium慢，而且容易被目标站点的反爬机制识别；分析XHR接口则需要你熟悉浏览器DevTools的操作，还得祈祷接口没做签名验证。
1.2 历史版本从哪来：直接爬目标站的最大盲区
就算你解决了动态渲染问题，还有一个更麻烦的事——历史版本。今天你写了个爬虫抓到了定价页，那上周的版本呢？上个月的呢？目标站点的服务器不会保存历史版本给你调取，除非它自己做了改动记录，但这种情况极其罕见。我见过一些团队的做法是"先上线爬虫，从今天开始积累数据"，这当然可以，但意味着你永远拿不到过去的变动数据。如果你需要回溯三个月前的某个定价变更，唯一靠谱的数据源是第三方网页存档服务——也就是Internet Archive的Wayback Machine。它从1996年开始持续抓取互联网上的公开页面，对主流SaaS官网的定价页有大量历史快照，这些快照本身就是天然的"历史版本"。
1.3 三种采集路线对比：我最终选择了哪条
我把市面上能想到的方案整理了一下，一共三条路线。
| 方案 | 优点 | 缺点 | 适用场景 |
|---|---|---|---|
| 直接爬目标站点，配合Selenium/Playwright | 实时性强，数据最新 | 拿不到历史版本；容易被反爬封禁；需要处理动态渲染和接口签名 | 只需要当前价格，且目标站点反爬较弱 |
| 自建定时任务，从今天开始每天存档 | 数据完全可控，格式自定义 | 没有历史回溯能力；需要长期维护；初期数据量为零 | 长期监控自有产品定价页或竞品，能接受冷启动周期 |
| 基于Wayback Machine CDX API采集历史快照 | 天然带时间戳，历史版本完整 | 快照非实时（有延迟）；某些页面可能没被收录；需要处理快照间的重复和噪声 | 回溯历史定价变更、竞品调价分析，也是最省事的主干方案 |
我的最终选择是以Wayback Machine CDX API为主干，把历史快照拉下来，再做内容提取和差异对比；同时用一个自建的小型定时脚本，每天抓一次目标页面的当前快照，补充最新数据。这样既解决了"回溯历史"的问题，也缓解了"最新数据滞后"的尴尬。整个项目下来，核心工作量其实不在爬虫本身，而在数据清洗和版本对比这两块——这恰恰是网上大多数爬虫教程没讲透的地方。
2. 环境准备与依赖安装：这套方案的最低必要配置
在动手写代码之前，先把环境说清楚。我的开发环境是Windows 11 + Python 3.10，但下面这套方案在macOS和Linux上完全通用，因为核心逻辑不依赖任何平台特性。如果你还在用Python 2，建议先升级，CDX API返回的JSON解析和后续的文本处理，在Python 3下会省掉大量编码相关的坑。
2.1 Python版本选择与虚拟环境
有条件的话直接用Python 3.8以上版本，原因有两个：一是3.8之后的f-string调试语法（f"{var=}"）非常方便，二是我后面会用到的zoneinfo时区处理模块，在3.9之后才进入标准库。装好Python之后，强烈建议建一个干净的虚拟环境，别把依赖直接装到全局：
python -m venv pricing_env # Windows激活 pricing_env\Scripts\activate # macOS/Linux激活 source pricing_env/bin/activate为什么要用虚拟环境？因为这个项目依赖的requests、pandas、python-dateutil这些库，版本要求比较宽，但如果你的机器上还跑着其他爬虫项目，某个库的版本升级很有可能把别的项目搞挂。虚拟环境就是给每个项目一个独立的依赖沙箱，互不干扰，这是我在踩过几次"升级依赖导致全网爬虫瘫痪"的坑之后养成的习惯。
2.2 依赖清单：本项目实际用到的库只有四个
我把依赖控制在最小范围内，核心思想是"能不用框架就不用框架，尽量用标准库解决问题"。最终项目里只用了四个库：
pip install requests pandas python-dateutilrequests：处理HTTP请求，向CDX API查询快照列表、拉取存档页面内容pandas：处理快照元数据表格，做时间戳归组、去重、排序，输出版本记录CSVpython-dateutil：解析Wayback Machine返回的W3C格式时间戳（类似20250315120345这种），比手动切字符串安全得多hashlib：系统内置，不算第三方库，用来算页面内容的SHA-256哈希，做变化检测
这里多说一句，网上很多教程喜欢用scrapy或BeautifulSoup，但本项目里BeautifulSoup都不是必须的。因为定价页的关键信息往往不是静态HTML里的文本，而是嵌在某个JSON结构里，或者需要提取特定区块。我直接用正则加json模块就能搞定，少一个依赖就少一个维护负担。
2.3 最小验证脚本：三行代码确认网络连通性
在写完整脚本之前，先跑一个最小验证，确认你的网络可以正常访问Wayback Machine的API。这一步挺重要，因为某些办公网络或云服务器IP段，访问这个服务可能会被限流或超时，早点发现问题总比写完几百行代码才发现跑不通要好。
import requests url = "http://archive.org/wayback/available" params = { "url": "notion.so/pricing", "timestamp": "20240301" } resp = requests.get(url, params=params, timeout=30) print(resp.json())如果返回结果里有closest字段，说明网络通，可以把目标URL换成你要采集的SaaS定价页试试。如果没有，检查一下是否需要用代理（这里说的是常规企业代理，不要误解），或者换一个网络环境再跑。这个微小验证脚本的价值在于，它把"网络问题"和"代码问题"两个变量分开排查，后面写复杂逻辑时心理会踏实很多。
3. 核心实现：基于CDX API的版本发现与内容抓取
现在进入正题。Wayback Machine的CDX API本质上是一个查询接口，它返回的是"某个URL在Internet Archive里所有的快照清单"。我一开始以为这个API很复杂，看了一小时文档差点放弃，但实际用起来核心请求就一个GET，参数也比想象中简单。先把最关键的请求参数列出来，这是整个项目的基石。
3.1 CDX API请求参数详解：比官方文档更实用的理解方式
CDX API的完整端点长这样：
http://web.archive.org/cdx/search/cdx?url=notion.so/pricing&output=json&fl=timestamp,original,statuscode,mimetype,digest&filter=statuscode:200&collapse=timestamp:6一个个解释：
url：目标页面URL。注意这里传的是原始URL，不需要带协议头，API会自动匹配http和httpsoutput=json：返回JSON格式，方便程序解析。如果不加，默认返回文本表格，解析起来很痛苦fl：控制返回哪些字段，我常用的是timestamp（快照时间）、original（原始URL）、statuscode（HTTP状态码）、mimetype（内容类型）、digest（内容哈希）filter=statuscode:200：只保留正常抓取成功的快照，过滤掉404、301等异常状态collapse=timestamp:6：按时间戳前6位（年月日）去重，意思是同一天只保留一条快照，避免一天被抓了七八次导致数据冗余
这里我特别说明一下collapse参数。Wayback Machine对热门页面经常一天抓取多次，比如Notion的定价页一天可能被存档三到五次，如果全保留，后面做版本对比时会看到大量重复或近乎重复的记录，纯属噪音。按天折叠后，每个自然日最多保留一条快照，数据量大幅下降的同时，版本粒度依然是"天级"，对定价变动分析来说完全够了。
3.2 获取快照清单与时间戳归组：核心代码实现
我封装了一个函数，用来获取指定页面在指定时间段内的所有快照：
import requests import pandas as pd from datetime import datetime, timezone from dateutil import parser as dt_parser WABase = "http://web.archive.org/cdx/search/cdx" def fetch_snapshots(target_url, start_date=None, end_date=None): """ 从Wayback CDX API获取目标URL的快照清单 :param target_url: 目标页面URL，如 notion.so/pricing :param start_date: 开始日期，格式'20230101'，可空 :param end_date: 结束日期，格式'20250301'，可空 :return: DataFrame，列包含timestamp, original, statuscode等 """ params = { "url": target_url, "output": "json", "fl": "timestamp,original,statuscode,mimetype,digest", "filter": "statuscode:200", "collapse": "timestamp:6" } if start_date: params["from"] = start_date if end_date: params["to"] = end_date resp = requests.get(WABase, params=params, timeout=60) resp.raise_for_status() rows = resp.json() if len(rows) < 2: return pd.DataFrame(columns=["timestamp", "original", "statuscode", "mimetype", "digest"]) # 第一行是字段名 df = pd.DataFrame(rows[1:], columns=rows[0]) # 时间戳解析成datetime，方便后续排序和归组 df["datetime"] = df["timestamp"].apply( lambda ts: dt_parser.parse(ts).replace(tzinfo=timezone.utc) ) df = df.sort_values("datetime").reset_index(drop=True) return df这个函数做了三件事：请求CDX API、解析JSON数组、将时间戳转成标准datetime对象。特别注意rows[0]是字段名，真正的数据从rows[1:]开始，这个细节我第一次处理时没注意，差点把第一行快照的时间戳当成列名。运行一下看看效果：
snapshots = fetch_snapshots("notion.so/pricing", start_date="20240101", end_date="20250315") print(snapshots.head())如果一切正常，你会看到一个包含每条快照时间、原始URL、状态码等信息的表格。到这里，你手里已经握住了Notion定价页在指定时间段的所有历史版本索引。接下来要做的就是把这些快照的内容真正拉下来。
3.3 按时间戳组装快照URL：从索引到内容
Wayback Machine的快照访问URL格式是有规律的：http://web.archive.org/web/{timestamp}/{original_url}。比如http://web.archive.org/web/20250315120345/https://www.notion.so/pricing，表示2025年3月15日12:03:45抓取的Notion定价页。我把前面的快照列表加上这个访问URL，变成一个完整的DataFrame：
snapshots["archive_url"] = snapshots.apply( lambda row: f"http://web.archive.org/web/{row['timestamp']}/{row['original']}", axis=1 )然后在每次抓取内容时，把archive_url传给requests.get。这里有个细节我希望新手注意：不要同时并发请求太多快照，Wayback Machine对短时间内的密集请求会做限流，我一般控制在每两秒一个请求，200个快照大约需要7分钟，完全可接受。如果快照数量上千，就需要人工评估是不是把时间范围拉得太大了，拆成多段慢慢跑。
抓取快照内容的函数长这样：
def fetch_snapshot_content(archive_url, timeout=30): """ 抓取Wayback快照页面的原始HTML """ headers = { "User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36" } resp = requests.get(archive_url, headers=headers, timeout=timeout, allow_redirects=True) resp.raise_for_status() return resp.text关于返回内容我要提醒一点：Wayback Machine在返回快照页面时，通常会在页面上插入自己的一个工具条（如果人家顶部有一条"archived from"的横幅），那个工具栏是HTML显式注入的，不影响我们提取数据，但如果你用BeautifulSoup去定位某些DOM节点，可能会受到干扰。我的习惯是直接用正则或者简单字符串操作提取，绕开工具栏带来的干扰。
3.4 从快照HTML中提取价格信息：用正则还是用结构解析
SaaS定价页的价格信息有相对固定的形态：美元符号加数字，比如"$49"或"$49.00"，或者是"from $49"这类前缀描述。我用一个多模式的正则来提取所有疑似价格的内容，再根据业务规则过滤出真正的套餐价格：
import re def extract_prices(html): """ 从HTML里提取所有疑似价格内容 """ patterns = [ r'\$\s*[\d,]+\.?\d*', # $49 或 $49.00 r'USD\s*[\d,]+\.?\d*', # USD 49 r'from\s*\$\s*[\d,]+\.?\d*' # from $49 ] prices = [] for pat in patterns: matches = re.findall(pat, html, flags=re.IGNORECASE) prices.extend(match.strip() for match in matches) return list(set(prices))有人会问我为什么不用XPath或CSS选择器去精确定位价格区块。原因是Wayback的历史快照里，页面结构在不同时期可能完全不一样。三年前的定价页可能用的是一套CSS类名，现在的又换了一套，如果你用固定选择器，换版后就会大面积提取失败。正则虽然看上去"笨"，但它对"价格长什么样"的刻画是稳定的，只要SaaS产品还在用"美元+数字"的表达方式，这套正则就能工作。如果你的目标产品用的是欧元、英镑或者其他币种符号，记得在正则里把符号替换掉。
提取完价格之后，我还习惯把原始HTML保存一份到本地，文件名带上时间戳。这既是为了备份，也是为了方便后续人工抽查——机器判断价格变动时可能会漏，但原始HTML永远是最终真相：
def save_html(raw_html, timestamp): file_path = f"snapshots/{timestamp}.html" with open(file_path, "w", encoding="utf-8") as f: f.write(raw_html) return file_path4. 变化检测与时间戳管理：让采集结果真正形成"版本史"
现在你已经有了一堆历史快照的HTML文件和提取出的价格列表，但如果只是把这些数据堆在一起，还称不上"版本史"。我在实际使用中很快就发现两个新问题：第一，快照数量多，但很多快照之间根本没有任何变化，如果全部展示出来，等于把噪音也记进了历史；第二，同一天的多个快照如果不做归组，会出现"同一天内不同时间版本"的冲突记录。这两个问题不解决，后续做趋势分析时数据质量会很差。
4.1 内容哈希与重复快照过滤：一个月只留下几张有效版本
我用的方案是给每个快照的HTML内容计算SHA-256哈希，然后只保留"哈希发生变化"的版本。如果一个快照和相邻快照的哈希完全一致，说明页面内容一字未改，这个快照对版本历史来说就是冗余的。
import hashlib import pandas as pd def compute_hash(html): return hashlib.sha256(html.encode("utf-8")).hexdigest() snapshots["content_hash"] = snapshots["archive_url"].apply( lambda url: compute_hash(fetch_snapshot_content(url)) ) # 只保留哈希变化的地方 snapshots["changed"] = snapshots["content_hash"] != snapshots["content_hash"].shift(1) version_df = snapshots[snapshots["changed"]].reset_index(drop=True)这里有两点需要注意。首先，shift(1)的比较是基于DataFrame排序后的顺序，所以务必确保数据按时间排序了（前面已经做了sort_values）。其次，哈希比较是"全量比较"，只要页面里任何一个字节变了，哈希就会变。这意味着一个动态的"今天访问人数"数字、一段随机推荐的文案，都会导致哈希变化。对于定价页来说，这种噪声相对少，但如果你的目标页面里有动态元素，建议还是用下一步的"结构化提取值对比"来辅助判断。
4.2 结构化版本对比：价格变动才是关键信号
哈希只能告诉你"页面变了"，不能告诉你"价格变了没"。为了精准捕捉定价变动，我需要把每个版本的提取结果组合成一个结构化记录：时间戳、原始URL、价格列表、内容哈希。然后把相邻版本的"价格集合"做对比，只有价格集合发生变化的，才标记为"定价版本变更"。
def prices_changed(row): # 当前价格集合和上一条记录的价格集合做差集 current = set(row["prices"]) previous = set(version_df.iloc[row.name - 1]["prices"]) if row.name > 0 else set() return current != previous version_df["prices"] = version_df["html_content"].apply(extract_prices) version_df["price_change"] = version_df.apply(prices_changed, axis=1)这个字段的价值在后续分析时才会体现出来。比如我想看某产品在2024年全年调价了几次，只需要查price_change==True的记录，得到的就是一张干净的调价时间表——哪一天、从什么价格变成什么价格。这比对着几十条原始快照肉眼看要高效得多。
4.3 生成版本记录CSV：最终交付的数据结构
最后把版本记录导出成CSV，每一行是一个"有内容变化的版本"：
version_df[["datetime", "archive_url", "prices", "content_hash", "price_change"]].to_csv( "pricing_versions.csv", index=False )CSV内容大致是这样的：
| datetime | archive_url | prices | price_change |
|---|---|---|---|
| 2024-01-15 08:12:33+00:00 | http://web.archive.org/web/20240115081233/... | ['$49'] | True |
| 2024-04-02 14:33:01+00:00 | http://web.archive.org/web/20240402143301/... | ['$49', '$79'] | True |
| 2024-07-20 09:05:44+00:00 | http://web.archive.org/web/20240720090544/... | ['$59', '$89'] | True |
看到这张表，你基本就能回答"某产品什么时候调过价、从多少调到多少"这个问题了。如果还想做可视化，直接把datetime和prices字段丢进Excel或ECharts画时间线走势图，都非常方便。
5. 定时调度与防封策略：从手动脚本到自动值守
脚本写完之后，我一开始是手动跑的，想起来了就执行一次。但一忙起来就忘，结果历史数据出现断档。后来我配置了定时调度，跑了两周终于稳定下来。这部分的经验对任何爬虫项目都有通用价值。
5.1 调度方案选择：Windows计划任务还是GitHub Actions
我同时配了两套调度方案，互为备份。
方案一：Windows计划任务（适合在我自己的电脑上跑）
步骤很简单：把Python脚本路径、虚拟环境的python.exe路径、工作目录配置到任务计划程序里，触发器设置每天上午九点执行一次。脚本内部先拉取当前快照做实时存档，再周期性调用CDX API回溯最近半个月的快照做补漏。Windows计划任务偶尔有个问题是系统休眠或关机时任务会被跳过，所以我还在脚本外层加了个"今天没跑过就补跑"的逻辑。
方案二：GitHub Actions（适合云端异地备份）
如果你的代码放在GitHub上，建立一个.github/workflows/pricing.yml，每天定时跑一遍采集逻辑，然后把生成的CSV提交回仓库。这样做有额外的好处：所有版本历史天然进了Git，每次变动都有记录，且不依赖本机是否开机。我用过一段时间，可靠性很高，缺点是一天只跑一次，无法做到小时级监控。
5.2 请求频率与User-Agent：合理设置，别把自己搞进黑名单
不管是请求Wayback Machine还是直连目标站点，都要注意请求频率。Wayback Machine的整体策略相对宽松，但也不是完全没限制。我的实践做法：
- 单线程顺序请求，不用
asyncio或concurrent.futures - 每个请求之间至少间隔2秒
- 设置超时时间（30秒），避免某个请求长时间卡死
- 每次请求都带上正常的
User-Agent，模拟浏览器访问
有人会问，为什么要带浏览器的User-Agent？因为默认的python-requests/2.31.0这个UA太容易被识别为爬虫，虽然Wayback不一定会封，但有些目标站点如果采集它的当前版本页，看到这个UA大概率直接拒绝服务。
5.3 关于robots.txt与数据使用的边界：必须提前想清楚的事
到这里必须提一个合规问题。用Wayback采集历史快照是从第三方存档取数，绕开了目标站点本身的访问限制，但这并不意味着可以无限制地使用这些数据。我给自己定的原则是：采集的数据只用于竞品分析和内部决策，不对外发布，不用于可能侵犯对方商业利益的场景。另外，如果脚本里有直连目标站点获取当前版本的逻辑，务必先检查目标站点的robots.txt，看它的Disallow规则是怎么写的，百度搜索"robots.txt 怎么看"就能快速了解。一个负责任的爬虫程序，应该在请求前先读取目标站点的robots规则，而不是不管三七二十一直接开爬。
6. 实战中的坑与排查链路：一个真实踩坑的完整过程
这一节我把整个开发过程中遇到的最典型的三个问题写出来，都是纯技术层面的坑，每个坑背后都有一段真实的排查过程。
6.1 坑一：CDX返回了大量重定向记录，导致重复版本激增
第一次跑完整脚本时，我拉回来的快照清单有300多条，但冷静一看，其中将近一半是original字段带www.和不带www.的重复，还有一些是http和https之间的重复。Wayback对同一个页面会同时记录多种URL形态，CDX默认不做归并。这个问题不加处理，会导致"同一个页面"被当成"多个页面"采集，版本对比彻底失真。
排查链路：先打印snapshots["original"].value_counts()，发现notion.so/pricing和www.notion.so/pricing被当成两条记录；然后我去CDX API文档里查，发现有一个matchType=exact参数可以精确匹配URL，但这样会把不同形态的URL全当成不同页面，也不合适。最终我的解法是：在请求CDX时，把URL统一成目标站点实际使用的那个形态（一般是不带www的那个），同时在拿到结果后，再做一次original字段的字符串归一化（去掉http(s)://前缀、去掉末尾斜杠），再按归一化后的URL排序去重。这样处理的逻辑简单，也最容易验证。
6.2 坑二：某些快照没有渲染出动态内容，价格字段为空
SaaS定价页如果在Wayback抓取时JavaScript执行失败，存档的HTML里可能只有空壳，价格信息完全缺失。我在调用extract_prices后返回空列表，导致版本对比时误判为"降价到0元"。对比离散价格时$xx -> $0这种结果极其刺眼，一眼就能发现不对。
排查链路：拿一条价格为空的快照URL，直接在浏览器里打开，发现Wayback页面显示正常，但查看原始HTML后发现，动态接口的数据被剥掉了，页面里确实没有价格文本。确认是"抓取时JS未执行"导致的快照缺陷，而不是我的正则写错。处理方案是在extract_prices后面加一个"空值判定"，如果某个快照的价格集合为空，则不把它记入版本变更，只记录一条"快照内容缺失"的日志，方便人工回头补查。这个坑没有完美解法，因为快照缺陷是存档服务自身的问题，只能靠数据规侧来规避。
6.3 坑三：目标页面有随机参数或签名token，导致哈希频繁变化
我盯的一个SEO工具定价页，URL后面带一个?ref=abc123之类的参数，每次Wayback爬虫抓到的URL参数值不同，页面内容里还嵌入了当前时间戳。结果哈希对比几乎每次都是"变化"，版本记录被撑到几百条但实际上价格一条没动。
排查链路：先看页面HTML里哪些部分在变，用diff工具直接对比两个快照的HTML，一目了然是时间戳和跳转参数在变。解法分两步：第一步，正则把所有URL参数里的ref=xxx、utm_*之类的键值对删除，再算哈希；第二步，更狠一点，直接只对extract_prices提取出来的价格文本计算哈希，价格没变就算无变化。这一步做完之后，有效版本记录立刻从300多条缩到了12条，清爽多了。
7. 功能的扩展方向：从价格追踪到小型竞品情报系统
主体功能跑通之后，我的项目基本满足了自己最初的需求。但这套东西的价值是可以往外延伸的，我列几个我已经做了或者准备做的方向，供你参考。
7.1 多目标批量管理：一个配置搞定十个竞品
目前我做的事情是把目标SaaS产品的列表写在一个配置文件里，脚本启动时循环处理。每个产品一行记录，格式是目标名称, 目标URL, 开始日期, 采集策略。这样当我需要新增一个竞品时，只需要在配置里加一行，不需要动代码。注意不同产品的站点结构差异会影响提取逻辑，我一般每个产品单独配一个小函数来解析价格，但正则库是共享的。
7.2 价格变动通知：三行代码把变动推到企业企微/钉钉群
价格变动如果全靠人工盯CSV，依然会错过。我加了一个Webhook通知的功能：当检测到某产品price_change==True时，脚本自动把"产品名、时间、旧价格、新价格、快照链接"拼成一条消息，通过企微群机器人或钉钉机器人推送到群里。实现只需要几行Python代码，核心就是用requests.post发一个JSON到Webhook地址。这样即使我一个月不看脚本产出的CSV，群里也会有完整的调价记录。
7.3 历史数据可视化：价格走势图与套餐结构演变
最后一个扩展方向是可视化。我目前的做法是把版本记录CSV导入到一个简单的前端页面，用ECharts的时间线折线图展示价格走势，横轴是日期，纵轴是价格，每条线代表一个套餐（Basic、Pro、Enterprise）。这种图对决策特别有用——你可以直观看到某个竞品一年内涨了几次价、涨价的幅度是不是一次比一次大，以及涨价前是不是伴随着免费额度的缩减。套餐结构的演变则可以用表格做对比：2023年的时候有没有某个档位，2025年这个档位是被删了还是改名为别的，这些都是销售策略分析里非常关键的信息。
说到底，定价页历史版本采集这个项目的本质，是把"对方的商业决策过程"通过互联网存档技术还原出来，让你在做竞品分析、预算评估或者产品定价决策时，手里有一份扎实的数据而不是感觉和猜。这套东西的技术门槛不高，难度在于把数据链路做扎实：从CDX API拿索引，到抓快照内容，到提取结构化字段，再到变化检测和通知，每一步都需要考虑边界情况和历史数据本身的噪声。跑通主流程不难，真正花时间的是那些"页面结构变了""接口失败""参数干扰"这类看似不起眼但每个都会让结果失真的小问题，希望这篇记录能帮你少走一点弯路。
