Next.js 13+ App Router 下 debugger 不生效，主因是服务端组件（SSR）与客户端执行环境混淆：debugger 在服务端代码中需用 VSCode Node.js Attach 模式（端口9229）调试，客户端逻辑须置于"use client"组件内；需确认 sourcemap、清缓存、区分 Chrome DevTools 与 VSCode 调试职责。
Next.js 13+ App Router 下 debugger 不生效？检查运行模式
VSCode 调试 Next.js 应用失败，90% 是因为没在正确的进程上下文中断点。App Router 默认启用服务端组件（SSR），debugger 放在 page.tsx 或 layout.tsx 里，实际运行在 Node.js 服务端，而你可能正对着浏览器 DevTools 打断点。
实操建议：
- 确认当前页面是否触发 SSR：访问
http://localhost:3000后，在终端观察 Next.js 启动日志是否出现wait - compiling /...和event - compiled client and server successfully—— 有 “server” 字样说明服务端代码已加载 - 服务端断点必须通过 VSCode 的 Node.js 调试器附加，不能靠浏览器 F12
- 若只想调试客户端逻辑（如
useEffect、事件处理），把debugger移到"use client"组件内部，并确保该组件未被服务端渲染（例如不在server component直接调用） - 临时禁用 SSR 验证：在
next.config.js中加experimental: { serverComponentsExternalPackages: [] }（仅调试期，不推荐长期开启）
launch.json 配置 next dev 时为什么连不上？端口与自动重启是关键
VSCode 默认的 Node.js: Launch Program 模板不适用于 Next.js，因为 next dev 是长期运行的开发服务器，不是一次性脚本，且会自动重启——调试器容易失联。
实操建议：
- 用
Node.js: Attach to Process模式，而非Launch：先手动运行npm run dev（或next dev），再在 VSCode 中按Ctrl+Shift+P→Debug: Attach to Node Process，选中next dev对应的 PID - 更稳定的方式是改用
launch.json的attach配置，显式指定port：{ "type": "node", "request": "attach", "name": "Attach to Next.js", "port": 9229, "restart": true, "protocol": "inspector", "console": "integratedTerminal" } - 启动 Next.js 时必须带
--inspect标志：next dev --inspect=9229（Next.js 13.2+ 支持；旧版需用NODE_OPTIONS='--inspect' next dev） -
restart: true很重要——Next.js 热重载会杀掉旧进程并拉起新进程，没它会导致断点失效
调试 Server Actions 或 API Route 时断点跳过？确认执行环境与 sourcemap
Server Actions 和 app/api/xxx/route.ts 是纯服务端逻辑，但 VSCode 可能因 sourcemap 映射错误或构建缓存，导致断点显示为“未绑定”（grayed out）。
dmap-jsapi-skill
下载
DMap GL地图JSAPI（dmapgl）开发指南。用于编写、审查、调试 DMap 地图 API 代码，涵盖地图初始化、覆盖物渲染、图层管理、事件处理、控件交互等任务。当用户提及 dmap、dmapgl、jsapi‑gl 或相关地图开发需求时自动触发。
实操建议：
- 确保
next.config.js中output: 'standalone'未开启（调试期应关闭，否则会跳过 dev server 的 sourcemap 生成） - 强制清除缓存：
rm -rf .next && next dev --inspect=9229（尤其改过tsconfig.json或next.config.js后） - Server Action 必须在客户端组件中触发（如
form action={...}），断点设在服务端函数体内才有效；直接在useActionState回调里打debugger是无效的 - API Route 断点只在对应 HTTP 请求发出后触发，可用
curl http://localhost:3000/api/hello触发，别只刷新页面 - 检查 VSCode 的
Debug Console是否报Could not read source map—— 若有，说明.next/server/app/...下的 JS 文件没正确映射到 TSX 源码，此时需验证tsconfig.json中compilerOptions.sourceMap为true
Chrome DevTools 和 VSCode 双调试冲突？优先级与入口点要分清
同时开 Chrome DevTools（F12）和 VSCode 调试器，容易出现断点抢夺、单步跳转错乱，尤其在混合使用客户端钩子和服务端数据获取时。
实操建议：
- 明确分工：VSCode 负责服务端逻辑（
generateStaticParams、Server Components 渲染、API Routes）、Chrome DevTools 负责客户端交互（useState、fetch响应处理、DOM 操作） - 禁用 Chrome 的 JS 断点干扰：在 DevTools → Settings → Preferences → Debugger 中勾选
Disable JavaScript debugging（调试 VSCode 期间） - VSCode 中不要启用
Smart Step Into（默认关着就行），Next.js 的打包层（如edge-runtime、webpack包裹）会让它误跳进无关代码 - 如果发现断点总停在
webpack/bootstrap或next/dist/...，说明 sourcemap 没对齐——回到上一节清缓存 + 验证配置
最麻烦的永远不是配置本身，而是服务端组件和客户端组件的边界模糊带来的执行环境误判。哪怕一个 console.log 输出位置不对，都值得先 console.log('env:', typeof window === 'undefined' ? 'server' : 'client') 确认一下。
