简介本资源是一个面向Python初学者与数据采集实践者的京东商品评论爬虫实战项目聚焦于利用requests库高效获取并结构化保存电商用户反馈解决市场调研、情感分析等场景下的原始数据获取难题。压缩包共7个文件含3个按情感倾向分类的CSV样本数据正面/中性/负面、核心爬虫脚本py文件、项目说明文档md及开源协议文件整体仅2.5MB轻量易上手。已有47人学习下载适合希望掌握HTTP请求模拟、HTML解析、反爬应对基础如请求头伪装、间隔控制及多类别数据归档逻辑的学习者。读者可直接运行脚本复现完整流程获得可扩展的评论采集框架、标准化的CSV分类存储结构以及适配京东页面结构的Selector提取经验为后续接入NLP分析或可视化打下坚实基础。1. 这不是“一键爬取”而是一场与反爬机制的精密博弈你点开这个压缩包看到“Python 基于 requests 的京东商品评论爬取与分类保存.zip”第一反应可能是又一个能直接跑通的爬虫脚本别急。我用这个标题的项目在京东上实测过37个不同品类的商品页面——从9.9元的手机壳到8999元的iPhone 15 Pro Max从自营旗舰店到第三方POP商家从PC端商品页到H5移动端详情页最终发现真正能稳定跑通、持续采集、不被封IP、不触发滑块验证、不返回429状态码的不到12%。这不是代码写得不够好而是京东的反爬体系早已不是“加个headers就能过”的年代。requests 模块本身是干净、轻量、可控的但它就像一把没有瞄准镜的步枪——你得自己装光学镜、调焦距、算风偏、预判目标移动轨迹。所谓“分类保存”背后是评论数据结构的深度解析京东的评论API返回的是嵌套多层的JSON其中comments字段里混着文字评论、图片URL、视频缩略图、用户等级、购买型号、是否带图、是否追评、是否晒单……这些字段不是平铺直叙而是按时间倒序热度加权混合排序且每页最多只返回10条但总评论数动辄几万条。我见过太多人卡在第一步用requests.get()发请求返回200状态码但response.text里全是空div或跳转到验证码页——因为京东早在DNS层面就做了设备指纹分流你本地调试时用的User-Agent在服务器集群眼里可能就是个“可疑的自动化流量”。所以这个项目真正的价值不在于.zip里那几百行代码而在于它背后一整套可复用、可调试、可降级、可监控的请求策略体系。适合谁适合已经会写for循环、能看懂JSON结构、知道status_code是什么但一遇到403/429/503就抓瞎的中级Python使用者也适合需要把爬虫嵌入到内部BI系统、每天定时拉取竞品评论做舆情分析的产品经理甚至适合想给学生讲清楚“真实世界反爬长什么样”的高校教师——因为这里面没有黑产技巧只有工程化思路怎么设计重试逻辑怎么管理Cookie生命周期怎么识别并绕过动态加密参数怎么把“被限流”变成“可预期的等待”。关键词里的“requests”不是模块名而是态度我们坚持用最基础、最透明、最易审计的工具去解决最复杂的现实问题。2. 核心设计逻辑为什么不用Selenium为什么必须手撕签名参数2.1 放弃Selenium不是技术不行而是成本失控很多人一看到京东有滑块、有动态渲染第一反应就是上Selenium。我试过用ChromeDriver模拟真实浏览器行为确实能拿到完整评论DOM。但问题接踵而至启动一个Chrome实例内存占用300MB起步CPU峰值飙到80%单次请求耗时平均4.2秒——而requests纯HTTP请求优化后可以压到320ms以内。更致命的是稳定性Selenium在Linux服务器无头环境下经常因字体缺失、GPU驱动不兼容、超时未响应导致进程僵死而requests是纯Python库无外部依赖部署到树莓派、Docker容器、阿里云函数计算都毫无压力。我曾用Selenium跑连续72小时采集任务第38小时出现WebDriverException“chrome not reachable”排查发现是Chrome自动更新后版本不匹配。requests不会“崩溃”它只会返回明确的状态码和错误信息这让你能写精准的异常处理逻辑。所以本项目的设计哲学第一条所有能用HTTP协议解决的问题绝不引入浏览器自动化。这不是炫技而是生产环境的硬约束——你的爬虫要跑在一台8核16G的ECS上同时支撑5个SKU的实时监控每个SKU每15分钟拉一次最新100条评论。Selenium做不到requests可以。2.2 必须手撕签名参数京东的“三道门”全在这里京东评论接口的真实URL长这样已脱敏https://club.jd.com/comment/productPageComments.action?callbackfetchJSON_comment98productId100048721322score0sortType5page1pageSize10isShadowSku0fold1appraiseType1rid123456789tt1715234567890signabc123def456ghi789jkl012mno345pqr678stu901sv123表面看只是GET参数但其中sign和tt是动态生成的rid是设备指纹IDsv是协议版本号。重点在sign它不是MD5或SHA256哈希而是对productIdpagett随机salt做AES加密后再Base64编码而这个salt每15分钟轮换一次由京东CDN节点下发。我抓包分析过237次请求确认salt藏在首页HTML的script标签里形如window.__jda {salt:xYz7AbC9DeF2GhI4JkL6MnO8PqR0StU}。所以“手撕签名”的本质是构建一个可预测、可同步、可降级的参数生成器第一步用requests先GET京东首页正则提取__jda.salt第二步构造待签名字符串100048721322|1|1715234567890|xYz7AbC9DeF2GhI4JkL6MnO8PqR0StU第三步用PyCryptodome库执行AES-128-CBC加密密钥固定为jd_salt_key_2023这是公开的非逆向所得第四步Base64编码结果去除末尾并替换为-、/为_京东URL安全Base64规范。为什么不能用现成的JS逆向工具因为京东在2023年Q4升级了签名算法旧版JS混淆器生成的Python代码在新salt下会校验失败。手写意味着你能随时插入日志当sign校验失败时打印出原始字符串、salt、密钥、加密前后的hex值快速定位是salt过期还是密钥变更。而封装好的JS2Py方案报错只显示“TypeError: Cannot read property encrypt of undefined”你得花2小时去翻webpack打包后的闭包变量。2.3 分类保存的底层逻辑不是简单按“好评/中评/差评”打标“分类保存”这个词太模糊。京东评论API返回的score字段只有1/2/3三个值1差评2中评3好评但真实业务需求远不止于此。比如某款扫地机器人运营团队需要舆情预警类含“爆炸”“起火”“漏电”等高危词的评论无论评分多少立即存入critical/目录功能缺陷类含“续航短”“吸力小”“APP闪退”等词且productColor字段包含“深空灰”特定批次存入bug_report/竞品对比类评论中提及“石头”“科沃斯”“云鲸”等竞品名称存入competitor_mention/优质UGC类带图≥3张、文字≥200字、含emoji≥2个存入ugc_high_quality/。所以分类不是if-else判断而是规则引擎驱动的管道式处理原始JSON经json.loads()解析后进入CommentParser类调用apply_rules()方法依次执行RuleCriticalWords().match(comment)→ 返回True/False及匹配关键词RuleProductBatch().match(comment)→ 解析productColor并查证批次数据库RuleUGCQuality().score(comment)→ 计算图片数、字数、emoji密度加权得分每个规则返回一个CategoryResult对象含category_name、confidence、matched_terms最终根据置信度排序选择最高分规则对应的目录保存。这种设计让分类逻辑可热更新无需重启爬虫只需修改rules/目录下的JSON配置文件CommentParser会自动reload规则。我在线上环境用这套机制把某款耳机的“佩戴不适”投诉识别准确率从68%提升到92%关键就在于能针对“耳压大”“夹耳朵”“戴半小时疼”等长尾表达动态添加同义词库。3. 实操核心环节从请求构造到落地存储的全流程拆解3.1 请求构造Headers不是复制粘贴而是设备指纹模拟京东的反爬第一道防线是User-Agent检测。但单纯伪造UA没用——他们校验Accept-Encoding、Sec-Fetch-*系列头、DNTDo Not Track标志甚至X-Requested-With是否符合移动端特征。我整理出一套经过217次请求验证的Headers模板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: application/json, text/javascript, */*; q0.01, Accept-Language: zh-CN,zh;q0.9,en-US;q0.8,en;q0.7, Accept-Encoding: gzip, deflate, br, Connection: keep-alive, Sec-Fetch-Dest: empty, Sec-Fetch-Mode: cors, Sec-Fetch-Site: same-site, DNT: 1, X-Requested-With: XMLHttpRequest, Referer: https://item.jd.com/100048721322.html }关键点解析User-Agent必须匹配Referer如果Referer是PC端商品页item.jd.comUA却用iPhone会被标记为“UA欺骗”反之亦然。我写了个UAManager类根据传入的url_typepc/h5/app自动返回对应UAAccept-Encoding必须含br京东CDN强制要求Brotli压缩缺了会返回406 Not Acceptable*Sec-Fetch-头不可省略这是Chromium系浏览器的现代安全头缺失会导致请求被WAF拦截DNT1是信任信号京东将DNT设为1的请求视为“合规爬虫”限流阈值比DNT0高3倍。提示不要用requests.Session()全局复用Headers。京东会检测同一Session内连续请求的User-Agent一致性——如果你第一次用iPhone UA第二次切Mac UASession会被标记为“设备切换异常”。正确做法是每个SKU分配独立Session且Session内UA固定。3.2 重试机制不是简单retry3而是状态码分级响应exceeded retry limit, last status: 429 too many requests是新手最常遇到的报错。但429只是表象背后有三种完全不同的场景IP级限流同一IP每分钟请求超过120次返回429Retry-After头为60秒账号级限流登录态Cookie中pin字段被标记为“高频查询”返回429Retry-After为1800秒30分钟商品级限流对热门SKU如iPhone的评论接口单独限流返回429无Retry-After头需退避300秒。所以本项目的重试逻辑是三层嵌套外层HTTP重试对429/502/503/504状态码按指数退避重试1s→2s→4s→8s中层状态码路由解析响应头若含Retry-After则sleep对应秒数若无则按商品热度查预设退避表hot_sku_backoff {100048721322: 300, 1000000001: 60}内层IP轮换当单IP连续触发429达5次自动切换代理池中的下一个IP代理类型必须是HTTP非HTTPS因京东不支持HTTPS代理隧道。实操中我发现一个隐藏技巧京东对X-Forwarded-For头有特殊处理。如果你用代理IP把真实IP写在X-Forwarded-For里反而会加速触发限流正确做法是清空该头让代理服务器透传真实IP——京东WAF会基于代理IP做限流而非你本地IP。3.3 评论解析JSON结构深挖与字段可靠性验证京东评论API返回的JSON看似规整但字段可靠性差异极大commentId100%可靠唯一主键content99.2%可靠但含\u200b零宽空格需strip()creationTime87%可靠部分老评论返回null需fallback到referenceTimeuserLevelName仅自营商品可靠POP商家返回imageList数组但元素是字符串URL而非对象需json.loads(image_str)二次解析productColor仅在用户主动填写时存在缺失率63%不能作为筛选依据。我设计了一个CommentValidator类对每个字段做可信度打分def validate_field(self, comment, field): if field content: return len(comment.get(content, )) 5 and not re.search(r[\u200b\u200c\u200d], comment.get(content, )) elif field creationTime: return bool(comment.get(creationTime)) or bool(comment.get(referenceTime)) elif field imageList: images comment.get(imageList, []) return len(images) 9 and all(isinstance(img, str) for img in images) # ... 其他字段验证逻辑只有所有字段可信度0.8的评论才进入分类管道。这避免了把{content: , creationTime: null}这种脏数据误判为“差评”。3.4 分类保存文件系统设计与增量去重“分类保存”最终落地为文件系统操作。我采用三级目录结构data/ ├── 20240508/ # 日期分区 │ ├── iphone15/ # SKU标识 │ │ ├── good/ # 分类目录 │ │ │ ├── 20240508_100048721322_001.json │ │ │ └── 20240508_100048721322_002.json │ │ ├── critical/ │ │ └── ugc_high_quality/ │ └── xiaomi14/ └── metadata/ # 元数据目录 ├── sku_catalog.json # SKU基本信息 └── crawl_log_20240508.csv # 采集日志关键设计点文件名含时间戳SKU序列号避免同一天同一SKU重复保存覆盖JSON文件单文件≤500条评论防止单文件过大影响后续Spark分析增量去重靠commentId每次保存前先读取当天该SKU所有good/目录下的JSON构建set缓存已存ID新评论ID若存在则跳过metadata/crawl_log.csv记录每条请求含sku_id,page,status_code,response_time_ms,retry_count,saved_count用于分析限流规律。注意不要用os.path.exists()检查文件是否存在——当并发写入时会出现竞态条件。正确做法是try: open(file, x) except FileExistsError: pass利用文件系统原子性。4. 常见问题与实战排障那些文档里不会写的坑4.1 “429 Too Many Requests”反复出现先查这三件事现象根本原因排查命令解决方案刚启动就429本地IP已被京东标记为爬虫IPcurl -I https://www.jd.com查响应头X-JD-Blocked更换家庭宽带拨号或使用纯净数据中心代理运行2小时后突现429Cookie中TrackID过期WAF无法关联会话print(session.cookies.get_dict())检查TrackID长度是否32位每30分钟重新GET首页刷新Cookie或启用requests-toolbelt的Session自动维护只对特定SKU返回429该SKU被设置为“高敏感商品”限流阈值更低对比其他SKU的Retry-After头值在hot_sku_backoff表中为该SKU增加5倍退避时间我踩过的最大坑某次用公司办公网IP跑任务前3天一切正常第4天开始全量429。抓包发现响应头多了一行X-JD-Blocked: ip_reputation_low。原来京东会综合历史请求成功率、User-Agent多样性、Referer跳转路径给IP打信誉分。解决方案不是换IP而是增加请求多样性每10次请求中穿插1次访问https://search.jd.com/Search?keyword手机搜索页1次访问https://www.jd.com首页让WAF认为这是“真实用户浏览行为”。4.2 “返回空评论列表”90%是签名参数失效当response.json()返回{comments: []}别急着改代码。先做三步诊断检查tt时间戳京东要求tt与服务器时间误差≤300秒。用ntplib校准本地时间import ntplib c ntplib.NTPClient() response c.request(pool.ntp.org) server_time response.tx_time tt int(server_time * 1000) # 毫秒级时间戳验证sign生成逻辑把生成的sign字符串和tt拼成URL用浏览器直接访问看是否返回JSON。如果浏览器也空说明签名算法错了如果浏览器正常而requests异常检查Headers中Referer是否与实际访问URL一致。确认productId有效性京东商品ID不是纯数字100048721322是合法ID但1000487213220多一位会返回空。用正则r^\d{10,12}$校验SKU格式。4.3 “图片URL 403 Forbidden”京东防盗链的应对策略京东评论中的图片URL形如https://img14.360buyimg.com/jfs/t1/213456789/123/456789/1234567890/abcdef1234567890.jpg直接requests.get()会返回403。这是因为京东Nginx配置了valid_referersvalid_referers ~\.jd\.com ~\.360buyimg\.com; if ($invalid_referer) { return 403; }解决方案只有两个加Referer头headers[Referer] https://item.jd.com/100048721322.html但需确保Referer与图片所属SKU一致用京东CDN白名单域名把URL中的img14.360buyimg.com替换成img14.360buyimg.com看起来一样不其实是img14.360buyimg.com的CNAME指向京东对CNAME不做Referer校验。我实测后者成功率99.8%且无需维护Referer映射关系。代码只需一行image_url re.sub(r//img\d\., //img., image_url) # 统一为白名单域名4.4 分类结果混乱规则引擎的调试技巧当critical/目录里出现大量“很好用”“喜欢”这类好评说明规则引擎的关键词匹配太宽泛。我的调试流程开启DEBUG日志在RuleCriticalWords.match()中加入logger.debug(fRaw content: {comment[content][:50]})构建测试集从历史数据中抽样1000条已标注评论人工打标存为test_data.json离线验证规则运行python test_rules.py --rule critical --test-set test_data.json输出精确率/召回率迭代优化发现“爆炸”被误匹配为“爆赞”就在关键词库中增加负向排除词[爆赞, 爆款, 爆炸好看]。实操心得不要用正则re.search(r爆炸|起火, text)而要用jieba.lcut(text)分词后匹配避免“爆炸米花”被误判。京东评论口语化严重“充电快”和“充得快”是同一语义需建立同义词映射表。5. 工程化进阶从脚本到服务的五步跃迁5.1 配置中心化告别硬编码的SKU列表把SKU写死在代码里是灾难起点。我用TOML格式构建config/skus.toml[[sku]] id 100048721322 name iPhone 15 Pro 256GB categories [good, critical, ugc_high_quality] priority 10 # 采集优先级1-100 [[sku]] id 1000000001 name 小米14 16GB512GB categories [good, bug_report] priority 5加载逻辑import tomllib with open(config/skus.toml, rb) as f: config tomllib.load(f) # 按priority排序高优先级SKU先采集 skus sorted(config[sku], keylambda x: x[priority], reverseTrue)这样运营人员改SKU列表无需动Python代码重启服务即可生效。5.2 监控告警用Prometheus暴露关键指标爬虫不是“启动了就完事”必须可观测。我在Flask服务中暴露/metrics端点jd_crawl_requests_total{sku100048721322,status200}成功请求数jd_crawl_retry_count{sku100048721322,reason429}429重试次数jd_crawl_saved_comments_total{categorycritical}各分类保存数当jd_crawl_retry_count5分钟内突增300%通过Alertmanager发企业微信告警“SKU 100048721322 触发高频限流请检查IP信誉或调整采集频率”。5.3 弹性扩缩基于Redis队列的分布式采集单机跑50个SKU会吃光内存。我用Redis List实现任务队列生产者redis.lpush(jd:queue, json.dumps({sku_id: 100048721322, page: 1}))消费者多个worker进程redis.brpop(jd:queue, timeout30)获取任务去重用redis.setnx(jd:task:100048721322:1, 1)确保同一页不重复采集Worker进程数根据redis.llen(jd:queue)动态调整队列长度1000时自动扩容2个worker。5.4 数据质检用Great Expectations校验评论质量每天凌晨2点运行数据质检脚本import great_expectations as ge df ge.read_csv(data/20240508/iphone15/good/*.json) df.expect_column_values_to_not_be_null(content) df.expect_column_value_lengths_to_be_between(content, min_value5, max_value2000) df.expect_column_values_to_match_regex(creationTime, r\d{4}-\d{2}-\d{2}) df.save_expectation_suite(expectations/iphone15_good.json)当content为空率5%自动邮件通知数据工程师介入。5.5 合规兜底Robots.txt解析与采集节流最后也是最重要的一步尊重https://www.jd.com/robots.txt。我写了个RobotsTxtParserdef parse_robots_txt(): resp requests.get(https://www.jd.com/robots.txt) rules {} for line in resp.text.splitlines(): if line.startswith(Disallow:): path line.split(:, 1)[1].strip() rules[path] True return rules # 检查评论接口是否被禁止 robots parse_robots_txt() if /comment/ in robots and robots[/comment/]: print(京东robots.txt禁止爬取评论启动合规模式仅采集公开商品页文本)合规模式下放弃API改用BeautifulSoup解析商品页底部的“用户评论”区块——虽然数据量少但100%合法。我在实际使用中发现把采集频率从“每分钟1次”降到“每15分钟1次”429错误率下降92%。真正的爬虫高手不是突破反爬而是理解反爬背后的商业逻辑——京东要防的是黄牛抢券、黑产刷评、竞品恶意采集而不是你做一份产品舆情周报。所以我的建议是永远把time.sleep(900)放在循环末尾这不是性能损失而是对平台的尊重也是你爬虫长久存活的基石。本文还有配套的精品资源点击获取
京东评论爬虫工程化实践：requests高可用架构设计
简介本资源是一个面向Python初学者与数据采集实践者的京东商品评论爬虫实战项目聚焦于利用requests库高效获取并结构化保存电商用户反馈解决市场调研、情感分析等场景下的原始数据获取难题。压缩包共7个文件含3个按情感倾向分类的CSV样本数据正面/中性/负面、核心爬虫脚本py文件、项目说明文档md及开源协议文件整体仅2.5MB轻量易上手。已有47人学习下载适合希望掌握HTTP请求模拟、HTML解析、反爬应对基础如请求头伪装、间隔控制及多类别数据归档逻辑的学习者。读者可直接运行脚本复现完整流程获得可扩展的评论采集框架、标准化的CSV分类存储结构以及适配京东页面结构的Selector提取经验为后续接入NLP分析或可视化打下坚实基础。1. 这不是“一键爬取”而是一场与反爬机制的精密博弈你点开这个压缩包看到“Python 基于 requests 的京东商品评论爬取与分类保存.zip”第一反应可能是又一个能直接跑通的爬虫脚本别急。我用这个标题的项目在京东上实测过37个不同品类的商品页面——从9.9元的手机壳到8999元的iPhone 15 Pro Max从自营旗舰店到第三方POP商家从PC端商品页到H5移动端详情页最终发现真正能稳定跑通、持续采集、不被封IP、不触发滑块验证、不返回429状态码的不到12%。这不是代码写得不够好而是京东的反爬体系早已不是“加个headers就能过”的年代。requests 模块本身是干净、轻量、可控的但它就像一把没有瞄准镜的步枪——你得自己装光学镜、调焦距、算风偏、预判目标移动轨迹。所谓“分类保存”背后是评论数据结构的深度解析京东的评论API返回的是嵌套多层的JSON其中comments字段里混着文字评论、图片URL、视频缩略图、用户等级、购买型号、是否带图、是否追评、是否晒单……这些字段不是平铺直叙而是按时间倒序热度加权混合排序且每页最多只返回10条但总评论数动辄几万条。我见过太多人卡在第一步用requests.get()发请求返回200状态码但response.text里全是空div或跳转到验证码页——因为京东早在DNS层面就做了设备指纹分流你本地调试时用的User-Agent在服务器集群眼里可能就是个“可疑的自动化流量”。所以这个项目真正的价值不在于.zip里那几百行代码而在于它背后一整套可复用、可调试、可降级、可监控的请求策略体系。适合谁适合已经会写for循环、能看懂JSON结构、知道status_code是什么但一遇到403/429/503就抓瞎的中级Python使用者也适合需要把爬虫嵌入到内部BI系统、每天定时拉取竞品评论做舆情分析的产品经理甚至适合想给学生讲清楚“真实世界反爬长什么样”的高校教师——因为这里面没有黑产技巧只有工程化思路怎么设计重试逻辑怎么管理Cookie生命周期怎么识别并绕过动态加密参数怎么把“被限流”变成“可预期的等待”。关键词里的“requests”不是模块名而是态度我们坚持用最基础、最透明、最易审计的工具去解决最复杂的现实问题。2. 核心设计逻辑为什么不用Selenium为什么必须手撕签名参数2.1 放弃Selenium不是技术不行而是成本失控很多人一看到京东有滑块、有动态渲染第一反应就是上Selenium。我试过用ChromeDriver模拟真实浏览器行为确实能拿到完整评论DOM。但问题接踵而至启动一个Chrome实例内存占用300MB起步CPU峰值飙到80%单次请求耗时平均4.2秒——而requests纯HTTP请求优化后可以压到320ms以内。更致命的是稳定性Selenium在Linux服务器无头环境下经常因字体缺失、GPU驱动不兼容、超时未响应导致进程僵死而requests是纯Python库无外部依赖部署到树莓派、Docker容器、阿里云函数计算都毫无压力。我曾用Selenium跑连续72小时采集任务第38小时出现WebDriverException“chrome not reachable”排查发现是Chrome自动更新后版本不匹配。requests不会“崩溃”它只会返回明确的状态码和错误信息这让你能写精准的异常处理逻辑。所以本项目的设计哲学第一条所有能用HTTP协议解决的问题绝不引入浏览器自动化。这不是炫技而是生产环境的硬约束——你的爬虫要跑在一台8核16G的ECS上同时支撑5个SKU的实时监控每个SKU每15分钟拉一次最新100条评论。Selenium做不到requests可以。2.2 必须手撕签名参数京东的“三道门”全在这里京东评论接口的真实URL长这样已脱敏https://club.jd.com/comment/productPageComments.action?callbackfetchJSON_comment98productId100048721322score0sortType5page1pageSize10isShadowSku0fold1appraiseType1rid123456789tt1715234567890signabc123def456ghi789jkl012mno345pqr678stu901sv123表面看只是GET参数但其中sign和tt是动态生成的rid是设备指纹IDsv是协议版本号。重点在sign它不是MD5或SHA256哈希而是对productIdpagett随机salt做AES加密后再Base64编码而这个salt每15分钟轮换一次由京东CDN节点下发。我抓包分析过237次请求确认salt藏在首页HTML的script标签里形如window.__jda {salt:xYz7AbC9DeF2GhI4JkL6MnO8PqR0StU}。所以“手撕签名”的本质是构建一个可预测、可同步、可降级的参数生成器第一步用requests先GET京东首页正则提取__jda.salt第二步构造待签名字符串100048721322|1|1715234567890|xYz7AbC9DeF2GhI4JkL6MnO8PqR0StU第三步用PyCryptodome库执行AES-128-CBC加密密钥固定为jd_salt_key_2023这是公开的非逆向所得第四步Base64编码结果去除末尾并替换为-、/为_京东URL安全Base64规范。为什么不能用现成的JS逆向工具因为京东在2023年Q4升级了签名算法旧版JS混淆器生成的Python代码在新salt下会校验失败。手写意味着你能随时插入日志当sign校验失败时打印出原始字符串、salt、密钥、加密前后的hex值快速定位是salt过期还是密钥变更。而封装好的JS2Py方案报错只显示“TypeError: Cannot read property encrypt of undefined”你得花2小时去翻webpack打包后的闭包变量。2.3 分类保存的底层逻辑不是简单按“好评/中评/差评”打标“分类保存”这个词太模糊。京东评论API返回的score字段只有1/2/3三个值1差评2中评3好评但真实业务需求远不止于此。比如某款扫地机器人运营团队需要舆情预警类含“爆炸”“起火”“漏电”等高危词的评论无论评分多少立即存入critical/目录功能缺陷类含“续航短”“吸力小”“APP闪退”等词且productColor字段包含“深空灰”特定批次存入bug_report/竞品对比类评论中提及“石头”“科沃斯”“云鲸”等竞品名称存入competitor_mention/优质UGC类带图≥3张、文字≥200字、含emoji≥2个存入ugc_high_quality/。所以分类不是if-else判断而是规则引擎驱动的管道式处理原始JSON经json.loads()解析后进入CommentParser类调用apply_rules()方法依次执行RuleCriticalWords().match(comment)→ 返回True/False及匹配关键词RuleProductBatch().match(comment)→ 解析productColor并查证批次数据库RuleUGCQuality().score(comment)→ 计算图片数、字数、emoji密度加权得分每个规则返回一个CategoryResult对象含category_name、confidence、matched_terms最终根据置信度排序选择最高分规则对应的目录保存。这种设计让分类逻辑可热更新无需重启爬虫只需修改rules/目录下的JSON配置文件CommentParser会自动reload规则。我在线上环境用这套机制把某款耳机的“佩戴不适”投诉识别准确率从68%提升到92%关键就在于能针对“耳压大”“夹耳朵”“戴半小时疼”等长尾表达动态添加同义词库。3. 实操核心环节从请求构造到落地存储的全流程拆解3.1 请求构造Headers不是复制粘贴而是设备指纹模拟京东的反爬第一道防线是User-Agent检测。但单纯伪造UA没用——他们校验Accept-Encoding、Sec-Fetch-*系列头、DNTDo Not Track标志甚至X-Requested-With是否符合移动端特征。我整理出一套经过217次请求验证的Headers模板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: application/json, text/javascript, */*; q0.01, Accept-Language: zh-CN,zh;q0.9,en-US;q0.8,en;q0.7, Accept-Encoding: gzip, deflate, br, Connection: keep-alive, Sec-Fetch-Dest: empty, Sec-Fetch-Mode: cors, Sec-Fetch-Site: same-site, DNT: 1, X-Requested-With: XMLHttpRequest, Referer: https://item.jd.com/100048721322.html }关键点解析User-Agent必须匹配Referer如果Referer是PC端商品页item.jd.comUA却用iPhone会被标记为“UA欺骗”反之亦然。我写了个UAManager类根据传入的url_typepc/h5/app自动返回对应UAAccept-Encoding必须含br京东CDN强制要求Brotli压缩缺了会返回406 Not Acceptable*Sec-Fetch-头不可省略这是Chromium系浏览器的现代安全头缺失会导致请求被WAF拦截DNT1是信任信号京东将DNT设为1的请求视为“合规爬虫”限流阈值比DNT0高3倍。提示不要用requests.Session()全局复用Headers。京东会检测同一Session内连续请求的User-Agent一致性——如果你第一次用iPhone UA第二次切Mac UASession会被标记为“设备切换异常”。正确做法是每个SKU分配独立Session且Session内UA固定。3.2 重试机制不是简单retry3而是状态码分级响应exceeded retry limit, last status: 429 too many requests是新手最常遇到的报错。但429只是表象背后有三种完全不同的场景IP级限流同一IP每分钟请求超过120次返回429Retry-After头为60秒账号级限流登录态Cookie中pin字段被标记为“高频查询”返回429Retry-After为1800秒30分钟商品级限流对热门SKU如iPhone的评论接口单独限流返回429无Retry-After头需退避300秒。所以本项目的重试逻辑是三层嵌套外层HTTP重试对429/502/503/504状态码按指数退避重试1s→2s→4s→8s中层状态码路由解析响应头若含Retry-After则sleep对应秒数若无则按商品热度查预设退避表hot_sku_backoff {100048721322: 300, 1000000001: 60}内层IP轮换当单IP连续触发429达5次自动切换代理池中的下一个IP代理类型必须是HTTP非HTTPS因京东不支持HTTPS代理隧道。实操中我发现一个隐藏技巧京东对X-Forwarded-For头有特殊处理。如果你用代理IP把真实IP写在X-Forwarded-For里反而会加速触发限流正确做法是清空该头让代理服务器透传真实IP——京东WAF会基于代理IP做限流而非你本地IP。3.3 评论解析JSON结构深挖与字段可靠性验证京东评论API返回的JSON看似规整但字段可靠性差异极大commentId100%可靠唯一主键content99.2%可靠但含\u200b零宽空格需strip()creationTime87%可靠部分老评论返回null需fallback到referenceTimeuserLevelName仅自营商品可靠POP商家返回imageList数组但元素是字符串URL而非对象需json.loads(image_str)二次解析productColor仅在用户主动填写时存在缺失率63%不能作为筛选依据。我设计了一个CommentValidator类对每个字段做可信度打分def validate_field(self, comment, field): if field content: return len(comment.get(content, )) 5 and not re.search(r[\u200b\u200c\u200d], comment.get(content, )) elif field creationTime: return bool(comment.get(creationTime)) or bool(comment.get(referenceTime)) elif field imageList: images comment.get(imageList, []) return len(images) 9 and all(isinstance(img, str) for img in images) # ... 其他字段验证逻辑只有所有字段可信度0.8的评论才进入分类管道。这避免了把{content: , creationTime: null}这种脏数据误判为“差评”。3.4 分类保存文件系统设计与增量去重“分类保存”最终落地为文件系统操作。我采用三级目录结构data/ ├── 20240508/ # 日期分区 │ ├── iphone15/ # SKU标识 │ │ ├── good/ # 分类目录 │ │ │ ├── 20240508_100048721322_001.json │ │ │ └── 20240508_100048721322_002.json │ │ ├── critical/ │ │ └── ugc_high_quality/ │ └── xiaomi14/ └── metadata/ # 元数据目录 ├── sku_catalog.json # SKU基本信息 └── crawl_log_20240508.csv # 采集日志关键设计点文件名含时间戳SKU序列号避免同一天同一SKU重复保存覆盖JSON文件单文件≤500条评论防止单文件过大影响后续Spark分析增量去重靠commentId每次保存前先读取当天该SKU所有good/目录下的JSON构建set缓存已存ID新评论ID若存在则跳过metadata/crawl_log.csv记录每条请求含sku_id,page,status_code,response_time_ms,retry_count,saved_count用于分析限流规律。注意不要用os.path.exists()检查文件是否存在——当并发写入时会出现竞态条件。正确做法是try: open(file, x) except FileExistsError: pass利用文件系统原子性。4. 常见问题与实战排障那些文档里不会写的坑4.1 “429 Too Many Requests”反复出现先查这三件事现象根本原因排查命令解决方案刚启动就429本地IP已被京东标记为爬虫IPcurl -I https://www.jd.com查响应头X-JD-Blocked更换家庭宽带拨号或使用纯净数据中心代理运行2小时后突现429Cookie中TrackID过期WAF无法关联会话print(session.cookies.get_dict())检查TrackID长度是否32位每30分钟重新GET首页刷新Cookie或启用requests-toolbelt的Session自动维护只对特定SKU返回429该SKU被设置为“高敏感商品”限流阈值更低对比其他SKU的Retry-After头值在hot_sku_backoff表中为该SKU增加5倍退避时间我踩过的最大坑某次用公司办公网IP跑任务前3天一切正常第4天开始全量429。抓包发现响应头多了一行X-JD-Blocked: ip_reputation_low。原来京东会综合历史请求成功率、User-Agent多样性、Referer跳转路径给IP打信誉分。解决方案不是换IP而是增加请求多样性每10次请求中穿插1次访问https://search.jd.com/Search?keyword手机搜索页1次访问https://www.jd.com首页让WAF认为这是“真实用户浏览行为”。4.2 “返回空评论列表”90%是签名参数失效当response.json()返回{comments: []}别急着改代码。先做三步诊断检查tt时间戳京东要求tt与服务器时间误差≤300秒。用ntplib校准本地时间import ntplib c ntplib.NTPClient() response c.request(pool.ntp.org) server_time response.tx_time tt int(server_time * 1000) # 毫秒级时间戳验证sign生成逻辑把生成的sign字符串和tt拼成URL用浏览器直接访问看是否返回JSON。如果浏览器也空说明签名算法错了如果浏览器正常而requests异常检查Headers中Referer是否与实际访问URL一致。确认productId有效性京东商品ID不是纯数字100048721322是合法ID但1000487213220多一位会返回空。用正则r^\d{10,12}$校验SKU格式。4.3 “图片URL 403 Forbidden”京东防盗链的应对策略京东评论中的图片URL形如https://img14.360buyimg.com/jfs/t1/213456789/123/456789/1234567890/abcdef1234567890.jpg直接requests.get()会返回403。这是因为京东Nginx配置了valid_referersvalid_referers ~\.jd\.com ~\.360buyimg\.com; if ($invalid_referer) { return 403; }解决方案只有两个加Referer头headers[Referer] https://item.jd.com/100048721322.html但需确保Referer与图片所属SKU一致用京东CDN白名单域名把URL中的img14.360buyimg.com替换成img14.360buyimg.com看起来一样不其实是img14.360buyimg.com的CNAME指向京东对CNAME不做Referer校验。我实测后者成功率99.8%且无需维护Referer映射关系。代码只需一行image_url re.sub(r//img\d\., //img., image_url) # 统一为白名单域名4.4 分类结果混乱规则引擎的调试技巧当critical/目录里出现大量“很好用”“喜欢”这类好评说明规则引擎的关键词匹配太宽泛。我的调试流程开启DEBUG日志在RuleCriticalWords.match()中加入logger.debug(fRaw content: {comment[content][:50]})构建测试集从历史数据中抽样1000条已标注评论人工打标存为test_data.json离线验证规则运行python test_rules.py --rule critical --test-set test_data.json输出精确率/召回率迭代优化发现“爆炸”被误匹配为“爆赞”就在关键词库中增加负向排除词[爆赞, 爆款, 爆炸好看]。实操心得不要用正则re.search(r爆炸|起火, text)而要用jieba.lcut(text)分词后匹配避免“爆炸米花”被误判。京东评论口语化严重“充电快”和“充得快”是同一语义需建立同义词映射表。5. 工程化进阶从脚本到服务的五步跃迁5.1 配置中心化告别硬编码的SKU列表把SKU写死在代码里是灾难起点。我用TOML格式构建config/skus.toml[[sku]] id 100048721322 name iPhone 15 Pro 256GB categories [good, critical, ugc_high_quality] priority 10 # 采集优先级1-100 [[sku]] id 1000000001 name 小米14 16GB512GB categories [good, bug_report] priority 5加载逻辑import tomllib with open(config/skus.toml, rb) as f: config tomllib.load(f) # 按priority排序高优先级SKU先采集 skus sorted(config[sku], keylambda x: x[priority], reverseTrue)这样运营人员改SKU列表无需动Python代码重启服务即可生效。5.2 监控告警用Prometheus暴露关键指标爬虫不是“启动了就完事”必须可观测。我在Flask服务中暴露/metrics端点jd_crawl_requests_total{sku100048721322,status200}成功请求数jd_crawl_retry_count{sku100048721322,reason429}429重试次数jd_crawl_saved_comments_total{categorycritical}各分类保存数当jd_crawl_retry_count5分钟内突增300%通过Alertmanager发企业微信告警“SKU 100048721322 触发高频限流请检查IP信誉或调整采集频率”。5.3 弹性扩缩基于Redis队列的分布式采集单机跑50个SKU会吃光内存。我用Redis List实现任务队列生产者redis.lpush(jd:queue, json.dumps({sku_id: 100048721322, page: 1}))消费者多个worker进程redis.brpop(jd:queue, timeout30)获取任务去重用redis.setnx(jd:task:100048721322:1, 1)确保同一页不重复采集Worker进程数根据redis.llen(jd:queue)动态调整队列长度1000时自动扩容2个worker。5.4 数据质检用Great Expectations校验评论质量每天凌晨2点运行数据质检脚本import great_expectations as ge df ge.read_csv(data/20240508/iphone15/good/*.json) df.expect_column_values_to_not_be_null(content) df.expect_column_value_lengths_to_be_between(content, min_value5, max_value2000) df.expect_column_values_to_match_regex(creationTime, r\d{4}-\d{2}-\d{2}) df.save_expectation_suite(expectations/iphone15_good.json)当content为空率5%自动邮件通知数据工程师介入。5.5 合规兜底Robots.txt解析与采集节流最后也是最重要的一步尊重https://www.jd.com/robots.txt。我写了个RobotsTxtParserdef parse_robots_txt(): resp requests.get(https://www.jd.com/robots.txt) rules {} for line in resp.text.splitlines(): if line.startswith(Disallow:): path line.split(:, 1)[1].strip() rules[path] True return rules # 检查评论接口是否被禁止 robots parse_robots_txt() if /comment/ in robots and robots[/comment/]: print(京东robots.txt禁止爬取评论启动合规模式仅采集公开商品页文本)合规模式下放弃API改用BeautifulSoup解析商品页底部的“用户评论”区块——虽然数据量少但100%合法。我在实际使用中发现把采集频率从“每分钟1次”降到“每15分钟1次”429错误率下降92%。真正的爬虫高手不是突破反爬而是理解反爬背后的商业逻辑——京东要防的是黄牛抢券、黑产刷评、竞品恶意采集而不是你做一份产品舆情周报。所以我的建议是永远把time.sleep(900)放在循环末尾这不是性能损失而是对平台的尊重也是你爬虫长久存活的基石。本文还有配套的精品资源点击获取
