vscode调试oak应用断点不触发，90%是请求未进入中间件链：先验证请求是否到达应用层（加console.log），检查端口、deno扩展启用、launch模式配置（非attach）、--allow-net权限、路由路径匹配及mock测试中间件。
VSCode 调试 Oak 应用时断点不触发，90% 的情况不是配置错，是请求根本没进到中间件里——Oak 的 app.use() 是洋葱模型，漏掉 await next() 或中间件提前 return，后续所有中间件都静默跳过。
确认请求真进了 Oak 中间件链
断点设在 app.use((ctx, next) => { ... }) 里却从不停，先验证请求是否穿透到了应用层：
- 在第一个中间件里加
console.log("→ request entered")，用curl -v http://localhost:8000/触发，看终端有没有输出 - 没日志？检查 Deno 是否监听了正确端口：
app.listen({ port: 8000 })和你curl的地址是否一致；也可能是防火墙或端口被占用 - 有日志但断点仍不触发？确认 VSCode 已启用 Deno 扩展，且左下角状态栏显示
Deno (v1.x)；若不显示，说明扩展未激活或deno命令不在$PATH - Oak 不会自动处理
OPTIONS预检请求，前端发带认证头的请求时，浏览器先发OPTIONS——它不会进你的业务中间件，只走内置路由匹配逻辑
launch.json 必须用 launch 模式启动带调试参数的 deno run
VSCode 默认的 attach 模式对 Oak 无效，因为 Oak 是单进程直接运行，没有“已存在的进程”可 attach。必须用 launch 模式拉起带 --inspect-brk 的 Deno 进程：
Skill Weave Chains — 技能链路由引擎
下载
开箱即用的技能链路由引擎。13 条预定义链覆盖搜索、开发、审查、MLOps、法律、创意等场景，三层路由架构（触发词→SAD反馈→DAG编排），recall@10=96.97%。配置驱动（chains.yaml），零代码扩展。pip install skill-weave-chains 一键安装。
-
program字段只能填deno命令本身，不能填.ts文件路径；实际执行靠args - 正确配置示例（保存为
.vscode/launch.json）：
{
"version": "0.2.0",
"configurations": [
{
"name": "Debug Oak",
"type": "pwa-node",
"request": "launch",
"runtimeExecutable": "deno",
"runtimeArgs": [
"run",
"--inspect-brk",
"--allow-net",
"--allow-env",
"${workspaceFolder}/server.ts"
],
"port": 9229,
"sourceMaps": true,
"outFiles": ["${workspaceFolder}/**/*.js"],
"cwd": "${workspaceFolder}"
}
]
}
- 缺
--allow-net会导致服务根本启动失败，但错误可能被调试器吞掉，表现为“启动后立刻退出” -
--inspect-brk让 Deno 在第一行就暂停，确保断点来得及注册；去掉它，某些快速执行的中间件（如日志）可能一闪而过 - 如果用
import_map.json，必须在runtimeArgs里显式加--import-map=import_map.json
调试路由匹配与 ctx.request.path 匹配逻辑
Oak 的 Router 中间件（如 router.get("/api/users", ...)）本质仍是 app.use() 链中一环，但它内部做了路径匹配。断点不触发常因路径不匹配：
- 确保
router.routes()和router.allowedMethods()都传给了app.use()，顺序不能反 - 在路由回调里打日志：
router.get("/api/users", (ctx) => { console.log("path:", ctx.request.url.pathname); ctx.response.body = "ok"; }) - Oak 默认不 strip trailing slash，
/api/users/和/api/users是两个不同路径；用router.get("/:id?", ...)这类通配时，ctx.params.id可能是undefined，别直接解构 - 检查
ctx.request.url.origin和ctx.request.url.pathname的实际值，前端代理（如 Vite 的proxy）可能把路径重写了，但 Oak 看到的是代理后的原始路径
测试中间件别跑真实服务器，用 createMockContext
调试单个中间件时，启动整个 Oak 服务纯属浪费时间。Oak 官方测试工具提供轻量模拟上下文：
- 安装测试依赖：
jsr:@oak/oak已含testing模块，无需额外装 - 写一个最小测试文件
middleware.test.ts：
import { testing, Application } from "https://deno.land/x/oak/mod.ts";
import { assertEquals } from "https://deno.land/std/assert/assert_equals.ts";
const authMiddleware = async (ctx: any, next: any) => {
const token = ctx.request.headers.get("Authorization");
if (!token) ctx.throw(401);
await next();
};
Deno.test("auth middleware rejects missing token", async () => {
const ctx = testing.createMockContext({
method: "GET",
path: "/api/data",
headers: new Headers(), // 空 Authorization
});
const next = testing.createMockNext();
try {
await authMiddleware(ctx, next);
throw new Error("should have thrown");
} catch (e) {
assertEquals(e.status, 401);
}
});
- 运行：
deno test --allow-env --allow-net middleware.test.ts；VSCode 点 “Debug Test” 按钮前，确保已启用 Deno 扩展并工作区根目录有deno.json - 注意：mock context 不触发网络、不读文件、不走真实路由，只专注中间件逻辑本身——这才是调试的合理粒度
最易忽略的一点：Deno 的权限模型是硬性拦截，不是警告。断点进不去，有时只是因为 --allow-net 漏了，服务启动失败被静默吞掉；务必在终端手动跑一次 deno run --allow-net server.ts 确认基础可运行，再进 VSCode 调试。
