vscode 仅支持通过 miniflare 在本地调试 cloudflare workers；生产环境不支持断点调试，唯一可观测方式是 wrangler tail 日志。
VSCode 不能直接调试 Cloudflare Workers 生产环境，所有“调试”都发生在本地模拟环境（Miniflare）中；生产环境唯一可观测方式只有 wrangler tail 日志。
VSCode 断点调试只对 wrangler dev 有效
Workers 运行在 V8 isolates 中，启动是微秒级瞬时的，不暴露调试端口，也不支持 node --inspect 或 Chrome DevTools 的 attach 流程。你无法像调试本地 Node.js 那样，在 VSCode 里配个 launch.json 就连上远程边缘节点——那根本不存在。
真正能用断点的地方，仅限于 wrangler dev 启动的本地 Miniflare 模拟环境。它会启动一个兼容 Chrome DevTools 协议的调试服务（固定端口 9229），VSCode 才能借此介入。
- 确保项目使用 Wrangler v3+，且未在
wrangler.toml中设置local = false - 运行
wrangler dev --remote=false强制走本地模拟（避免误连预览环境） - 在代码中写
debugger;，不是console.log——后者在生产环境才可见
launch.json 必须匹配 Miniflare 的实际地址和路径映射
VSCode 的调试配置不是通用模板，稍有偏差就无法触发断点。关键字段必须严格对齐 Miniflare 的行为：
-
urlFilter必须是wrangler dev实际监听的地址，默认为http://localhost:8787/*；若改了端口（如加--port 3000），这里也得同步改 -
port固定为9229，这是 Miniflare 内置的 DevTools 端口，不可自定义 -
sourceMapPathOverrides要真实反映你的源码路径，例如 Webpack 构建时用了webpack:///./src/，就得映射到${workspaceFolder}/src/；TypeScript 项目若用tsconfig.json输出到dist/，也要相应调整
生产部署后，debugger 和断点全部失效
一旦执行 wrangler deploy，代码就运行在 Cloudflare 全球边缘节点上，没有进程、无持久状态、无调试代理入口。Cloudflare 明确不提供生产环境的实时调试能力——这是安全与性能设计的必然取舍。
此时你唯一能依赖的观测手段，只有：
-
wrangler tail：实时拉取边缘日志，支持--status code、--header等过滤，但延迟通常在 1–3 秒 -
console.log：仅在wrangler tail中可见，注意不要打敏感信息（日志明文传输） - 错误堆栈：Worker 抛出未捕获异常时，
wrangler tail会输出完整 stack trace，但不会包含 source map 映射后的原始行号（除非你显式上传 sourcemap）
Wrangler CLI 是唯一可信的部署入口，VSCode 插件不可信
目前没有任何 VSCode 插件能替代 wrangler 命令完成真实部署。所谓“一键部署”插件，本质只是调用 wrangler publish 或 wrangler deploy 的封装壳，背后仍依赖本地已配置好的 Wrangler 凭据（CF_API_TOKEN 或 .wrangler/ 目录下的用户凭证）。
容易被忽略的关键点：
- CI/CD 中务必用
CF_API_TOKEN环境变量授权，而非CF_EMAIL + CF_API_KEY（后者已被 Cloudflare 标记为 legacy） -
wrangler.toml中的[env.production]区块必须显式声明vars和bindings，否则部署时不会自动注入生产环境变量 - 本地开发用
.dev.vars，但该文件默认不参与构建，也不会被上传到 Cloudflare —— 它只影响wrangler dev运行时
复杂点在于：你写的每行代码，都要同时适配两种完全不同的执行上下文——本地 Miniflare 的“类浏览器”环境，和生产边缘节点的“纯 V8 isolate”环境。比如 fetch() 在两者中行为一致，但 crypto.subtle 的可用算法、WebSocket 支持、甚至 process.env 的存在与否，都可能不同。这些差异不会报错，但会让逻辑在生产环境静默失败。
