能否精准检测网站使用的所有API？具体实现方法是什么

完全可以实现高覆盖率的API检测，BuiltWith这类工具漏检率高（尤其是浏览器API场景），核心原因是它的检测逻辑以静态特征匹配为主，不会完整追踪页面全生命周期的动态调用行为。不存在100%无遗漏的非侵入式检测方案，但通过多层捕获逻辑组合，可以把漏检率压到极低，检测效果远好于常规的特征扫描类工具。

BuiltWith类工具常见漏检原因 #

• 仅扫描初始HTML的静态标签、静态资源的URL特征，不会捕获用户交互后才触发的API调用，比如点击按钮后才发起的支付接口、懒加载接口、单页应用路由切换后才加载的服务调用
• 对浏览器原生API的Hook覆盖不全，无法追踪经过混淆、代理封装的调用，比如业务代码重写fetch/XMLHttpRequest后再发起的请求，或是Web Worker、Service Worker上下文里发起的调用，基本不会被捕获
• 未覆盖WebSocket、WebRTC、Beacon API这类非XHR/非fetch的通信链路
• 扩展内容脚本注入时机晚于页面初始脚本执行，页面初始化阶段发起的API调用会被直接漏掉

具体实现方案 #

建议采用「浏览器端前置Hook + 网络层全局兜底 + 静态分析补全 + 交互模拟覆盖」的组合方案，爬虫场景下适配性更强。

1. 浏览器端前置Hook（核心解决浏览器API漏检问题） #

这部分的核心要求是Hook脚本必须在页面所有业务脚本执行前注入，不能用普通浏览器扩展默认的内容脚本注入时机，要通过扩展的webRequest能力在文档开始加载阶段（document_start）注入，或是通过无头浏览器的初始化脚本能力提前注入，提前覆盖所有可能的调用入口：

• 网络请求类API覆盖：重写原生XMLHttpRequest所有实例方法、全局fetch方法、navigator.sendBeacon方法，调用触发时同步记录请求方法、URL、参数、返回状态，注意要保留原方法的执行逻辑，不能破坏页面正常运行。同时额外捕获WebSocket、EventSource（SSE）、RTCPeerConnection（WebRTC）这类长连接/实时通信API的连接地址与交互数据。
• 浏览器原生能力API覆盖：如果需要检测页面调用的浏览器内置API（比如地理位置、剪贴板、摄像头、本地存储相关能力），对navigator、window下对应方法做包装，每次调用都打日志记录。可以通过Object.defineProperty把Hook后的方法伪装成原生函数，避免被页面的反篡改检测识别。
• 特殊执行上下文覆盖：不要只在主页面上下文注入Hook，要开启扩展的all_frames权限，同时覆盖iframe（含跨域iframe）、Web Worker、Service Worker的执行上下文，这类上下文里发起的调用是普通检测工具最容易遗漏的部分。

2. 网络层全局兜底（爬虫场景适配） #

做爬虫类自动化检测时，不要只依赖浏览器端的Hook记录，要在网络层做全局流量捕获兜底：

• 用Puppeteer、Playwright这类无头浏览器工具时，直接监听浏览器实例的全局request事件，所有上下文发起的请求都会在这个事件层触发，不会因为Hook失效漏记。
• 需要更高覆盖率的场景，可以给爬虫实例配置全局代理，把所有进出的HTTP/HTTPS、WebSocket流量全部走代理记录，哪怕是浏览器组件、特殊插件发起的请求也能捕获到。
• 必须加交互模拟逻辑：不要页面初始加载完成就结束检测，要模拟真实用户行为——滚动页面、点击所有可见交互元素、切换单页应用路由、等待足够长的懒加载超时时间，大量API是用户触发后才会发起调用的，不做交互模拟必然出现漏检。

3. 静态分析补全 #

对爬取到的所有静态JS资源做AST语法分析，识别代码里写死的API路径、浏览器API调用特征，补全那些触发条件极端、模拟交互也没有触发到的API调用。注意这部分只能作为动态捕获的补充，不能作为主要检测手段，否则会和BuiltWith一样出现大量动态调用漏检。

这套组合方案对常规站点的API检测覆盖率可以达到95%以上，尤其是浏览器原生API、动态触发接口、Worker上下文调用的检测效果远好于静态扫描工具。唯一可能出现漏检的场景是页面有极强的反爬检测，识别到自动化环境后不发起真实API调用，这类场景配合常规的反检测手段绕过环境识别即可。

内容的提问来源于stack exchange，提问作者Jumbino