nitro dev 断点不生效需确认是否在服务端上下文调试：用 node.js: attach to process 模式，启动时加 --inspect=9229，断点仅对 server/ 下文件有效，中间件须在 nitro.config.ts 显式注册且导出默认函数。

nitro dev 启动后断点不生效？先确认是否在服务端上下文里调试

VSCode 默认的 launch.json 启动配置（如 Node.js: Launch Program）对 Nitro 无效——Nitro 开发服务器是长期运行的进程，不是一次性脚本。你打的断点可能落在客户端代码里，而实际逻辑跑在服务端。

实操建议：

Skill Weave Chains — 技能链路由引擎

开箱即用的技能链路由引擎。13 条预定义链覆盖搜索、开发、审查、MLOps、法律、创意等场景，三层路由架构（触发词→SAD反馈→DAG编排），recall@10=96.97%。配置驱动（chains.yaml），零代码扩展。pip install skill-weave-chains 一键安装。

下载

• 用 Node.js: Attach to Process 模式：启动 nitro dev 后，在 VSCode 中按 Ctrl+Shift+P → 输入 Debug: Attach to Node Process，选中对应 PID
• 或改用显式 attach 配置，launch.json 必须含 "port": 9229 和 "restart": true（热重载时自动重连）
• 启动 Nitro 时加 --inspect=9229：运行 nitro dev --inspect=9229，否则调试器连不上
• 断点只对 server/ 下的文件有效（如 server/api/hello.ts、server/middleware/auth.ts），pages/ 或 components/ 里的代码不在此调试范围内

调试 server/middleware/ 里的中间件没反应？检查 handler 注册方式

Nitro 中间件不会自动执行，必须通过 nitro.config.ts 显式注册，且路径匹配规则严格。写在 server/middleware/ 目录下 ≠ 自动生效。

常见错误现象：

• 写了 server/middleware/logging.ts，但终端日志里完全没输出
• 访问 /api/user，中间件没触发，但 /api/* 规则明明配了

实操建议：

• 确保 nitro.config.ts 中 handlers 正确声明：

  export default defineNitroConfig({
    handlers: [
      { route: '/api/**', handler: './server/middleware/auth.ts', middleware: true }
    ]
  })

• route 是 glob 模式，/api/** 匹配所有子路径，/api/* 不匹配 /api/user/profile
• 中间件文件导出必须是默认函数：export default defineEventHandler(...)，不能是命名导出或普通函数
• 若用 server/routes/ 写路由，它不走中间件管道——只有 server/api/ 和显式注册的 handlers 才受中间件影响

server/api/ 下的 API 断点跳过？检查 sourcemap 和构建产物路径

Nitro 在开发模式下会生成临时构建目录（如 .nitro/output/server/index.mjs），VSCode 调试器需要靠 sourcemap 把运行时代码映射回源码。如果映射失败，断点就“悬空”。

实操建议：

• 确认 nitro.config.ts 含 sourceMap: true（默认开启，但自定义 build 配置可能覆盖）
• 不要手动修改 .nitro 目录，清理缓存用 rm -rf .nitro + 重启 nitro dev
• 断点必须打在原始 TS 文件上（如 server/api/hello.ts），不能打在 .nitro/output/ 下的 JS 文件里
• 若使用 defineEventHandler 包裹逻辑，断点要放在函数体内，而非顶层；顶层代码在服务启动时即执行，无法被常规断点捕获

怎么验证中间件或 API 是否真被调用？别只看浏览器响应

浏览器返回 200 不代表中间件跑了，也不代表 API 处理函数执行了——可能是缓存、代理拦截、或 Nitro fallback 到静态资源。

实操建议：

• 在中间件或 API 文件里加 console.log('hit auth middleware')，观察终端输出，这是最直接的触发证据
• 用 curl -v http://localhost:3000/api/test 绕过浏览器缓存和扩展干扰
• 检查 Nitro 日志前缀：正常请求会显示 [nitro] GET /api/test，若只看到 [nitro] Serving static file，说明请求根本没进路由系统
• 路径区分大小写且严格匹配：注册了 /api/users，但请求 /API/users 就不会命中

Nitro 的服务端调试不依赖浏览器 DevTools，也不靠 VSCode 插件自动识别——它本质是 Node.js 进程调试，所有关键动作都发生在终端与 launch.json 的配合里。最容易被忽略的是：你以为在调试中间件，其实只是在编辑一个没被注册的 TS 文件。