没有公开文档的 API 怎么找：从 SPA 前端逆向数据接口的六个步骤

工作中经常遇到这种情况：某个平台的功能只能在页面上点，但有批量操作、自动化、数据分析的需求，需要直接调用它背后的接口。可平台不提供公开文档。

这篇文章总结一套可复用的方法：从页面源码出发，一步步定位数据接口。整个过程只用浏览器开发者工具和 grep，不需要任何特殊工具。文中所有示例都来自公开可访问的页面，仅用于说明方法；实际使用时请仅针对你自己有权访问的账号和数据，并遵守平台的服务条款。

一、第一步：判断页面是服务端渲染还是前端渲染

打开目标页面的源代码（不是 Elements 面板，是「查看网页源代码」）：

如果是服务端渲染，数据通常直接出现在 HTML 里，用 grep 搜关键词就能拿到，甚至不需要找接口。

如果是前端渲染（SPA），源码里只有一堆 script 标签和一个空的挂载点，比如只有一个 id="app" 的 div 和几个 js 文件。这时数据必然是页面加载后通过接口异步取回来的。

判断方法：在源码里搜索你要的数据关键词。搜得到就是服务端渲染，搜不到就是前端渲染，需要走后续步骤。

二、第二步：找到真正的业务 JS

SPA 的 script 标签通常分三类：

第一类是公共库，比如 jquery、统计脚本、客服组件，与业务无关，跳过。
第二类是框架运行时，比如 vite 的 polyfill、webpack 的 runtime。
第三类是业务入口，文件名常带 index、main、app 加一串 hash，路径里往往有构建产物目录名。

找第三类的方法：看 script 标签的路径特征。现代构建工具通常把产物放在 assets 目录，文件名形如 index.abc123.js、main.abc123.js。下载这一个文件，它就是入口。

注意一个坑：入口文件常常只有几十 KB，里面只是路由表和动态导入语句，真正的业务代码被打包进了按路由拆分的 chunk。这时要看入口里 import 的路径，顺着下载对应 chunk。

三、第三步：从 JS 里提取接口路径

拿到业务 JS 后，直接 grep 字符串常量。接口路径通常以引号包裹的字面量出现，可以这样搜：

grep -oE '"/[a-zA-Z0-9/_.-]{5,60}"' main.js | sort -u

然后按业务关键词过滤，比如搜 activity、list、detail、submit、query 等。你会得到一批候选路径。

这一步有两个关键陷阱：

陷阱一，前端路由和接口长得一样。现在很多应用的路由也是这种路径形式，比如 /events、/activity/list。怎么区分？看上下文：如果路径出现在路由配置里（周围有 path:、component:、redirect: 等字样），那是前端路由，不是接口。真正调用接口的地方，代码里通常有请求方法，或者有 fetch、axios 之类的调用。

陷阱二，接口不是完整字符串。很多项目把 base 前缀和具体路径分开控制，代码里只出现了后半段。这时要搜 baseURL、base、prefix 这类变量，把两段拼起来。

四、第四步：确认接口域名

找到路径后，还要确认请求发往哪个域名。三种常见形态：

第一种，同域。接口就在页面所在域名下，直接拼路径即可。

第二种，独立 API 域。代码里会有一个域名常量，比如某个 api 子域，或者按环境变量切换的多套配置。

第三种，网关转发。页面域名下有个统一前缀（比如 /api/rest、/servlet），由网关转发到后端服务。

提取方法同样是 grep：搜 https:// 加平台域名特征，或者搜域名赋值语句。注意区分配置里出现的「跳转链接」和「接口域名」，前者通常是文档链接、帮助中心链接。

五、第五步：先用只读接口验证，靠错误码定位问题

候选接口到手后，不要直接调写操作。先找一个只读的列表接口试请求，用返回内容验证三件事：路径对不对、域名对不对、参数格式对不对。

这一步的核心技巧是读懂错误响应。不同错误码指向完全不同的排查方向：

返回 404 且是框架风格的空响应，路径可能错了，或者这个接口需要特定前缀。
返回「缺少必要请求头 X」，说明路径对了，只是鉴权或元信息不全。
返回「参数校验失败，缺少某某字段」，说明路径对了、鉴权也过了，只差参数。
返回「用户未登录」并给出登录跳转地址，说明这个接口需要登录态。

很多平台的错误信息写得很具体，比如会直接告诉你缺哪个头、哪个参数必填。按错误信息一步步补齐，比反复猜参数效率高得多。

这里还有一个实用发现：如果列表接口的返回里包含登录跳转地址，那个地址往往会暴露平台的认证域名和回调路径，对理解整体架构很有帮助。

六、第六步：处理鉴权

能拿到数据的接口通常需要鉴权，常见四种：

Cookie 会话。浏览器登录后的 cookie 直接带上即可。
Bearer Token。登录响应或本地存储里会有一个 token。
签名认证。请求头里带签名，算法通常在 JS 里可以找到，属于固定模式的 HMAC 或哈希拼接。
临时凭证。云平台常见，用长期凭证换短期凭证，再拿短期凭证调接口。

对自动化来说，优先选择平台正式提供的凭证机制（比如官方的命令行工具、SDK、开放的 token 管理），而不是逆向出来的会话 cookie。前者稳定、可审计、不会因为前端改版失效；后者属于不稳定方案，仅适合临时性的分析需求。

七、几个反复遇到的坑

坑一：WAF 拦截静态资源。下载 JS 时如果返回几百字节的奇怪内容，或者状态码异常，通常是请求头太像脚本，补一个常见的浏览器 User-Agent 再试。

坑二：多版本 API 并存。云平台的接口常有多个版本，默认版本和指定版本的参数格式可能完全不同。看到提示「这是多版本接口，默认版本是 v3」时，先查 v3 的参数字段名，不要拿旧版本的参数硬套。

坑三：路径里的特殊字符。中文路径、加号、空格在 URL 里必须编码，否则会被当成不同的资源。测试时用编码后的形式，脚本里也一样。

坑四：把行为埋点当成接口。页面里常有一堆统计上报请求，这类接口返回空对象，对业务没有价值，不要在它们上面浪费时间。

八、方法总结

整套方法可以压缩成六句话：

一看源码判断渲染方式；
二找入口 JS 和业务 chunk；
三 grep 路径字面量并排除前端路由；
四 grep 域名并拼出完整地址；
五用只读接口加错误码反向验证；
六优先走官方凭证而不是逆向 cookie。

这套方法的价值不在于「能调某个接口」，而在于建立一种理解系统的路径：任何一个页面，数据从哪里来、经过什么网关、需要什么凭证，都可以通过公开可得的静态资源推断出来。

最后强调一句边界：分析方法是中性的，使用场景不是。仅在自己的账号、自己有权访问的数据、平台条款允许的范围内使用；批量抓取、绕过权限、规避限流都不在此列。把方法用在自动化自己重复劳动上，才是它真正的价值。

（本文所述操作均基于公开可访问页面的静态资源分析，未涉及任何权限绕过。）