简介：面向有跨平台购物比价需求的消费者，这款唯品会得物商品比价工具借助自动化技术，实时抓取两个电商平台的商品价格并进行对比，帮助用户更快做出明智的购买决策。压缩包内共38个文件，以exe主程序、dll功能库、xml配置与数据文件为主，另含说明文档与pdb调试信息，整体体积约13.56MB，目录结构便于按模块查阅。已有4438人浏览学习。工具完整展示了自动化比价的实现路径：通过浏览器驱动模拟登录与搜索操作，抓取商品页面或调用接口获取数据，再利用JSON解析和内存高效处理完成信息清洗，最终由表格控件直观呈现各平台价格对比。这套工程覆盖了爬虫、Selenium自动化、.NET数据操作及桌面界面开发等关键环节，对于想研究电商数据采集与对比工具实现的开发者，是一份可上手的实战案例。
1. 顺手写了个唯品会得物比价工具：先把“到手价”这三个字搞明白
唯品会做品牌特卖、得物做潮流球鞋和鉴定交易，两边同一个商品标价经常差几百块。但直接比标价没有意义——唯品会有满减券和会员折扣，得物在卖家价之外还要收技术服务费和鉴别费，真正该比的是各自结算页里的“到手价”。这个工具我做了三件事：把两个平台的搜索和商品详情采集下来，按货号把同一双鞋/同一件衣服归到一条记录上，再用各自的价格口径算出实际开销推给用户。适合两类人：一类是自己想买但不想做表格手动对价的朋友，另一类是做商品价格监控、需要持续跑数据的从业者。刚跑通第一版时我觉得很稳，结果第三天就发现在匹配逻辑上翻了大车，后面会细说。
2. 商品匹配与比价口径：同一双鞋，凭什么认定是同一件
2.1 标题匹配的陷阱：唯品会叫“潮流板鞋”，得物叫“AJ1 Mid”
比价工具的第一个难点不是采集，而是“匹配”。唯品会的商品标题偏营销风，比如“耐克男鞋新款复古低帮板鞋 缓震休闲运动鞋”，得物的标题则是结构化的“Air Jordan 1 Mid SE Craft 黑白 男子篮球鞋 2024款”。两个标题对不齐，用字符串包含、编辑距离都容易错配：编辑距离会把“Nike Dunk 黑白”和“Nike Dunk Low 黑白”判成同一个商品，实际上这是两个货号的产品。
我的处理方式是先做特征提取，再做归一化匹配。特征是硬指标：品牌名、系列名、官方货号（Style Code）、配色关键词。唯品会详情页里通常带“货号”字段，得物商品详情也有对应的货号信息，只是藏在页面 JSON 里。先把两边都解析成统一结构，再按货号优先匹配，货号缺失时用“品牌+系列+配色”三元组做模糊匹配。这一步做完，匹配准确率才从我开始时的不到 60% 拉到 90% 以上。
下面这段是货号提取和归一化的核心代码，我在两个平台的详情页 JSON 里都跑过：
import re # 货号常见格式：3~6位字母/数字组合，如 CT8532-104、DH3716-100 STYLE_CODE_PATTERN = re.compile( r'\b([A-Z]{1,3}\d{3,4}[-]?\d{3})\b' ) def extract_style_code(raw_text: str) -> str | None: """ 从商品标题或详情JSON字段里提取官方货号。 raw_text: 拼接了标题、子标题、规格字段的纯文本 返回: 统一格式的货号，例如 CT8532-104；找不到返回 None """ if not raw_text: return None upper_text = raw_text.upper() # 先去掉常见干扰词，避免把“NIKE”后的数字误认成货号 upper_text = upper_text.replace('NIKE', ' ').replace('AIR JORDAN', ' ') match = STYLE_CODE_PATTERN.search(upper_text) if not match: return None # 统一去掉横杠，方便两边对比：CT8532-104 -> CT8532104 return match.group(0).replace('-', '') def normalize_color_keywords(text: str) -> str: """ 把配色关键词归一化，同名不同写法的色系在这里合并。 例如 'Black/White' 与 '黑白' 都映射到 '黑白' """ text_lower = text.lower() color_map = { "black/white": "黑白", "黑白": "黑白", "triple white": "纯白", "纯白": "纯白", } for key, val in color_map.items(): if key in text_lower: return val return text_lower.strip()货号提取用正则匹配，命中后统一去横杠，是因为唯品会可能显示为CT8532-104，得物可能显示成CT8532104，不去横杠就直接错过。normalize_color_keywords是为了解决两边语言习惯不同的问题：得物用英文配色，唯品会用中文，得先映射到同一套枚举值再参与匹配。这一步的教训是：不要一上来就搞机器学习匹配，先把手里的规则特征吃干净，大部分场景规则就够了。
2.2 到手价口径：唯品会算完券，得物还要加鉴定费
两个平台的“到手价”含义不一样，这是比价工具的第二道坎。
唯品会的到手价逻辑：商品标价 - 优惠券金额 - 会员折扣（如果有）。优惠券是全场券还是品类券，金额什么时候抵扣，在接口里都有明确字段。缺点是要在登录状态下才能拿到真实会员价，未登录看到的通常是“划线价”或原价。
得物的到手价逻辑：卖家价 + 技术服务费 + 鉴别费 + 运费。技术服务费按卖家价的一定比例收，有上限；鉴别费按品类固定；运费视卖家发货方式而定。得物页面显示的“到手价”是平台帮买家算好的，但采集接口里的字段分散在不同层级，需要自己把服务费率和基础价格兜齐。
下面是我定义的价格模型，两边采集后的数据都折算进这个结构：
from dataclasses import dataclass @dataclass class FinalPrice: """统一后的最终到手价模型""" platform: str # 'vip' 或 'dewu' raw_price: float # 页面标注价/卖家价 discount: float # 折扣或优惠金额（唯品会） service_fee: float # 技术服务费（得物） auth_fee: float # 鉴别费（得物） shipping: float # 运费 final_price: float # 最终到手价 def __post_init__(self): if self.platform == 'vip': self.final_price = self.raw_price - self.discount elif self.platform == 'dewu': self.final_price = self.raw_price + self.service_fee + self.auth_fee + self.shipping def is_lower_than(self, other: 'FinalPrice', threshold: float = 0.0) -> bool: """比较两个平台的到手价，返回是否比对方便宜超过 threshold 元""" return self.final_price + threshold < other.final_price这个数据类把两边的价差计算统一成同一套接口：唯品会价格等于“标价减优惠”，得物价格等于“卖家价加一堆费用”。判断是否值得买时，我用is_lower_than带一个阈值参数，默认 0 表示只要便宜就算，实际用的时候我会把阈值设成 30 元——差不到 30 块钱不值得换平台折腾。这个阈值在后面的监控告警里也是同一个参数，避免为了一两块钱频繁推送。
3. 采集层落地：搜索接口与页面解析的完整代码
3.1 唯品会搜索页：JSON 接口与签名参数的应对思路
唯品会的搜索页走的是内部 JSON 接口，浏览器地址栏里的 URL 是 SEO 页面，直接抓 HTML 效率低、数据杂，我从 Network 面板里找到了search.do?keyword=xxx这个接口，返回的 JSON 里有list字段，每一项包含title、price、salePrice、brandName、goodsId这些核心字段。
但接口有个 signature 参数，是服务端动态生成的，直接裸请求会被丢到验证码页。我的处理方式是：用 requests.Session 维持 cookie，先访问一次搜索首页种下基础 cookie，再用同一个 Session 带上一组固定的 Header 集合去请求搜索接口——常见做法是把浏览器里的Accept、User-Agent、Referer按顺序放好，Referer 必须指向唯品会搜索页，否则部分接口会返回 403。
import requests import time import json 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" ), "Accept": "application/json, text/plain, */*", "Referer": "https://www.vip.com/search.html", "Origin": "https://www.vip.com", "Accept-Language": "zh-CN,zh;q=0.9", } session = requests.Session() session.headers.update(HEADERS) def search_vip(keyword: str, page: int = 1) -> list[dict]: """ 搜索唯品会商品，返回商品基础信息列表。 keyword: 搜索关键词，例如 'Air Jordan 1' page: 页码，接口从 1 开始 """ url = "https://search.vip.com/search.do" params = { "keyword": keyword, "page": page, "pagesize": 60, "needPop": "false", "source": "search", } resp = session.get(url, params=params, timeout=10) # 常见做法：先判状态码再判返回结构，防止拿到验证码页面的 HTML if resp.status_code != 200: return [] try: data = resp.json() except json.JSONDecodeError: # HTML 响应说明被重定向到验证码页，稍后重试 return [] items = [] for raw in data.get("list", []): # salePrice 是活动价，price 是划线价，比价统一用 salePrice items.append({ "goods_id": raw.get("goodsId"), "title": raw.get("title", "").strip(), "brand": raw.get("brandName", ""), "final_price": float(raw.get("salePrice", raw.get("price", 0))), "product_url": "https://www.vip.com/detail-" + str(raw.get("goodsId")) + ".html", }) return items这里有几个参数需要重点说明：pagesize我设成 60，是唯品会一次返回的最大数量，设大了不会多给还会超时；needPop固定false，是为了省掉弹窗信息；salePrice才是用户最终付款价，price是划线价，取错字段会把比价结果拉偏。如果返回空列表但状态码是 200，八成是signature校验失败——这时候加一个time.sleep(2)等冷却，再用带 cookie 的 Session 重新请求，比换代理更管用。
3.2 得物搜索与详情页：加密参数靠解析 HTML 里的NEXT_DATA
得物的反爬比唯品会严：搜索接口带platform、clientTag等请求头校验，直接调 JSON 接口容易被风控，所以我绕了一步——用常见做法“先请求搜索列表页 HTML，再从 HTML 里的__NEXT_DATA__脚本标签解析商品数据”。这个字段是 Next.js 应用在服务端渲染时内嵌的 JSON，包含搜索结果的完整信息，能拿到商品 id 和标题。
拿到商品 id 后再请求详情页，详情页同样有__NEXT_DATA__，里面的goods对象里有priceInfo和serviceFeeRate。解析时用正则把<script id="__NEXT_DATA__" type="application/json">...</script>里的内容抠出来，再走json.loads。
import re import json import time import requests DETAIL_HEADERS = { "User-Agent": ( "Mozilla/5.0 (iPhone; CPU iPhone OS 16_6 like Mac OS X) " "AppleWebKit/605.1.15 (KHTML, like Gecko) Version/16.6 Mobile/15E148 Safari/604.1" ), "Accept": "text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8", } session = requests.Session() session.headers.update(DETAIL_HEADERS) def parse_next_data(html: str) -> dict: """从 HTML 中提取 __NEXT_DATA__ 并解析为 JSON 对象""" m = re.search( r'<script id="__NEXT_DATA__" type="application/json">(.*?)</script>', html, re.DOTALL, ) if not m: return {} try: return json.loads(m.group(1)) except json.JSONDecodeError: return {} def search_dewu(keyword: str) -> list[dict]: """ 搜索得物商品，从列表页的 __NEXT_DATA__ 提取商品信息。 keyword: 搜索关键词 """ url = "https://www.dewu.com/search" params = {"keyword": keyword} resp = session.get(url, params=params, timeout=10) if resp.status_code != 200: return [] data = parse_next_data(resp.text) # 不同页面里商品列表所在的路径略有差异，常见做法是逐层取 props page_props = data.get("props", {}).get("pageProps", {}) or {} goods_list = page_props.get("searchResult", []) or [] items = [] for raw in goods_list: items.append({ "spu_id": raw.get("spuId"), "title": raw.get("title", ""), "brand": raw.get("brandName", ""), "ref_price": raw.get("refPrice", 0), "product_url": f"https://www.dewu.com/product/{raw.get('spuId')}.html", }) return items得物搜索结果里的refPrice是参考价，不是真实到手价，这里只做展示和匹配用；真实到手价必须进详情页拿价格模型。移动端 UA 是我反复试出来的——得物对 PC UA 的详情页会注入风险检测脚本，移动端反而宽松一些。这个差异没有文档，属于血泪经验，如果你跑的时候发现 PC 端频繁被校验，直接换 iPhone UA 再试，能少走半天弯路。
4. 数据层与比价计算：SQLite 存储与到手价算法
4.1 三张表的结构设计：商品表、价格表、历史表
比价不是一次性请求，而是持续跑。我用 SQLite 做持久化，三张表：products存商品基础信息和货号，prices存当前两条平台价格记录，price_history存每次采集的价格快照。价格表和历史表分开的原因是：当前价格是覆盖写的，历史价格是追加写的，混在一张表里会让查询越来越慢。
建表 SQL 我放在下面，字段命名尽量直白，后续写统计查询时不用翻文档：
CREATE TABLE IF NOT EXISTS products ( id INTEGER PRIMARY KEY AUTOINCREMENT, style_code TEXT, -- 归一化货号，如 CT8532104 brand TEXT, -- 品牌名 product_name TEXT, -- 商品名 vip_goods_id TEXT, -- 唯品会商品 ID dewu_spu_id TEXT, -- 得物 SPU ID created_at TEXT DEFAULT (datetime('now', 'localtime')), UNIQUE(style_code) ); CREATE TABLE IF NOT EXISTS prices ( id INTEGER PRIMARY KEY AUTOINCREMENT, product_id INTEGER NOT NULL, platform TEXT NOT NULL, -- 'vip' 或 'dewu' final_price REAL NOT NULL, -- 最终到手价 raw_data TEXT, -- 保留原始响应字段，方便排查 updated_at TEXT DEFAULT (datetime('now', 'localtime')), UNIQUE(product_id, platform), FOREIGN KEY (product_id) REFERENCES products(id) ); CREATE TABLE IF NOT EXISTS price_history ( id INTEGER PRIMARY KEY AUTOINCREMENT, product_id INTEGER NOT NULL, platform TEXT NOT NULL, final_price REAL NOT NULL, created_at TEXT DEFAULT (datetime('now', 'localtime')), FOREIGN KEY (product_id) REFERENCES products(id) );products表里的vip_goods_id和dewu_spu_id单独存而不是只存一个商品 ID，是为了保持双平台映射关系。UNIQUE(style_code)在写入时做幂等保护：同一个货号重复采集不会插入新商品行，而是更新平台字段和价格。raw_data字段保留接口原始响应，排查“这个价格为什么算出来不对”时，直接翻这条记录就知道是不是采集阶段取错了字段。
4.2 比价主流程：采集、匹配、入库三步串起来
入库之后就是核心的比价流程。我把它写成一个独立函数，每一步都打日志，方便定时任务跑挂时快速定位：
import sqlite3 from datetime import datetime DB_PATH = "compare.db" def run_compare(keyword: str) -> dict: """ 主流程：采集唯品会和得物数据 -> 匹配 -> 入库 -> 返回比价结果 keyword: 搜索关键词，建议带上品牌和系列名，例如 'nike dunk' """ conn = sqlite3.connect(DB_PATH) conn.execute("PRAGMA journal_mode=WAL") # 1. 采集 vip_items = search_vip(keyword) dewu_items = search_dewu(keyword) if not vip_items or not dewu_items: conn.close() return {"status": "empty", "msg": "单边无数据，跳过"} # 2. 按货号匹配，匹配不到的可选规则再兜底一次 merged = [] for vip in vip_items: vip_style = extract_style_code(vip['title']) for dewu in dewu_items: dewu_style = extract_style_code(dewu['title']) if vip_style and vip_style == dewu_style: merged.append({"vip": vip, "dewu": dewu, "style_code": vip_style}) break # 3. 入库并计算比价结果 results = [] for pair in merged: product_id = upsert_product(conn, pair) vip_price = upsert_price(conn, product_id, "vip", pair["vip"]) dewu_price = upsert_price(conn, product_id, "dewu", pair["dewu"]) diff = round(vip_price - dewu_price, 2) cheap_platform = "vip" if diff > 0 else "dewu" results.append({ "product_id": product_id, "style_code": pair["style_code"], "vip_price": vip_price, "dewu_price": dewu_price, "diff": abs(diff), "cheap_platform": cheap_platform, }) conn.close() return {"status": "ok", "results": results} def upsert_product(conn: sqlite3.Connection, pair: dict) -> int: """按货号插入或更新商品表，返回 product_id""" cur = conn.execute( """ INSERT INTO products (style_code, product_name, vip_goods_id, dewu_spu_id) VALUES (?, ?, ?, ?) ON CONFLICT(style_code) DO UPDATE SET vip_goods_id = excluded.vip_goods_id, dewu_spu_id = excluded.dewu_spu_id """, ( pair["style_code"], pair["vip"]["title"], pair["vip"]["goods_id"], pair["dewu"]["spu_id"], ), ) conn.commit() select_cur = conn.execute( "SELECT id FROM products WHERE style_code = ?", (pair["style_code"],) ) return select_cur.fetchone()[0] def upsert_price(conn: sqlite3.Connection, product_id: int, platform: str, item: dict) -> float: """ 更新当前价格并追加历史快照，返回最终到手价。 item: 采集阶段的商品字典，需包含 final_price 字段 """ price = float(item.get("final_price", 0)) if price <= 0: return 0.0 conn.execute( """ INSERT INTO prices (product_id, platform, final_price, raw_data, updated_at) VALUES (?, ?, ?, ?, ?) ON CONFLICT(product_id, platform) DO UPDATE SET final_price = excluded.final_price, raw_data = excluded.raw_data, updated_at = excluded.updated_at """, (product_id, platform, price, json.dumps(item, ensure_ascii=False), datetime.now().isoformat()), ) conn.execute( "INSERT INTO price_history (product_id, platform, final_price) VALUES (?, ?, ?)", (product_id, platform, price), ) conn.commit() return price匹配逻辑里有个容易忽略的点：唯品会一个goodsId可能对应多个 SKU 规格，得物一个spuId下也有多个尺码。我比价时用整个搜索列表，取标题里出现的商品进行匹配；如果你要精确到尺码，需要把尺码维度也加进products表的唯一键，否则会出现 42 码得物 900 元、唯品会 45 码 850 元被当成同一双鞋的尴尬。SQLite 开WAL模式是为了让定时任务和手动查询并发运行不锁库，数据量上来之后这个设置能明显减少database is locked报错。
5. 避坑排查：六个翻车点，测了一周才稳定
5.1 得物登录态过期，价格字段集体变 0
现象：跑了半天的定时任务，突然某一次采集后所有得物商品价格全部是 0，直达详情页也正常。 原因：得物的价格接口依赖登录态的X-Token，token 过期后接口不报错，只是把价格字段返回为空或 0，程序把空值当成了合法价格入库，后续比价全部错乱。 解决：在search_dewu和详情解析里加一道校验——price <= 0时直接丢弃，返回空列表；同时把 Session 里的 cookie 和 token 持久化到本地文件，每次请求前检查 token 时间戳，超过 6 小时就提示重新登录并暂停采集。从那以后我每次采集前都强制走一遍价格有效性检查，不是跑到一半才发现数据废了。
5.2 唯品会salePrice不恒定，区间价会误导比价
现象：同一个商品昨天采集到手价 399，今天变成 429，同一页面点进去却是 379。 原因：唯品会的salePrice在搜索列表接口里给的是“区间价”或“多人团价”，不同用户、不同登录状态下看到的值不同；详情页里的价格带上会员标识，才是当前账号的最终支付价。 解决：比价时搜索列表的价格只做初筛，拿到goodsId后进详情页取salePrice和优惠券信息，再参与计算。我用FinalPrice数据类时也把discount独立出来，方便按账号维度配置优惠券模板，而不是把优惠揉进raw_price里。
5.3 匹配错配：同系列不同配色被合成了同一个商品
现象：Air Jordan 1 Low Black和Air Jordan 1 Low White被匹配成同一商品，比价结果里出现“同款价格差 400 元”。 原因：货号缺失时只用了“品牌 + 系列”匹配，丢掉了配色特征。两个商品货号前几位相同，系列名也一样，唯一区分是货号后缀或配色字段。 解决：匹配算法升级为两级——第一优先级是完整货号，第二优先级是“品牌 + 系列 + 归一化配色”，只有三元组完全一致才确认匹配。同时把两个平台的货号后缀也纳入比较，例如CT8532-104与CT8532-107属于不同配色，不能合并。这个坑后来被我列成一条校验规则：凡是匹配结果里两边标题差异大于 25%，直接打回人工审核。
5.4 访问频率过快，两个平台同时触发验证码
现象：批次跑到第 100 个关键词时，唯品会的响应从 JSON 变成 HTML，得物直接返回 403，整批数据带回去全是空的。 原因：采集用了固定time.sleep(0.5)，单线程看似不快，但 Session 复用加上无随机抖动，被风控按 IP 维度识别成了脚本特征。 解决：延迟改成随机区间time.sleep(random.uniform(2, 5))，并且每跑 20 个关键词强制停 30 秒。如果还触发验证码，就先降到请求频率而不是换代理，因为换代理后 cookie 重建的成本更高。这个踩坑经验只写在这，网上很多教程不会提——他们给的都是“失败后重试”，不告诉你失败往往是因为太快。
5.5 得物详情页的__NEXT_DATA__里价格路径在不同品类不一样
现象：球鞋详情页能解析出priceInfo，但潮流服饰详情页解析出来是空字典，程序直接抛 KeyError。 原因：得物对不同品类的商品结构做了差异化渲染，部分品类没有priceInfo字段，而是saleInfo；字段路径不是统一的。 解决：解析时用.get()多级兜底，同时记录字段路径日志，发现新品类时打印原始 JSON 的 key 树，人工补充解析规则。常见做法是把“路径查找器”单独抽成一个函数，传入一组候选路径，命中哪个用哪个，新增品类只需加路径不需要动主流程。
5.6 SQLite 并发写入导致database is locked
现象：定时任务和手动跑脚本同时打开数据库时，手动脚本抛出OperationalError: database is locked。 原因：SQLite 默认是写锁粒度，两个写事务同时提交时会锁库；跑定时任务时忘了主动关闭连接，连接池占着锁不放。 解决：连接时执行PRAGMA journal_mode=WAL，写操作统一走同一个函数入口，并设置timeout=30。WAL 模式下读和写可以并发，timeout则让写冲突时等待而不是直接报错。从那以后我每次建库都会在连接初始化时强制走一遍这两个 pragma 设置，算是一个止血习惯。
6. 进阶：价格变动的持续监控与告警
比价工具的用处不只在于“当下谁便宜”，更在于“什么时候值得出手”。我把历史价格表和当前价格表对比，每次采集后检测三天内的最低价和跌幅，一旦跌幅超过阈值就触发告警。这里我用一个简单 SQL 查询：
SELECT product_id, platform, MIN(final_price) AS min_price, MAX(final_price) AS max_price, ROUND((MAX(final_price) - MIN(final_price)) / MIN(final_price) * 100, 2) AS drop_pct FROM price_history WHERE created_at >= datetime('now', '-3 days', 'localtime') GROUP BY product_id, platform HAVING drop_pct >= 5;这条查询扫描近三天的价格快照，按商品和平台分组，算出最大跌幅百分比，只保留跌幅超过 5% 的记录。落到定时任务里，我一般用 APScheduler 每隔两小时跑一次全量比对，命中告警就推一条消息，内容包含商品名、平台、降价前后价格和直达链接。阈值 5% 是经验值——球鞋这类商品日常波动就有 3% 左右，低于 5% 推出来全是噪音，时间长了就没有人看告警了。
告警函数里我会把同款商品的两端价格并排显示，如果唯品会降价比得物更多，就自动标记“建议唯品会入手”。这个逻辑不复杂，但很实用：用户点进来看的不是两个平台的数字，而是“现在该去哪买”的直接结论。运行一段时候后，可以把命中告警的商品回填到一张专门追踪的表里，连续三天都在降价且跌幅扩大的，列为重点观察名单。
这个项目真正跑通花了接近两周，大部分时间耗在字段不确定和频率控制上。每当我想再加一个新平台或新品类时，都会先想想：任务是要覆盖更宽，还是让数据更稳？从那以后我每次改完采集逻辑，都会强制跑一遍本地全量校验，把 0 价格、空响应、匹配异常各标记一类颜色，确认三类都清零才放它上线。希望帮到你。
本文还有配套的精品资源，点击获取
