简介这是一套面向电商价格监控场景的京东商品价格实时监控工具源码适合具备一定Python基础的开发者、爬虫学习者及有比价需求的用户参考。资源围绕商品价格抓取、数据存储与降价提醒展开可帮助读者理解从定时爬取到邮件通知的完整链路。压缩包共8个文件约7KB包含4个Python脚本负责爬取、数据库连接与邮件发送等核心逻辑、1个MySQL建表SQL、1个XML配置文件、1个开源协议及1份说明文档结构精简便于快速阅读与二次改造。目前已有283人学习下载。通过阅读源码读者可掌握价格数据采集、入库与阈值触发通知的实现思路并借鉴其模块划分方式为自建监控脚本或扩展多平台比价提供参考。1. 京东电商商品价格实时监控从“看价格”到“抓价格”的工程化落地做电商价格监控这件事很多人第一反应是“写个爬虫定时抓一下不就行了”。真上手才发现京东的商品页价格不是静态写在 HTML 里的而是通过异步接口返回、带签名、带时效、还跟登录态和风控策略强相关。你昨天能跑通的脚本今天可能就返回一个空价格或者干脆被限流。这篇文章不讲空泛的“数据采集重要性”而是把京东商品价格实时监控这套东西拆成能复现的工程方案接口怎么找、签名怎么处理、频率怎么控、数据怎么存、异常怎么兜底。适合两类人——想给自己关注的商品做个降价提醒的开发者以及需要批量监控竞品价格做定价参考的运营技术同学。核心目标只有一个让价格数据稳定、可追溯、能触发告警而不是抓一次就完事。2. 京东价格数据的来源与接口选型为什么不能只靠页面解析2.1 页面直出价格与异步接口价格的差异早期做京东价格监控最直接的办法是请求商品详情页然后用正则或 XPath 去匹配价格文本。这个做法在 PC 端页面改版前勉强能用但现在基本行不通。原因有三层第一商品页的很多内容是客户端渲染服务端返回的 HTML 里价格位置往往是占位符第二即使拿到了价格文本它可能是“促销价”“到手价”“划线价”混在一起语义不清晰第三页面请求体积大、耗时长批量监控时效率极低。真正稳定的做法是找到页面背后实际拉取价格的异步接口。常见的有两类一类是商品详情聚合接口返回 JSON 里包含价格字段另一类是独立的价格查询接口通常需要传入商品 IDskuId和区域信息。这两类接口的返回结构比页面干净得多字段明确适合程序化处理。需要注意的是不同商品类型自营、第三方、全球购走的接口可能不同返回字段名也有差异选型时要先确认目标商品的类型。2.2 接口鉴权与请求头的最小必要集合京东的异步接口不是裸奔的直接拿 requests 发一个 GET 大概率返回错误码或空数据。经过实际调试一个能跑通的请求通常需要以下几类信息用户代理User-Agent必须是一个常见浏览器的完整 UA不能是 python-requests 默认值。来源页Referer一般设为对应商品详情页的 URL部分接口会校验。Cookie这是最关键也最易变的部分。部分价格接口依赖登录态或至少是匿名会话产生的 Cookie比如 __jda、__jdb 这类设备标识。没有 Cookie 时接口可能返回默认区域的价格或直接拒绝。查询参数除了 skuId往往还需要 area地区编码、cat品类等缺一个就可能拿不到正确价格。下面是一个最小可跑的请求示例用 Python 的 requests 库演示import requests # 目标商品 skuId这里用占位数字 sku_id 100000000001 # 请求头UA 和 Referer 是必须的Cookie 需要从浏览器实际会话中提取 headers { User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36, Referer: fhttps://item.jd.com/{sku_id}.html, # Cookie 字段根据实际会话填写这里仅示意结构 Cookie: __jdaxxx; __jdbxxx; __jdcxxx; __jduxxx } # 价格接口地址不同时期路径可能变化以实际抓包为准 url fhttps://p.3.cn/prices/mgets?skuIdsJ_{sku_id}type1 resp requests.get(url, headersheaders, timeout10) print(resp.status_code) print(resp.text)这段代码的逻辑很直白构造一个带完整请求头的 GET 请求去访问价格查询接口。参数说明上skuIds 的格式通常是 J_ 加上纯数字 IDtype1 表示返回 JSON 格式。返回结果一般是一个列表里面包含 p当前价、m市场价、op原价等字段。如果返回为空列表或状态码非 200优先检查 Cookie 是否过期、Referer 是否匹配、skuId 是否有效。提示Cookie 的获取不要用硬编码建议从浏览器开发者工具里复制一次后用配置文件或环境变量管理方便后续更新。2.3 区域与促销信息的处理边界京东的价格是跟区域挂钩的同一个 skuId 在不同省份可能显示不同价格尤其是大家电、生鲜类目。接口里的 area 参数就是用来指定地区的格式一般是“省份ID_城市ID_区县ID”比如 1_72_2799 代表北京某区。如果不传 area接口可能返回一个默认区域的价格跟你实际看到的不一致。另一个容易翻车的地方是促销价。接口返回的 p 字段通常是当前展示价但可能不包含“满减”“优惠券”“plus 会员价”这些叠加后的最终到手价。如果你的监控目标是“用户实际能买到的价格”就需要额外去解析促销信息接口或者至少把 p 和 op 的差值作为参考。我的建议是第一版监控先只盯 p 字段把链路跑通等稳定后再逐步接入促销计算逻辑不要一上来就追求“到手价”否则复杂度会指数级上升。3. 实时监控的调度与存储从单次抓取到持续运行3.1 调度频率与风控规避的平衡“实时”这个词在价格监控里要打个折扣。你不可能每秒去请求一次京东接口那样用不了多久 IP 就会被限制。实际工程中合理的频率取决于监控商品数量和目标精度少量商品几十个可以做到 1 到 5 分钟一次分散请求每次间隔随机 1 到 3 秒。中等规模几百个建议 10 到 15 分钟一轮用队列控制并发单 IP 并发不超过 2。大规模上千个必须引入代理池或多 IP 轮换否则单机跑不动。下面是一个用 Python 的 schedule 库做简单调度的例子配合随机延迟import time import random import schedule def job(): # 这里调用前面封装好的价格抓取函数 print(开始抓取价格...) # 模拟抓取耗时 time.sleep(random.uniform(1, 3)) print(本轮抓取完成) # 每 5 分钟执行一次 schedule.every(5).minutes.do(job) while True: schedule.run_pending() # 每次循环随机休眠避免固定节奏被识别 time.sleep(random.uniform(0.5, 1.5))逻辑说明schedule 负责定时触发random 用来打散请求间隔。参数上5 分钟是经验值商品多的时候可以放宽到 10 分钟。注意不要在 job 里写死循环否则会阻塞调度。如果商品数量大建议用 Celery 或 APScheduler 做分布式调度把每个商品作为一个独立任务分发。3.2 数据表结构设计与去重策略价格数据的特点是“时间序列 商品维度”存储时至少要记录skuId、抓取时间、当前价、原价、区域编码、促销标记。用 SQLite 做本地存储就够用表结构可以这样设计CREATE TABLE price_history ( id INTEGER PRIMARY KEY AUTOINCREMENT, sku_id TEXT NOT NULL, price REAL NOT NULL, original_price REAL, area_code TEXT, promo_flag INTEGER DEFAULT 0, crawl_time DATETIME DEFAULT CURRENT_TIMESTAMP ); -- 建索引加速按商品和时间的查询 CREATE INDEX idx_sku_time ON price_history (sku_id, crawl_time);字段说明price 存当前价original_price 存划线价promo_flag 标记是否有促销。去重策略上不建议每轮都无脑插入而是先查最近一条记录如果价格没变且距离上次抓取不到 30 分钟就跳过写入避免数据表膨胀。这个逻辑可以在应用层做也可以用 SQL 的 INSERT OR IGNORE 配合唯一约束实现。3.3 价格变动检测与告警触发监控的核心价值在于“价格变了能知道”。最简单的做法是每轮抓取后跟上一轮的价格做对比如果降幅超过阈值比如 5%就触发告警。告警通道可以用邮件、Webhook 或者本地弹窗。下面是一个对比逻辑的片段def check_price_drop(sku_id, new_price, threshold0.05): # 从数据库取该商品最近一次价格 last_price get_last_price(sku_id) if last_price is None: return False drop_ratio (last_price - new_price) / last_price if drop_ratio threshold: # 触发告警这里用打印代替实际通知 print(f商品 {sku_id} 降价 {drop_ratio:.2%}当前价 {new_price}) return True return False参数说明threshold 是降价比例阈值0.05 表示降 5% 才告警。这个值不要设太小否则促销活动期间会频繁触发。如果要做“涨价提醒”或“历史最低价提醒”逻辑类似改一下比较方向即可。4. 避坑与常见问题排查那些让我熬夜的翻车现场4.1 返回价格为空或为 0 的几种原因现象接口返回 200但价格字段是空字符串或 0。原因通常有三种Cookie 失效导致接口降级返回默认值area 参数缺失或错误接口无法定位区域skuId 对应的商品已下架或库存为零。解决方式先检查 Cookie 有效期建议每次启动时用浏览器重新获取一次再确认 area 编码是否跟目标地区匹配最后用商品页手动验证是否还在售。4.2 请求频率过高导致 IP 被临时限制现象连续跑了几百次请求后接口开始返回 403 或验证码页面。原因单 IP 请求过于密集触发了风控。解决降低频率增加随机延迟必要时引入代理池。我的血泪经验是不要等到被封了才想起来加延迟一开始就把间隔设成 2 秒以上能省很多事。4.3 价格字段含义混淆导致误判现象监控显示降价了但实际去页面看并没有。原因接口返回的 p 字段可能是“促销价”或“会员价”而页面展示的是“到手价”两者口径不同。解决在告警前加一层校验把接口价格和页面价格做一次抽样比对确认口径一致后再用于决策。4.4 数据库写入并发冲突现象多线程抓取时SQLite 报 database is locked。原因SQLite 默认的写锁机制不支持高并发写入。解决改用 WAL 模式或者把写入操作集中到一个单线程队列里。如果数据量大直接上 PostgreSQL 或 MySQL 更省心。4.5 商品 ID 变更或合并导致监控断档现象某个 skuId 突然抓不到数据但商品还在卖。原因商家可能下架旧链接、上架新链接或者把多个规格合并到一个新 skuId。解决在监控列表里维护“商品组”概念一个商品对应多个 skuId任一有效即可。同时定期检查失效 ID自动标记并提醒人工确认。5. 进阶技巧用历史价格曲线做决策而不是只看当前价跑通基础监控之后真正有价值的是把价格数据用起来。我一般会做两件事一是画历史价格曲线二是算价格分位数。曲线能直观看出一个商品的价格波动规律比如是不是每逢大促前先涨价再降价。分位数则能回答“当前价格在历史上处于什么水平”——如果当前价低于过去 90 天 10% 分位那大概率是入手好时机。具体实现上可以用 pandas 做聚合分析import pandas as pd import sqlite3 conn sqlite3.connect(price.db) df pd.read_sql(SELECT * FROM price_history WHERE sku_id ?, conn, params(100000000001,)) # 按天取最低价避免促销瞬时低价干扰 daily_min df.groupby(df[crawl_time].str[:10])[price].min() # 计算 10% 和 90% 分位数 q10 daily_min.quantile(0.1) q90 daily_min.quantile(0.9) print(f90天 10% 分位价{q10:.2f}) print(f90天 90% 分位价{q90:.2f})这段代码的逻辑是先按天聚合出每日最低价再算分位数。参数上分位数的选择取决于你的风险偏好10% 偏激进25% 更稳妥。注意 crawl_time 是字符串格式切片取前 10 位就是日期部分如果存的是 datetime 类型需要先转换。另一个实用技巧是设置“动态阈值告警”。不要固定降 5% 就告警而是根据该商品的历史波动率来定。波动大的商品阈值设宽一点波动小的阈值收紧。这样能减少无效告警让每一次提醒都值得点开看。最后说一个我自己的习惯每次调整抓取策略后先拿 5 个商品跑 24 小时观察数据完整率和告警准确率确认没问题再扩大到全量。这个“小步验证”的习惯帮我省了很多后悔药。希望帮到你。本文还有配套的精品资源点击获取
