VSCode无法捕获预检请求（OPTIONS），因其调试器不监听网络层流量；需通过Express日志、curl验证、浏览器Network面板或mitmproxy等工具定位和调试。
VSCode 本身不处理预检请求（OPTIONS），也抓不到它——因为 OPTIONS 是浏览器发给后端的，而 VSCode 的调试器不监听网络层流量。真正在本地捕获预检请求，得靠 Node.js 服务自身日志、代理工具，或浏览器 Network 面板配合 sourcemap 定位源码发起点。
为什么在 VSCode Debug Console 里看不到 OPTIONS 请求
Node.js 调试器（包括 Chrome Debug Adapter）只挂载 JS 执行栈，fetch 或 axios 发出的请求会直接交由底层 libuv / Chromium 网络栈处理，不经过 V8 调用链。所以：
- 断点打在
axios.get('/api/data')行，能停住；但停不住 OPTIONS 请求本身 -
Debug Console不会打印任何OPTIONS日志，哪怕它已到达你的 Express 服务器 - 如果你没在 Express 中显式
app.options()或用cors()，那 OPTIONS 就根本不会被路由匹配到——此时浏览器报错是404或500，不是 CORS 错误
如何让 Express 正确响应预检请求并本地验证
关键不是“抓包”，而是确保你的 Node 服务对 OPTIONS 请求有明确、可观察的响应逻辑。最简可靠做法：
Rydberg Agent Node
下载
使用一条命令部署ProbeChain Rydberg测试网代理节点。自动注册为Agent(NodeType=1)，免gas，支持macOS/Linux/Windows。触发词：/r
- 用
cors中间件：安装npm install cors，然后在 Express 入口加app.use(cors())—— 它自动处理OPTIONS并返回正确头 - 手动拦截 OPTIONS：在路由前加
app.options('*', (req, res) => { res.set('Access-Control-Allow-Origin', '*').end(); }) - 启动服务后，在 VSCode 终端运行：
curl -v -X OPTIONS http://localhost:3000/api/users，看响应头是否含Access-Control-Allow-Origin - 别依赖浏览器自动触发：有些前端框架（如 Vue CLI）开发服务器自带代理，会吞掉 OPTIONS；直接 curl 更可信
在 VSCode 里快速定位预检失败的源头
多数“跨域失败”其实不是后端问题，而是前端发请求时没配好 base URL 或凭空多写了端口。排查路径要从发起点开始：
- 检查前端代码中
axios的baseURL：比如写成http://localhost:3001（后端跑在 3000），就会触发预检且必失败 - 确认浏览器 Network 面板中请求的
Request URL和Origin头是否真的不同源——右键 Copy as cURL，粘贴到终端执行，排除前端构建/代理干扰 - 如果用了 Webpack/Vite 开发服务器代理（如
proxy配置），预检请求可能被代理层拦截，根本没到你的 Express；此时需在代理配置里显式允许OPTIONS - VSCode 中打开
launch.json，确保env区域没意外覆盖NODE_ENV=production——某些中间件在 production 下默认关闭 CORS
真正需要抓 OPTIONS 流量时该用什么工具
当你要确认 OPTIONS 请求是否发出、带了哪些头、后端是否响应了正确的 CORS 头，VSCode 不是合适工具。该换：
- 浏览器 Network 面板：过滤
Other或直接搜OPTIONS，看 Initiator 列是否指向你写的 JS 文件（说明 sourcemap 有效） -
mitmproxy：启动mitmproxy --mode reverse:http://localhost:3000，前端请求走http://localhost:8080，所有流量（含 OPTIONS）明文可见 - Node.js 原生日志：在 Express
app.use最前面加app.use((req, res, next) => { console.log(req.method, req.url); next(); })，VSCode 调试控制台就能看到每条 OPTIONS 进来 - 别用 Charles/Fiddler 做 Node 本地调试：它们对 localhost 的代理支持不稳定，尤其 Windows 上容易被绕过
预检请求本身无业务逻辑，但它像一道安检门——漏掉它、配错它、或误以为它被 VSCode 捕获了，都会让后续真实请求卡在第一步。盯住它，比盯住响应体更重要。
