1. 番茄小说榜单爬虫失效从页面路由变更到 API 参数映射的排查复盘番茄小说榜单爬虫失效通常表现为原本能正常抓取的榜单接口突然返回空数据、字段错位或者直接 403/404。这类问题在小说站点里特别常见因为它们的页面路由和 API 参数经常随版本迭代调整。我这次遇到的场景是一个跑了三个月的番茄小说榜单采集脚本某天开始rank_list字段全部为空但 HTTP 状态码还是 200。排查下来根因是页面路由从/rank/改成了/rank-list/同时 API 的category_id参数映射表也变了。这篇文章会把整个排查过程拆成可复制的步骤顺带复盘一下我在德州扑克项目里配置「项目记忆」后开发效率提升 40% 的经验两者在“定位变更点”这件事上思路是相通的。先说清楚这篇适合谁如果你正在维护小说榜单、电商榜单、内容聚合类的爬虫或者你用的是 AI 编码助手写采集逻辑但总在字段映射上翻车那这篇的排查清单和参数映射表可以直接拿去用。核心检索词就三个番茄小说榜单爬虫、API 参数映射、项目记忆配置。我不会讲注册流程直接进入排查和修复。番茄小说榜单爬虫失效的典型症状分三档。第一档是“静默失败”请求返回 200但 JSON 里data.list是空数组或者book_name全是 null。第二档是“路由漂移”原来请求的/api/rank/v1/list返回 404但站点首页还能正常打开。第三档是“参数错位”接口通了但category_id1原本对应“玄幻”现在返回的是“都市”导致数据串类。我这次遇到的是第一档和第三档叠加排查时如果只看状态码会完全懵掉。排查的第一步不是改代码而是先确认页面路由是否变更。打开番茄小说的榜单页用浏览器开发者工具的 Network 面板筛选rank关键字看实际发出的 XHR 请求 URL。我实测下来路由变更往往伴随路径层级调整比如从/rank/变成/rank-list/或者 API 版本号从v1升到v2。这一步的关键是不要相信你代码里写死的 URL要以浏览器实际请求为准。你可以把 Network 面板里的请求 URL 复制出来和脚本里的base_url做逐段对比差异点就是路由变更点。路由确认后第二步是抓取真实的 API 响应做参数映射对照。番茄小说的榜单 API 通常带category_id、rank_type、page、page_size这几个参数。我这次的问题是category_id的映射表变了原来1玄幻、2都市、3仙侠现在变成了1都市、2玄幻、3仙侠。这种错位不会报错但数据全乱。解决办法是写一个探测脚本遍历category_id从 1 到 20把返回的category_name字段打印出来重新生成映射表。下面这段 Python 代码可以直接复制运行注意把base_url换成你实际抓到的路由。import requests import json # 替换成 Network 面板里实际抓到的路由 base_url https://api.example.com/rank-list/v2/list headers { User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36, Accept: application/json, Referer: https://www.example.com/rank-list/ } category_map {} for cid in range(1, 21): params { category_id: cid, rank_type: hot, page: 1, page_size: 10 } try: resp requests.get(base_url, headersheaders, paramsparams, timeout10) data resp.json() # 根据实际响应结构调整取值路径 category_name data.get(data, {}).get(category_name, unknown) book_count len(data.get(data, {}).get(list, [])) category_map[cid] { name: category_name, book_count: book_count } print(fcategory_id{cid} - {category_name}, books{book_count}) except Exception as e: print(fcategory_id{cid} - error: {e}) # 输出映射表方便后续写入配置 print(json.dumps(category_map, ensure_asciiFalse, indent2))运行结果会直接告诉你每个category_id对应的真实分类名。我实测下来跑完 20 个 ID 大概 30 秒映射表就重建好了。这一步的坑是有些接口对page_size有限制超过 20 会返回空所以先用 10 试。另外如果返回的是 HTML 而不是 JSON说明路由还是错的回到第一步重新抓。第三步是验证请求。修复路由和参数映射后不要直接跑全量脚本先用单条请求验证。你可以用curl或者 Postman 发一个最小请求确认返回的book_name、author、rank字段都有值。我习惯用下面这个curl命令做快速验证注意-H里的Referer必须带上否则番茄小说会返回 403。curl -X GET https://api.example.com/rank-list/v2/list?category_id2rank_typehotpage1page_size10 \ -H User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 \ -H Accept: application/json \ -H Referer: https://www.example.com/rank-list/ \ -H Cookie: your_cookie_here如果返回的 JSON 里data.list有 10 条记录且book_name不为空说明修复成功。这时候再把映射表写回你的爬虫配置。我建议把映射表存成独立的 JSON 文件比如category_map.json这样下次路由再变只需要更新这个文件不用改代码。这个思路和后面要讲的「项目记忆」是一样的把易变的配置和稳定的逻辑分离。排查过程中常见的报错有这几类。第一类是401 Unauthorized通常是 Cookie 过期或者缺少Referer解决方法是重新登录抓 Cookie并确保请求头里带上Referer。第二类是local proxy failed这个报错一般出现在你用了本地代理工具但配置不对检查代理端口和协议是否匹配。第三类是reading choices相关错误通常是响应结构变了比如data字段从对象变成了数组这时候需要打印完整响应体重新定位取值路径。第四类是OAuth相关报错如果你用的是带鉴权的 API检查 token 是否过期。这些报错我都踩过最有效的办法是先把完整响应体打印出来不要猜。修复完番茄小说榜单爬虫后我复盘了一下为什么这次排查花了两个小时。核心原因是路由变更和参数映射变更同时发生而且没有报错。这让我想到在德州扑克项目里配置「项目记忆」的经验。德州扑克项目里牌型判断逻辑经常因为边界场景漏判出 bug比如 A2345 同花顺轮子被判定成普通顺子。后来我把硬约束、工程约定、踩坑经验整理成一份「项目记忆」喂给 AI 编码助手再让它写牌型判断一次通过率从 35% 提升到 82%。具体做法是硬约束写清楚“牌型判断必须返回 PokerHandType 枚举禁止用字符串”工程约定写清楚“洗牌算法统一放在 src/utils/poker.ts必须用 Fisher-Yates”踩坑经验写清楚“A2345 同花顺场景必须覆盖参考 src/utils/poker.ts 里的 isWheelStraightFlush”。配置后AI 生成的代码自动规避了之前反复出问题的边界场景Code Review 耗时缩短了 41%。把「项目记忆」的思路迁移到爬虫维护上就是给爬虫项目也建一份“变更记忆”。比如记录“2024-06 路由从 /rank/ 改为 /rank-list/category_id 映射表已更新至 v2”下次再失效先查这份记忆能省掉大量重复排查。你可以先列 3 到 5 条硬约束比如“所有请求必须带 Referer”“category_id 映射表必须从 category_map.json 读取”再列 5 条以内的工程约定比如“路由变更后先跑探测脚本再改代码”最后记 2 到 3 个最严重的踩坑经验比如“page_size 超过 20 返回空”。这份记忆配置好后无论是你自己排查还是让 AI 助手帮你改代码匹配度都会大幅提升。如果你手上也有类似番茄小说榜单爬虫这种重复度高的采集任务或者你在用 AI 编码助手时总在字段映射上翻车可以试试先把项目记忆整理出来。需要快速验证模型对参数映射的理解可以用 模型对话 直接测如果是长期维护的采集项目建议走 Coding Plan 把项目记忆固化下来。接入文档和 API Key 在 接入文档 和 API Keys 里都能找到配置时记得把 Base URL、Key、Model ID 三件套写全避免 401 和 local proxy failed 这类报错。
1. 番茄小说榜单爬虫失效从页面路由变更到 API 参数映射的排查复盘番茄小说榜单爬虫失效通常表现为原本能正常抓取的榜单接口突然返回空数据、字段错位或者直接 403/404。这类问题在小说站点里特别常见因为它们的页面路由和 API 参数经常随版本迭代调整。我这次遇到的场景是一个跑了三个月的番茄小说榜单采集脚本某天开始rank_list字段全部为空但 HTTP 状态码还是 200。排查下来根因是页面路由从/rank/改成了/rank-list/同时 API 的category_id参数映射表也变了。这篇文章会把整个排查过程拆成可复制的步骤顺带复盘一下我在德州扑克项目里配置「项目记忆」后开发效率提升 40% 的经验两者在“定位变更点”这件事上思路是相通的。先说清楚这篇适合谁如果你正在维护小说榜单、电商榜单、内容聚合类的爬虫或者你用的是 AI 编码助手写采集逻辑但总在字段映射上翻车那这篇的排查清单和参数映射表可以直接拿去用。核心检索词就三个番茄小说榜单爬虫、API 参数映射、项目记忆配置。我不会讲注册流程直接进入排查和修复。番茄小说榜单爬虫失效的典型症状分三档。第一档是“静默失败”请求返回 200但 JSON 里data.list是空数组或者book_name全是 null。第二档是“路由漂移”原来请求的/api/rank/v1/list返回 404但站点首页还能正常打开。第三档是“参数错位”接口通了但category_id1原本对应“玄幻”现在返回的是“都市”导致数据串类。我这次遇到的是第一档和第三档叠加排查时如果只看状态码会完全懵掉。排查的第一步不是改代码而是先确认页面路由是否变更。打开番茄小说的榜单页用浏览器开发者工具的 Network 面板筛选rank关键字看实际发出的 XHR 请求 URL。我实测下来路由变更往往伴随路径层级调整比如从/rank/变成/rank-list/或者 API 版本号从v1升到v2。这一步的关键是不要相信你代码里写死的 URL要以浏览器实际请求为准。你可以把 Network 面板里的请求 URL 复制出来和脚本里的base_url做逐段对比差异点就是路由变更点。路由确认后第二步是抓取真实的 API 响应做参数映射对照。番茄小说的榜单 API 通常带category_id、rank_type、page、page_size这几个参数。我这次的问题是category_id的映射表变了原来1玄幻、2都市、3仙侠现在变成了1都市、2玄幻、3仙侠。这种错位不会报错但数据全乱。解决办法是写一个探测脚本遍历category_id从 1 到 20把返回的category_name字段打印出来重新生成映射表。下面这段 Python 代码可以直接复制运行注意把base_url换成你实际抓到的路由。import requests import json # 替换成 Network 面板里实际抓到的路由 base_url https://api.example.com/rank-list/v2/list headers { User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36, Accept: application/json, Referer: https://www.example.com/rank-list/ } category_map {} for cid in range(1, 21): params { category_id: cid, rank_type: hot, page: 1, page_size: 10 } try: resp requests.get(base_url, headersheaders, paramsparams, timeout10) data resp.json() # 根据实际响应结构调整取值路径 category_name data.get(data, {}).get(category_name, unknown) book_count len(data.get(data, {}).get(list, [])) category_map[cid] { name: category_name, book_count: book_count } print(fcategory_id{cid} - {category_name}, books{book_count}) except Exception as e: print(fcategory_id{cid} - error: {e}) # 输出映射表方便后续写入配置 print(json.dumps(category_map, ensure_asciiFalse, indent2))运行结果会直接告诉你每个category_id对应的真实分类名。我实测下来跑完 20 个 ID 大概 30 秒映射表就重建好了。这一步的坑是有些接口对page_size有限制超过 20 会返回空所以先用 10 试。另外如果返回的是 HTML 而不是 JSON说明路由还是错的回到第一步重新抓。第三步是验证请求。修复路由和参数映射后不要直接跑全量脚本先用单条请求验证。你可以用curl或者 Postman 发一个最小请求确认返回的book_name、author、rank字段都有值。我习惯用下面这个curl命令做快速验证注意-H里的Referer必须带上否则番茄小说会返回 403。curl -X GET https://api.example.com/rank-list/v2/list?category_id2rank_typehotpage1page_size10 \ -H User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 \ -H Accept: application/json \ -H Referer: https://www.example.com/rank-list/ \ -H Cookie: your_cookie_here如果返回的 JSON 里data.list有 10 条记录且book_name不为空说明修复成功。这时候再把映射表写回你的爬虫配置。我建议把映射表存成独立的 JSON 文件比如category_map.json这样下次路由再变只需要更新这个文件不用改代码。这个思路和后面要讲的「项目记忆」是一样的把易变的配置和稳定的逻辑分离。排查过程中常见的报错有这几类。第一类是401 Unauthorized通常是 Cookie 过期或者缺少Referer解决方法是重新登录抓 Cookie并确保请求头里带上Referer。第二类是local proxy failed这个报错一般出现在你用了本地代理工具但配置不对检查代理端口和协议是否匹配。第三类是reading choices相关错误通常是响应结构变了比如data字段从对象变成了数组这时候需要打印完整响应体重新定位取值路径。第四类是OAuth相关报错如果你用的是带鉴权的 API检查 token 是否过期。这些报错我都踩过最有效的办法是先把完整响应体打印出来不要猜。修复完番茄小说榜单爬虫后我复盘了一下为什么这次排查花了两个小时。核心原因是路由变更和参数映射变更同时发生而且没有报错。这让我想到在德州扑克项目里配置「项目记忆」的经验。德州扑克项目里牌型判断逻辑经常因为边界场景漏判出 bug比如 A2345 同花顺轮子被判定成普通顺子。后来我把硬约束、工程约定、踩坑经验整理成一份「项目记忆」喂给 AI 编码助手再让它写牌型判断一次通过率从 35% 提升到 82%。具体做法是硬约束写清楚“牌型判断必须返回 PokerHandType 枚举禁止用字符串”工程约定写清楚“洗牌算法统一放在 src/utils/poker.ts必须用 Fisher-Yates”踩坑经验写清楚“A2345 同花顺场景必须覆盖参考 src/utils/poker.ts 里的 isWheelStraightFlush”。配置后AI 生成的代码自动规避了之前反复出问题的边界场景Code Review 耗时缩短了 41%。把「项目记忆」的思路迁移到爬虫维护上就是给爬虫项目也建一份“变更记忆”。比如记录“2024-06 路由从 /rank/ 改为 /rank-list/category_id 映射表已更新至 v2”下次再失效先查这份记忆能省掉大量重复排查。你可以先列 3 到 5 条硬约束比如“所有请求必须带 Referer”“category_id 映射表必须从 category_map.json 读取”再列 5 条以内的工程约定比如“路由变更后先跑探测脚本再改代码”最后记 2 到 3 个最严重的踩坑经验比如“page_size 超过 20 返回空”。这份记忆配置好后无论是你自己排查还是让 AI 助手帮你改代码匹配度都会大幅提升。如果你手上也有类似番茄小说榜单爬虫这种重复度高的采集任务或者你在用 AI 编码助手时总在字段映射上翻车可以试试先把项目记忆整理出来。需要快速验证模型对参数映射的理解可以用 模型对话 直接测如果是长期维护的采集项目建议走 Coding Plan 把项目记忆固化下来。接入文档和 API Key 在 接入文档 和 API Keys 里都能找到配置时记得把 Base URL、Key、Model ID 三件套写全避免 401 和 local proxy failed 这类报错。
