VSCode调试Next.js服务端代码需用attach模式：配置launch.json的type为node、request为attach、port与next dev --inspect端口一致，并设置skipFiles和outFiles；Nuxt 3需确保SSR触发、sourceMap开启且路径匹配。
VSCode 调试 Next.js 服务端代码：launch.json 怎么写
Next.js 的服务端逻辑（比如 getServerSideProps、API Routes）默认不进断点，因为 Node.js 进程不是直接由 VSCode 启动的，而是被 next dev 内部管理。必须让 VSCode 附着（attach）到实际运行的 Node 进程，或改用 node --inspect 启动。
推荐用 attach 模式，稳定且兼容所有 Next.js 版本：
- 确保启动命令是
next dev --inspect=0.0.0.0:9229（加--inspect参数暴露调试端口） -
launch.json中 type 必须是node，不是pwa-node（旧版可能失效） -
port要和--inspect后一致，address默认localhost，Docker 或 WSL 需改成0.0.0.0 - 别漏掉
skipFiles配置，否则断点会卡在node_modules里 —— 加上["<node_internals>/**"]</node_internals>
{
"type": "node",
"request": "attach",
"name": "Attach to Next.js",
"port": 9229,
"address": "localhost",
"skipFiles": ["<node_internals>/**"],
"outFiles": ["${workspaceFolder}/.next/server/**/*.js"]
}
Nuxt 3 服务端调试失败：useServerSeoMeta 断点不触发？
Nuxt 3 的服务端逻辑（如 server/api/、server/plugins/、useServerSeoMeta）只在 SSR 渲染时执行，纯客户端导航（例如点击 <NuxtLink>）不会重新跑服务端代码 —— 所以断点自然不触发。
验证是否真在服务端执行：
- 在
server/api/hello.ts里加console.log('pid:', process.pid)，刷新页面看日志是否输出 - 浏览器访问
/api/hello直接触发 API Route，这时断点才有效 -
useServerSeoMeta只在首次 SSR 时调用，后续客户端跳转无效，别在onMounted里指望它 - Nuxt 3 默认用
nitro作为服务端引擎，调试需对准.nuxt/dist/server下的产物，sourceMap必须开启（nitro.options.sourceMap = true）
调试时断点全灰、提示“未加载源映射”
VSCode 找不到原始 TS 文件，本质是生成的 JS 没带正确 sourceMappingURL，或路径映射错位。Next.js 和 Nuxt 都依赖构建配置导出 sourcemap。
常见修复动作：
- Next.js：确认
next.config.js中没关productionBrowserSourceMaps: true（开发期默认开，但自定义 webpack config 可能覆盖） - Nuxt 3：检查
nitro.config.ts是否有sourceMap: true，且没被rollupOptions.output.sourcemapExcludeSources干掉 - VSCode 的
outFiles路径要匹配实际输出位置 —— Next.js 是.next/server/...，Nuxt 3 是.nuxt/dist/server/... - 删掉
.next或.nuxt重跑dev，旧缓存 sourcemap 容易错乱
Chrome DevTools 能断住，VSCode 却不行？
不是配置问题，是 VSCode 的 Node 调试器和 Chrome 的 V8 调试协议存在行为差异：VSCode 对 dynamic import()、ESM 模块热更新、eval 生成代码支持更弱。
典型表现：
- API Route 里用了
import(...).then，VSCode 断点失效，Chrome 可以 - Nuxt 3 的
defineEventHandler包裹函数，VSCode 有时识别不出上下文 - 解决办法：把动态逻辑提前静态化，或改用
debugger语句 + Chrome 调试辅助定位 - VSCode 1.85+ 对 ESM 支持更好，但若项目用了
esbuild或自定义打包器，仍建议优先信任 Chrome 的 Sources 面板
服务端调试真正麻烦的从来不是配 launch.json，而是搞清哪段代码真在服务端执行、哪段只是看着像 —— 刷新页面、看终端日志、查 Network 里的 XHR，比反复改配置管用得多。
