定位AJAX真实请求需打开开发者工具Network标签页，刷新或触发动作后筛选XHR/Fetch，查看200响应的Response数据；关注Initiator定位JS来源，检查Query参数（如sign、timestamp）并全局搜索生成逻辑，注意GraphQL、SSE、WS等非常规请求类型及反爬校验。
用浏览器开发者工具定位真实请求
AJAX数据不直接写在HTML里，而是由JavaScript发起的独立HTTP请求加载。关键不是看页面源码，而是抓它发出去的请求本身。
打开浏览器开发者工具（F12），切到 Network 标签页，然后刷新页面或触发加载动作（比如滚动、点击“加载更多”）。筛选条件选 XHR 或 Fetch，就能看到所有异步请求。
- 留意
Status为 200 的请求，点开看Response是否含你要的数据（JSON格式最常见） - 如果请求太多，可右键列头勾选
Initiator，快速定位是哪个JS文件触发的 - 有些站点用
blob:或data:协议加载，这类不是标准HTTP请求，得回溯到调用它的fetch()或XMLHttpRequest代码里找URL
处理动态生成的请求参数（如 sign、timestamp、token）
很多接口带校验参数，直接复制URL用 requests 请求会返回错误或空数据。这不是没找到接口，而是参数失效了。
在 Network 里点开目标请求，看 Headers 下的 Request URL 和 Query String Parameters，再对比 Preview 或 Response 确认是否含有效数据。若参数含 sign=xxx、_t=171xxxx 这类，说明服务端做了签名或时效校验。
python-script-generator
下载
快速生成专业的 Python 脚本和应用代码。一键创建完整项目结构，支持CLI、API、爬虫、Bot、Django等多种项目类型，包含完整的项目结构、配置文件、依赖管理、测试、README和文档。
立即学习“Python免费学习笔记（深入）”；
- 用
Ctrl+Shift+F全局搜索关键词（如sign、getSign、md5），在 Sources 面板里找生成逻辑 - 重点关注
fetch()调用前的变量赋值，或封装好的请求函数（如api.getPostList()） - 部分站点把加密逻辑打包进混淆JS，此时需用
PyExecJS或nodejs子进程调用原生JS执行，而不是硬解算法
绕过前端渲染、直连后端API的典型陷阱
有些网站看似是AJAX，实则走的是GraphQL、WebSocket 或 Server-Sent Events（SSE），这些在 Network 面板里不会显示为常规 XHR/Fetch 请求。
- GraphQL 接口通常只有一个
/graphql端点，Request Payload是 JSON，含query字段；用requests.post(url, json={"query": "..."})即可模拟 - SSE 请求在 Network 中类型标为
eventsource，响应头含Content-Type: text/event-stream；Python里不能用普通 requests，得用requests.get(..., stream=True)并手动解析data:行 - WebSocket 不在 Network 的 XHR 列表里，需切到
WS子标签查看；但一般不建议用Python硬连 WS 抓数据，优先找它背后的真实REST接口
当所有请求都返回403/401或空响应时怎么办
不是接口找不到，而是请求被服务端识别为非浏览器行为。现代反爬常检查 User-Agent、Referer、Cookies，甚至 TLS 指纹和 JS 环境特征。
- 先用浏览器完整访问一次目标页面，确保 Cookies 已生效；再复制
Cookie字符串填进requests.get(..., headers={"Cookie": "xxx"}) -
Referer必须匹配来源页URL，否则某些接口直接拒绝；User-Agent建议用当前浏览器实际值（可在 Network → Headers → Request Headers 里复制） - 如果加了所有头仍失败，大概率服务端做了 JavaScript 指纹检测（如
navigator.webdriver、WebGL vendor），此时需用selenium或playwright启动真实浏览器上下文，而非纯HTTP请求
真正难的不是找不到接口，而是接口背后那层动态参数生成逻辑和环境校验——它藏在JS里，不运行就看不到结果。别花时间猜URL，先让浏览器替你发出请求，再逆向它怎么构造的。
