简介mercari-scanner 是一套基于 Python 的 Mercari 新商品扫描与提醒工具面向海淘代购人群和二手市场研究者旨在解决手动刷新页面容易错过心仪商品的问题。工具支持通过命令行参数 --min-price 与 --max-price 设置价格区间并可传入商品关键词扫描到新上架物品后通过 Slack API 推送到指定频道或群组响应及时且配置灵活。资源包共包含 2000 个文件其中 Python 脚本.py数量最多同时汇集了大量 C 头文件、.txt 配置及说明、.json 数据等辅助文件整体体积约 13.71MB从内容预览可见 lxml 等第三方依赖库的头文件也被完整收纳目录结构清晰便于离线部署。项目自带 config.ini 配置示例使用者只需填入自己的 Slack Token 和频道名称即可搭配启动脚本快速运行也可按需调整价格下限、上限和关键词。目前已有 509 人浏览学习适合具有一定 Python 基础的开发者和二手交易玩家直接使用或作为学习商品监控、Webhook 消息推送的实战参考。1. 新物品扫描不是爬全站先搞清楚它解决什么问题做跨境选品和日淘盯货的人应该都遇到过这个场景某个品牌的热门款刚挂上架几分钟内就被拍走等人工刷到的时候只剩“已售罄”三个字。想第一时间拿到 Mercari 上刚发布的新品列表却发现平台没有面向个人用户的“订阅新上架”功能。能用到的入口只有一个——搜索结果页的“最新排序”视图。于是不少人开始手动刷新但手速永远比不过机器人。这个项目就是用 300 行左右的 Python 把“定时抓取搜索页 → 按商品 ID 增量去重 → 推送到手机”这条链路自动化。适合有 Python 基础、想监控某个关键词下新挂单品的人代码量不大跑在普通服务器或本机即可。2. 架构与选型为什么用同步 requests 而不是重型爬虫框架2.1 轻量同步爬虫的合理性第一次看到这类扫描需求时很多人第一反应是上 Scrapy 或者 Selenium。但如果你只是每隔五分钟看一个搜索页这属于典型的轻量轮询任务。Scrapy 的异步调度、中间件、Item Pipeline 在这里几乎全用不上反而要把引擎配置、去重规则、日志体系都摸一遍上手成本远高于收益。Selenium 更不必说启动一个完整浏览器去渲染一个服务端已经渲染好的页面内存开销大而且部署时还要装 ChromeDriver版本匹配也是麻烦事。常见的做法是直接用requests抓 HTML再用lxml做 xpath 提取。这两个库加起来几百行代码就能覆盖全部需求。Mercari 的搜索结果页是服务端渲染的列表页里的商品卡片信息直接存在于 HTML 源码中不需要等待 JavaScript 二次加载。这也意味着传统的“看 Network 面板找 XHR 接口”的办法不是必须的拿到 HTML 字符串就能往下走。用requests.Session还有一个好处它会自动保存服务端下发的 cookies后续连续请求能保持同一个会话比每次新建一个连接更接近真实浏览器的行为。我当时实际做的时候第一步不是写抓取逻辑而是用浏览器的“查看源代码”确认商品卡片的 HTML 结构。只有先确认信息在源码里才能决定用同步请求还是无头浏览器。这个判断决定了整个项目的复杂度也决定了它到底能不能只靠一个requirements.txt就在新机器上跑起来。2.2 SQLite 做去重为什么不用 JSON 文件扫描器一旦跑起来最核心的问题不是“抓不到”而是“重复提醒”。同一个商品在两次扫描中都出现如果你没有去重机制用户就会收到两条一模一样的推送。这里就需要一个本地存储层。我见过有人用 JSON 文件保存已见商品 ID 列表每轮扫描后把整个列表读回来、追加、再写回去。数据量小的时候没问题但扫描器是长驻进程如果哪天你加了多关键词并发扫描两个进程同时写同一个 JSON 文件轻则丢数据重则文件损坏。SQLite 是更稳的选择。它不需要单独起数据库服务一个.db文件就是全部存储Python 标准库sqlite3直接支持。最关键的是它支持UNIQUE约束和INSERT OR IGNORE可以在数据库层面保证同一商品 ID 只被插入一次。这样一来去重逻辑不需要在 Python 代码里做双重判断直接把新抓到的商品 ID 往表里插根据插入影响的行数判断是不是新品就够了。这个模式简单、可靠也是我后来一直沿用的做法。2.3 提醒通道先搞定 SMTP 邮件再考虑聊天工具监控到新品之后怎么通知人这里我建议优先做 SMTP 邮件因为smtplib是 Python 标准库不需要额外申请任何平台的权限只要有一个可用的邮箱账号即可。邮件正文里放上商品标题、价格和链接手机上的邮件客户端会直接推送通知。后续如果想提升实时性可以在邮件的基础上增加企业微信群机器人或者其他的 Webhook 推送只需要往一个 URL POST 一段 JSON改动集中在单独一个notifier.py模块里不影响扫描主逻辑。有一点值得注意不要把提醒逻辑散落在抓取循环中。所有新商品的收集、格式化、批量发送应该集中到最后一步。否则某次解析异常导致循环中断前面发了一半的提醒就停在那里再跑一次又会重复发送。3. 核心实现抓取、解析、去重、提醒四个模块3.1 抓取模块搜索 URL 拼接与请求头Mercari 的搜索页 URL 结构并不复杂。把关键词、排序方式和页码拼接进去即可。需要注意的是关键词必须做 URL 编码尤其当你搜的是包含空格或者特殊符号的多词组合时直接拼进 URL 会导致请求失败或者返回空结果。以下是构造搜索 URL 的完整函数from urllib.parse import urlencode def build_search_url(keyword: str, sort: str new, page: int 1) - str: 构造 Mercari 搜索结果页 URL :param keyword: 搜索关键词比如 nike 帽子 :param sort: 排序方式new 表示最新上架优先 :param page: 页码从 1 开始 :return: 完整的搜索页 URL base_url https://www.mercari.com/jp/search/ params { keyword: keyword, sort: sort, page: page, } return base_url ? urlencode(params)这段代码的核心在于urlencode。它会自动处理关键词中的空格、日文假名和特殊字符保证生成的 URL 在浏览器里打开也能得到同样的结果。sortnew是“最新上架优先”的参数我在做监控时只使用这个排序方式否则默认的“综合排序”会把低相关度的商品混进来干扰去重判断。有了 URL 之后还需要一个带请求头、超时和重试逻辑的抓取函数。这里我一般会写一个独立的模块级函数方便在后面加随机延时import requests import random import time 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-Language: ja-JP,ja;q0.9,en;q0.8, } def fetch_page(keyword: str, page: int 1) - str: url build_search_url(keyword, pagepage) for attempt in range(3): try: resp requests.get(url, headersHEADERS, timeout15) if resp.status_code 200: return resp.text # 常见错误403 表示被限流先等一段时间再重试 time.sleep(5 * (attempt 1)) except requests.RequestException as e: print(f第 {attempt 1} 次请求失败: {e}) time.sleep(3) return 抓取函数里我做了两件重要的事一是设置了Accept-Language: ja-JP因为 Mercari 会根据地点的语言偏好返回不同结构的页面锁定日语可以减少页面结构的差异二是对非 200 状态码做指数退避重试。在监控场景下偶尔一次网络抖动是正常的但如果连续三次都失败就说明 IP 可能已经被临时限流此时再重试已经没有意义不如先退出本轮扫描。3.2 解析模块从商品卡片里抽 item_id拿到 HTML 源码后下一步是提取商品信息。在写 xpath 之前我习惯先用开发者工具查看某一个商品卡片的结构。Mercari 的商品列表由一个个带有items-box类的区块组成每个区块内有一个指向商品详情页的链接。解析的目标就是从这个链接中提取商品 ID因为它是唯一的、永不变化的。商品标题、价格字段可能因为促销等原因变化但 ID 不会。from lxml import html def parse_items(html_text: str) - list: 从搜索页 HTML 中抽取商品信息 返回列表元素为字典包含 item_id/title/price/href doc html.fromstring(html_text) items [] # 选取所有商品卡片 cards doc.xpath(//section[contains(class, items-box)]) for card in cards: # 取卡片内的详情页链接 href_node card.xpath(.//a[contains(href, /items/)]) if not href_node: continue href href_node[0].get(href, ) if href.endswith(/): href href.rstrip(/) # 纯 ID 从链接尾部切割 item_id href.split(/)[-1] # 标题位于 class 含 name 的元素中 title_node card.xpath(.//h3[contains(class, name)]/text()) title title_node[0].strip() if title_node else 无标题 # 价格位于 class 含 price 的元素中格式可能带 ¥ price_node card.xpath(.//span[contains(class, price)]/text()) price price_node[0].strip() if price_node else 未知 if item_id.isdigit(): items.append({ item_id: item_id, title: title, price: price, href: https://www.mercari.com/jp/items/ item_id, }) return items这个解析逻辑有几个边界点。第一contains(class, items-box)用的是模糊匹配而不是精确匹配因为 Mercari 的 class 名称后面经常带随机的样式后缀精确匹配会失效。第二商品链接的末尾可能带?开头的追踪参数rstrip(/)之后按/切割可以稳定提取 ID。第三价格和标题都做了空值兜底不会因为某一个字段缺失就丢掉整条商品记录。我遇到过一种情况卡片内的图片是懒加载的图片节点的src属性是空白占位图真实图片地址在>import sqlite3 from datetime import datetime, timezone DB_PATH scanner.db def init_db(): conn sqlite3.connect(DB_PATH) conn.execute( CREATE TABLE IF NOT EXISTS seen_items ( item_id TEXT PRIMARY KEY, title TEXT, price TEXT, seen_at TEXT ) ) conn.commit() conn.close() def save_new_items(items: list) - list: 将商品列表写入数据库 返回真正新增的商品列表 conn sqlite3.connect(DB_PATH) new_items [] for item in items: cur conn.execute( INSERT OR IGNORE INTO seen_items (item_id, title, price, seen_at) VALUES (?, ?, ?, ?) , ( item[item_id], item[title], item[price], datetime.now(timezone.utc).isoformat(), ), ) if cur.rowcount 1: new_items.append(item) conn.commit() conn.close() return new_itemsINSERT OR IGNORE这个写法比“先 SELECT 判断再 INSERT”更安全。虽然在当前单进程版本中看不出区别但将来你若把扫描任务扩展到多线程两个线程同时查询到同一商品不存在、同时插入就会产生一条重复记录。直接在数据库层约束则完全避免了这个问题。seen_at字段存储的是 UTC 时间。这样做不是为了显示而是为了后面排查“为什么这个商品现在才提醒”这类问题时能有一个统一的基准时间避免因为服务器时区设置不同导致记录时间与实际时间偏差几小时。3.4 推送提醒SMTP 邮件模板与批量化新商品收集完毕最后一步是通知。这里我按“少量商品合并提醒”的思路做避免单条商品触发一封邮件造成邮件轰炸。把新增的商品列表拼接成一个纯文本邮件标题中带上关键词和商品数量正文里列出每条商品的链接。import smtplib from email.mime.text import MIMEText from email.header import Header SMTP_HOST smtp.example.com SMTP_PORT 465 SMTP_USER your_accountexample.com SMTP_PASS your_password MAIL_TO receiverexample.com def send_alert(items: list, keyword: str) - None: if not items: return lines [f关键词 {keyword} 发现 {len(items)} 个新商品, ] for idx, item in enumerate(items, 1): lines.append(f{idx}. {item[title]} - {item[price]}) lines.append(f 链接: {item[href]}) body \n.join(lines) msg MIMEText(body, plain, utf-8) msg[Subject] Header(f[监控] {keyword} 新上架 {len(items)} 件, utf-8) msg[From] SMTP_USER msg[To] MAIL_TO with smtplib.SMTP_SSL(SMTP_HOST, SMTP_PORT) as server: server.login(SMTP_USER, SMTP_PASS) server.sendmail(SMTP_USER, [MAIL_TO], msg.as_string()) print(f已发送提醒: {len(items)} 个新商品)SMTP_SSL直接走 465 端口省去了starttls的额外步骤。如果你用的是需要显式 TLS 的服务器把SMTP_SSL换成SMTP并调用server.starttls()即可。邮件正文里我刻意标出了“链接”这样用户在手机上可以直接点击跳转比复制商品 ID 再去搜索方便得多。4. 避坑与排查扫描器的五个常见翻车现场4.1 反复提醒同一条商品现象同一商品在首次提醒之后过了几分钟又收到一次一模一样的提醒。原因最常见的是分页抓取时第 1 页末尾和第 2 页开头存在重复商品。Mercari 的排序在翻页瞬间可能因为新商品上架而发生变化原本在第 1 页的商品被挤到第 2 页重新被抓取。如果你的去重键是“标题 价格”同一个商品标题和价格完全相同就会判断为新品。解决统一使用item_id作为唯一键也就是我在 3.2 节中从详情页链接尾部提取的那段纯数字。只要自始至终使用这个 ID翻页顺序变化不会造成重复。4.2 本地能解析出数据服务器上一条都没有现象在开发机上运行parse_items一切正常部署到服务器后日志显示“新商品数量为 0”但抓到的 HTML 文件内容肉眼看起来是正常的。原因服务器上默认的User-Agent是 Python-requestsMercari 对这类请求头返回的页面结构可能不同。更隐蔽的原因是 Accept-Language非日语环境的响应会附加大量无关 DOM导致 xpath 定位失效。解决固定使用浏览器 UA并显式设置Accept-Language: ja-JP。这不算伪装只是让服务端返回与浏览器一致的语言版本。4.3 扫描频率太高被临时限流现象跑了大半天之后某一次fetch_page返回 403之后连续几轮全部 403。原因请求间隔太短服务端通过 IP 访问频率识别出异常行为。尤其是单页扫描间隔低于 30 秒时触发限流的概率很高。解决把整体扫描循环间隔设为 60 秒以上并在每次请求之间加入 1 到 5 秒的随机延时。随机延时比固定延时更接近真人浏览行为能显著降低限流概率。4.4 记录时间与实际商品上架时间对不上现象数据库里seen_at记录的发现时间比商品图上显示的发布时间晚了 9 个小时。原因Mercari 服务端的业务时间基于日本标准时间JST而你的服务器时区可能是 UTC 或者本地时间。当你直接用datetime.now()记录时存的是服务器本地时间一旦换服务器部署记录就会混乱。解决存储一律使用datetime.now(timezone.utc)展示时再做时区转换。数据库里存的 UTC 时间只用于排查顺序问题不直接参与业务判断。4.5 提醒发出时商品已经失效现象收到提醒后点击链接页面提示“商品不存在或已下架”。原因商品在两次扫描之间被拍走或删除。这在热门商品上非常常见竞拍者可能在商品上架后几分钟内就下单。解决这是时效性问题的固有矛盾只能通过缩短扫描间隔来缓解。我一般把主扫描间隔设为 2 到 3 分钟同时在邮件正文中加一句“商品可能已失效请打开链接确认”这样用户不会因为一次空链接而认为扫描器坏掉了。5. 部署与自检从开发机到 7x24 稳定的进阶操作5.1 用 systemd timer 替代 crontab我在部署这类扫描器时不太用crontab -e因为 cron 任务没有内建的失败重试和日志管理能力。更可靠的做法是写一个 systemd service 处理单轮扫描再用 systemd timer 每隔固定时间激活它。service 文件的关键配置如下[Unit] DescriptionMercari Scanner [Service] Userscanner ExecStart/home/scanner/venv/bin/python /home/scanner/scanner.py Restarton-failure [Install] WantedBytimers.target对应的 timer 文件设置每 3 分钟运行一次[Timer] OnBootSec2min OnUnitActiveSec3min Unitmercari-scan.service [Install] WantedBytimers.target这样做的回报是每次扫描失败后 systemd 会自动重启服务journalctl -u mercari-scan.service可以看到完整日志排查 403 和超时问题非常方便。相比在 Python 代码里维护一个 while 循环这种进程生命周期完全交给系统管理的方式更加稳固系统重启后也不需要额外启动脚本。5.2 增加价格阈值与关键词黑名单随着扫描时间变长你会意识到一个问题某个关键词下每天可能有几十个新商品但真正值得看的只有价格低于某个区间的。与其每次收到提醒后人工筛选不如在save_new_items之后加一道过滤def filter_items(items: list, max_price: int) - list: filtered [] for item in items: # 价格文本格式为 ¥300 或 ¥ 1,200 price_text item[price].replace(¥, ).replace(,, ) try: price int(price_text) if price max_price: filtered.append(item) except ValueError: # 价格字段解析失败时放行避免漏报 filtered.append(item) return filtered这里有一个反直觉的设计价格解析失败时选择放行而不是丢弃。因为你不知道解析失败是因为促销价变动还是页面改版如果直接丢弃可能漏掉真正重要的商品。宁可多收一条无关提醒也不能让扫描器在改版期静默失效。5.3 上线前的三分钟自检流程最后一个建议是给自己留一个可重复的验收路径。我每次修改扫描逻辑后都会强制跑一遍这个流程清空数据库把已扫过的商品记录删掉保证不靠历史数据兜底用一条比较冷门的关键词手动运行一轮确认邮件能收到、链接能打开再跑第二轮确认没有收到重复提醒也就是INSERT OR IGNORE生效了。这个过程总共不到三分钟但它能同时暴露 URL 拼接错误、xpath 失效和邮件配置问题。这个项目教会我的一件事是爬虫监控类的工具稳定性比功能丰富更重要。功能少一点可以忍一个晚上反复误报就没人敢用了。从那以后我每次改完扫描逻辑都会强制走一遍“清库试跑、确认提醒、再上定时任务”的流程确保改动在监控之前已经验证过。希望帮到你。本文还有配套的精品资源点击获取