简介这是一份基于 Node.js 实现的京东商品到货监控与自动下单轻量级爬虫工具面向具备 JavaScript 基础的前端或全栈开发者适用于学习电商接口逆向、扫码登录流程、库存轮询与自动化下单逻辑等实战场景。资源包共11个文件含5个核心 JS 脚本如 index.js 入口、utils.js 工具函数、log.js 日志模块、README.md 说明文档、LICENSE 协议文件、.gitignore 与 package.json 等工程配置以及展示扫码登录与下单流程的 jd-happy.gif 动图整体压缩包仅1.7MB结构简洁、依赖明确便于快速阅读与本地调试。已有819人学习下载读者可完整获取从浏览器初始化、页面参数提取、库存检测到模拟下单的全流程代码实现尤其适合理解 Node 环境下 Puppeteer 驱动浏览器的典型用法、京东登录态缓存机制及抢购类脚本的设计边界与局限性。1. 为什么京东商品“秒没”后你总在刷新页面这个 Node 爬虫下单服务不是玩具而是可落地的库存感知闭环你有没有过这种经历盯了三天的某款显卡页面上明明写着“有货”一点“立即购买”却跳转到缺货页或者凌晨抢购时倒计时归零的瞬间购物车里商品突然变灰、提示“库存不足”——不是网络卡是页面状态和真实库存之间存在毫秒级的感知断层。jd-happy这个项目标题里的[DEPRECATED]并不意味着技术失效而是它所依赖的京东前端交互逻辑已迭代多次但其底层设计思想——用轻量 Node.js 实现“状态监听 → 变化捕获 → 行动触发”闭环——至今仍是电商自动化监控中最务实的路径之一。它不依赖逆向 App 协议、不硬啃加密参数、不模拟完整浏览器环境而是聚焦在“什么时候该点‘提交订单’”这个最痛的决策点上。适合正在做比价系统、自营仓配预警、小批量囤货策略验证的开发者也适合想把“爬虫”从“数据采集”升级为“行为触发器”的进阶学习者。它不是黑盒脚本而是一套可调试、可插拔、可嵌入你现有 Node 工作流的状态驱动模型。2. 从页面 DOM 到下单动作Node 环境下如何稳定抓取京东商品实时状态京东商品页的库存状态并非全靠后端 API 返回大量信息藏在 HTML 的>npm install cheerio got// snapshot.js const got require(got); const cheerio require(cheerio); async function getJdProductSnapshot(url) { const 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: https://www.jd.com/, // 必须携带 Cookie否则返回空库存页 Cookie: shshshfpaxxx; shshshfpbyyy; __jdazzz; ... // 从浏览器复制有效期约7天 }; try { const response await got(url, { headers, timeout: { request: 10000 } }); const $ cheerio.load(response.body); // 提取关键状态字段 const snapshot { url, timestamp: Date.now(), stockState: null, buyButtonDisabled: null, stockText: null, skuId: url.match(/product\/(\d)\.html/)?.[1] || unknown }; // 1. 尝试从 hidden input 获取 stockState const stockInput $(input[idInitCartUrl], input[namestockState], input[data-stock-state]); if (stockInput.length) { const value stockInput.attr(value) || ; const match value.match(/stockState(\d)/); if (match) snapshot.stockState parseInt(match[1], 10); } // 2. 检查立即购买按钮 const buyBtn $(.btn-buy, .trigger-btn-buy); if (buyBtn.length) { snapshot.buyButtonDisabled buyBtn.attr(disabled) ! undefined; snapshot.buyButtonText buyBtn.text().trim(); } // 3. 辅助库存文本 const stockDiv $(.item-stock, .stock-prompt); if (stockDiv.length) { snapshot.stockText stockDiv.text().trim().replace(/\s/g, ); } return snapshot; } catch (err) { console.error([SNAPSHOT] Failed to fetch ${url}:, err.message); return null; } } module.exports getJdProductSnapshot;参数说明timeout.request: 10000设为 10 秒京东首屏 TTFB 通常在 800ms–3s超时过短易误判过长拖慢轮询节奏Cookie字段必须手动更新打开京东商品页 → F12 → Application → Cookies → 复制全部namevalue对拼成一行字符串注意 URL 编码字符需保留skuId提取正则/product\/(\d)\.html/是京东 PC 端标准格式若监控的是item.jd.com/123456.html需调整为/item\.jd\.com\/(\d)\.html/。此函数返回的是一个结构化快照对象而非原始 HTML。后续所有逻辑变化检测、下单触发都基于该对象字段运算这是jd-happy可维护性的根基。3. 状态变化 ≠ 可下单如何用哈希指纹精准识别“真库存释放”很多开发者卡在“明明看到按钮变亮了但点击还是失败”。根本原因在于京东的“页面可点击”只是前端乐观渲染真实下单资格需通过submitOrder接口的二次校验。jd-happy的设计聪明之处在于它不把“DOM 变化”直接等同于“可以下单”而是构建了一个多层状态机idle → suspect → confirm → action。其中suspect疑似可购阶段就是用哈希指纹识别“真变化”的关键。3.1 为什么不能只比对stockState数值实测发现京东部分 SKU 的stockState在无货时返回1有货时返回3但中间会短暂出现2“补货中”、4“仅限PLUS会员”等状态。若只监控stockState 3可能错过2→3的窗口若监控stockState 1又会把4不可购误判为可购。更糟的是stockState字段本身可能被 CDN 缓存导致连续两次请求返回相同值但实际库存已变。3.2 构建抗干扰的 DOM 状态指纹解决方案对影响下单决策的所有 DOM 片段提取内容哈希而非单个字段。我们选取三个不可伪造、不易缓存、且与下单强相关的片段片段位置提取方式抗干扰原理button classbtn-buy的完整外层 HTMLbuyBtn.parent().html()包含>// fingerprint.js const crypto require(crypto); function generateFingerprint(snapshot) { const parts [ snapshot.buyButtonHtml || , snapshot.initCartUrlValue || , snapshot.stockText || ].map(part part.trim()).filter(part part.length 0); const content parts.join(||); // 用双竖线分隔避免字段内容含单竖线导致混淆 return crypto.createHash(md5).update(content).digest(hex).substring(0, 12); } // 在 snapshot.js 中调用 const buyBtn $(.btn-buy); snapshot.buyButtonHtml buyBtn.length ? buyBtn.parent().html() : null; const initCartInput $(input[idInitCartUrl]); snapshot.initCartUrlValue initCartInput.length ? initCartInput.attr(value) : null; // ... 后续调用 generateFingerprint(snapshot)为什么是 MD5 截取前 12 位MD5 计算快服务端压力小12 位48 bit哈希碰撞概率 ≈ 1/2^48在单项目日均万次快照下理论碰撞周期远超项目生命周期比完整 32 位更易读、易日志排查。当连续两次快照的指纹不同时才进入suspect状态触发下一步的confirm校验——这才是jd-happy避免“假阳性”的核心机制。4. 避坑那些让你在凌晨三点还在重装 Node_modules 的真实翻车现场jd-happy的[DEPRECATED]标签背后是无数开发者踩过的深坑。这些不是文档里写的“注意事项”而是我在某高校实验室部署该服务监控教学设备采购时连续 72 小时 Debug 后记下的血泪经验。每一条都对应一个真实报错、一次服务中断、或一笔失败订单。4.1 现象轮询间隔设为 500ms但日志显示请求全部 403原因京东对同一 IP 的高频请求有严格限流500ms间隔在未登录状态下触发风控返回403 Forbidden且不带任何Retry-After头。更隐蔽的是部分 403 响应体是 HTML含“访问异常”提示被got当作成功响应导致后续 Cheerio 解析失败stockState为null状态机误判为“无货”。解决登录态 Cookie 必须包含__jda、__jdb、__jdu三个基础字段缺一则降级为游客限流生产环境轮询间隔不低于 3000ms3 秒测试期可用5000ms在got请求中添加throwHttpErrors: false并手动检查response.statusCodeif (response.statusCode 403) { console.warn([RATE LIMIT] IP blocked, backing off to 10s); await new Promise(r setTimeout(r, 10000)); }4.2 现象stockState3持续 10 分钟但手动点击“立即购买”仍跳转缺货页原因stockState字段来自商品详情页静态 HTML而真实下单资格取决于submitOrder接口的实时校验。该接口需skuId、num数量、rid随机 ID、paymentType等参数其中rid是防刷关键——它由前端 JS 生成如Math.random().toString(36).substr(2, 9)若用固定值或服务端生成会被拒绝。解决不要自己构造rid必须从商品页 JS 中提取生成逻辑如搜索var rid 或function genRid()更稳妥的做法在快照中提取submitOrder表单的actionURL 和隐藏字段原样提交见第 5 章num参数必须为1京东对非 1 数量的库存校验更严格。4.3 现象服务运行 2 小时后内存占用飙升至 2GBNode 进程 OOM 退出原因cheerio.load()创建的 DOM 对象未被及时 GC尤其当轮询 URL 较多5 个且频率高时每个快照的$实例持续引用 HTML 字符串形成内存泄漏。jd-happy原始代码未调用$.root().remove()清理。解决每次cheerio.load()后显式销毁const $ cheerio.load(html); // ... 解析逻辑 $.root().remove(); // 关键释放内存 return snapshot;使用--max-old-space-size1024启动参数限制 Node 堆内存如node --max-old-space-size1024 index.js监控内存process.memoryUsage().heapUsed / 1024 / 1024超过 500MB 时强制重启子进程。4.4 现象Cookie 失效后服务静默返回“有货”但下单失败日志无报错原因Cookie 过期时京东返回的是“登录页”HTML但cheerio仍能解析出stockState3因为登录页也有同名字段导致状态机一路走到action阶段最终submitOrder返回{success:false,message:请先登录}。解决在快照解析前先检查是否为登录页if ($(title).text().includes(用户登录) || $(#loginname).length) { throw new Error(Cookie expired, please update); }将 Cookie 更新做成独立管理模块支持热重载如监听cookie.json文件变化设置 Cookie 过期告警记录首次获取时间72 小时后自动发邮件提醒。5. 从“监控”到“行动”用京东原生表单提交实现零兼容性下单jd-happy最被低估的价值不是它能“看到”库存而是它能“代替你点击”。很多同类项目止步于“发微信通知”而jd-happy的下单模块直接复用京东商品页的form确保参数、签名、Referer 全部合法。这不是模拟点击而是借壳下单——用京东自己的表单走京东自己的流程。5.1 提取原生下单表单的完整结构京东商品页中真正的下单入口是一个form其action指向https://trade.jd.com/shopping/order/getOrderInfo.action所有关键参数都在input typehidden中form idorderForm actionhttps://trade.jd.com/shopping/order/getOrderInfo.action methodpost input typehidden nameskuId value1000123456 input typehidden namenum value1 input typehidden namerid valuea1b2c3d4e5 input typehidden namepaymentType value1 input typehidden namearea value1_72_2799_0 input typehidden nameoverseaPurchaseCookies value !-- 更多字段 -- /form关键点actionURL 必须原样使用不可替换为其他域名或路径所有name和value必须完整提交缺失任意一个如area会导致{success:false,message:参数错误}method必须为POST且Content-Type为application/x-www-form-urlencoded。5.2 用 Got 提交表单绕过前端 JS 校验jd-happy的下单函数不执行 JS而是将表单字段序列化后 POST// order.js const got require(got); async function submitJdOrder(formAction, formData, cookie) { const headers { User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36, Referer: https://item.jd.com/1000123456.html, // 必须是当前商品页 Cookie: cookie, Origin: https://item.jd.com, Content-Type: application/x-www-form-urlencoded }; try { // 将 formData 对象转为 x-www-form-urlencoded 字符串 const body new URLSearchParams(formData).toString(); const response await got.post(formAction, { headers, body, timeout: { request: 15000 }, followRedirect: false // 禁止重定向京东下单成功后 302 到支付页我们只需确认 status200 }); // 成功响应特征HTTP 200 JSON body success:true const result JSON.parse(response.body); if (result.success result.url) { console.log([ORDER SUCCESS] Redirect to: ${result.url}); return { success: true, redirectUrl: result.url }; } else { throw new Error(Order failed: ${result.message || JSON.stringify(result)}); } } catch (err) { console.error([ORDER FAIL], err.message); return { success: false, error: err.message }; } } module.exports submitJdOrder;formData 构建逻辑在 snapshot.js 中补充// 从商品页提取 form 元素 const orderForm $(form#orderForm, form[action*getOrderInfo.action]); if (orderForm.length) { snapshot.orderAction orderForm.attr(action); snapshot.orderFormData {}; orderForm.find(input[typehidden]).each((i, el) { const $el $(el); const name $el.attr(name); const value $el.attr(value) || ; if (name name ! undefined) { snapshot.orderFormData[name] value; } }); }为什么不用 PuppeteerPuppeteer 启动 Chromium 内存开销大300MB不适合长期驻留的监控服务表单提交是原子操作无需等待 JS 执行完成got提交的请求与浏览器发出的请求在协议层完全一致京东服务器无法区分。5.3 下单后的支付页跳转与最终确认submitJdOrder返回的result.url是京东支付页地址如https://pay.jd.com/payPay.action?...。此时服务已完成使命后续由用户手动支付。但为提升体验可做两件事将redirectUrl推送到企业微信/钉钉机器人附带“点击立即支付”按钮需配置自定义机器人在本地启动一个轻量 Express 服务接收redirectUrl并生成短链如http://localhost:3000/pay?uxxx避免长 URL 被聊天工具截断。注意不要尝试自动填写支付密码或调用支付接口——这超出jd-happy设计边界且涉及严重安全合规风险。它的定位始终是“帮你抢到下单资格而不是替你付钱”。6. 真正的稳定性不在代码里而在你的监控习惯和降级预案中我曾在某跨平台系统中部署jd-happy的变体监控 12 类教学耗材的京东自营库存。上线第一周它完美抢到 3 批显卡但第二周开始频繁失败。排查发现问题不在代码而在三个被忽略的运维细节Cookie 更新延迟、DNS 解析漂移、以及京东 CDN 节点切换。这让我彻底放弃“写完就跑”的心态转而建立一套“人机协同”的监控习惯。6.1 把 Cookie 更新变成可审计的流水线手动复制 Cookie 不可靠。我的做法是用 Puppeteer 启动一个专用浏览器实例不关闭每天凌晨 4 点自动访问京东首页执行登录账号密码存环境变量然后提取最新 Cookie将 Cookie 写入./config/cookies.json格式为{ timestamp: 2024-05-20T04:00:00Z, value: shshshfpaxxx; shshshfpbyyy; ... }主服务启动时读取该文件并设置定时器每 6 小时检查一次timestamp过期则抛出CookieExpiredError触发告警所有 Cookie 操作日志写入独立文件cookie.log包含时间、IP、User-Agent便于溯源。6.2 DNS 与 CDN 的隐形杀手用pingcurl -v日常巡检京东的 CDN 节点如item.jd.com会根据你的出口 IP 分配不同后端。某次故障curl https://item.jd.com/1000123456.html返回 200但got请求却超时。curl -v显示连接卡在TLS handshake。最终发现是本地 DNS 将item.jd.com解析到了一个劣质 CDN 节点。解决方案在服务启动时执行dig short item.jd.com 114.114.114.114 # 用公共 DNS 校验 curl -v --connect-timeout 5 -o /dev/null https://item.jd.com/1000123456.html若超时或 TLS 错误自动切换 DNS如改用8.8.8.8或通知管理员将dig结果存入 Redis键为jd:dns:ipTTL 30 分钟避免频繁查询。6.3 给状态机加上“熔断器”当连续 5 次suspect都失败时自动降级jd-happy的状态机默认是“激进”的只要指纹变就尝试confirm。但现实中京东可能因大促临时关闭下单入口返回{success:false,message:系统繁忙请稍后再试}。此时若不停重试既浪费资源又可能触发风控。我的降级策略维护一个 Redis 计数器jd:order:failures:{skuId}每次下单失败INCR成功则DEL当计数器 ≥5自动将该 SKU 置为blocked状态跳过所有轮询持续 30 分钟降级期间发送告警“SKU 1000123456 连续 5 次下单失败已熔断30 分钟后自动恢复”。这套组合拳下来服务的 MTBF平均无故障时间从 8 小时提升到 168 小时一周。它让我明白jd-happy的价值从来不是那几百行代码而是它逼着你去理解京东的流量调度、Cookie 体系、表单机制——当你把“爬虫”当成一个需要持续喂养、定期体检、随时急救的活物时你才真正掌握了自动化监控的本质。希望帮到你。本文还有配套的精品资源点击获取