VSCode 本身不拦截 HTTP 请求，所有链路日志均需代码显式输出；诊断微服务调用链的关键是主动注入 trace_id 并输出结构化 JSONL 日志，配合 LogLens 解析与正确配置。
直接说结论：VSCode 本身不拦截 HTTP 请求，http 或 axios 等客户端发出的请求不会自动出现在调试控制台或日志面板里——你看到的“链路日志”，全是代码里显式调用 console.log、logger.info 或调试器 output 事件产生的。想诊断多层级微服务间的 HTTP 调用链，关键不是“打开某个开关”，而是让每层服务在发请求前/收响应后，主动注入可追踪的上下文并输出结构化日志。
为什么断点+Console.log 在微服务链路里会失效
你在 Service A 的 fetchUser() 里打了个断点，看到 res.status === 200，但 Service B 的错误堆栈没出来？这不是 VSCode 的问题，是 Node.js 的异步调度和进程隔离导致的：
-
Service A和Service B运行在不同进程（甚至不同容器），VSCode 的单个调试会话无法跨进程捕获Service B的console输出，除非你手动 attach 到它的调试端口 - HTTP 客户端（如
node-fetch、axios）底层走的是http.ClientRequest，它不触发 DAP 的output事件，除非你用debug模块或自定义拦截器显式输出 - 如果你只在
launch.json里配了"trace": true，那只会输出 V8 引擎内部的调试协议帧（比如{"type":"event","event":"output","body":{"category":"console","output":"..."}}），不是业务 HTTP 日志
必须在代码里加的 3 类拦截器日志
不改代码，VSCode 就是个哑巴编辑器。以下是最小可行的日志注入点，按优先级排序：
-
出向请求拦截（Service A → Service B）：在
axios.interceptors.request.use或fetch封装函数里，记录method、url、headers['x-trace-id']、headers['x-span-id']—— 这些字段必须由上游传入，不能自己生成 -
入向响应拦截（Service B 收到请求）：在 Express/Koa 中间件里，用
req.id（来自express-request-id）或req.headers['x-trace-id']打印INFO日志，格式为 JSONL：{"time":"2026-06-30T16:02:00.123Z","level":"INFO","service":"service-b","trace_id":"abc123","span_id":"def456","msg":"request received","path":"/api/user"} -
错误兜底日志（Service B 抛错时）：不要只写
console.error(err)，要提取err.status、err.code、err.response?.data并打成ERROR级别结构化日志，否则 LogLens 无法识别为错误行
VSCode 里让这些日志真正“可诊断”的配置项
光打日志不够，得让 VSCode 看得懂、筛得快、关联得准：
- 在
.vscode/settings.json里启用原生LogLens解析："logLens.autoParseJsonLines": true—— 这能让 VSCode 自动把 JSONL 日志拆成字段，支持点击trace_id折叠/展开同链路日志 - 禁用污染性调试配置：
"logging": {"engineLogging": false}必须设为false，否则dap.js的千行协议日志会淹没你的业务日志 - 终端里用
tail -F logs/*.log启动后，右键日志文件 → “Open with Log Viewer”，再按Ctrl+Shift+P输入Log: Filter by Regex，输入"trace_id":"abc123"即可秒级定位整条链路 - 如果用的是
winston，确保format.json()开启，且transport写入的是单行 JSON（不是美化缩进格式），否则 LogLens 会解析失败
最常被忽略的一点：TraceID 必须从入口服务透传到下游，且所有日志都得带这个字段。VSCode 不会帮你生成或传播它，它只是个显示器——你喂给它的数据什么样，它就呈现什么样。链路断裂，从来不是工具的问题，是上下文丢失的问题。
