VSCode无法直接调试或部署Cloudflare Workers生产环境，仅能通过wrangler dev启动Miniflare本地模拟环境进行断点调试，生产环境唯一可观测手段是wrangler tail日志。
VSCode 本身不支持直接调试或部署 Cloudflare Workers 生产环境——所有“配置成功”的效果，都依赖于 wrangler CLI 和本地模拟运行时（Miniflare）的配合。你无法跳过 CLI 阶段，也不能靠 VSCode 插件一键发布到边缘网络。
wrangler dev 是本地开发唯一可靠入口
Cloudflare Workers 没有进程、不暴露调试端口、也不支持 node --inspect，wrangler dev 启动的是基于 Miniflare 的本地沙箱，它模拟了 Workers runtime 行为（包括 fetch 事件、Request/Response API、KV/R2 绑定等），但仅限于开发阶段。
- 必须使用
wranglerv3+，老版本（v1/v2）的配置结构和命令已失效 -
wrangler dev默认监听http://localhost:8787，这个地址要和 VSCode 的launch.json中urlFilter严格一致 - 若项目含 TypeScript，需确保
tsconfig.json中启用了"sourceMap": true，否则断点会落在编译后代码上 - 避免误用
wrangler dev --remote=true：这会连接预览环境（非本地），VSCode 断点完全无效
VSCode launch.json 必须匹配 Miniflare 的 DevTools 协议
Miniflare 固定在 9229 端口启动 Chrome DevTools 协议服务，VSCode 只能通过 pwa-chrome 类型配置 attach 进去，不是 launch，也不是 node 类型。
- 配置中
"type": "pwa-chrome"不可改为node或pwa-node，否则连接失败 -
"urlFilter": "http://localhost:8787/*"中的路径通配符不能省略，否则 VSCode 找不到匹配页面上下文 -
sourceMapPathOverrides要根据你实际构建路径调整，例如用 Vite + TS 时可能是"webpack:///src/*": "${workspaceFolder}/src/*"或"vite://./src/*": "${workspaceFolder}/src/*" - 断点生效前提是代码里写了
debugger;，且该行未被 tree-shaking 或编译优化移除
部署必须走 wrangler deploy，VSCode 无替代方案
VSCode 没有内置部署能力，也没有官方插件能绕过 wrangler deploy 直接推送到 Cloudflare 边缘网络。所谓“集成部署”，只是把 CLI 命令封装进 tasks.json 或终端快捷方式。
- 首次部署前必须执行
npx wrangler login完成 OAuth 授权，VSCode 无法代劳 -
wrangler.toml中的name字段决定生成的子域名（如my-api.yourname.workers.dev），改名后需重新部署 - 若启用自定义域名，DNS CNAME 记录必须先添加并生效，再在 Worker 管理界面绑定，顺序颠倒会导致 404
-
wrangler deploy --dry-run可检查配置合法性，但不会真正上传，适合 CI/CD 流程前置验证
真实边缘环境没有调试器、没有进程生命周期、也没有日志实时流控台——wrangler tail 是生产环境唯一的可观测手段，而它的延迟通常在 1–3 秒。别指望在生产环境加 debugger 或 console 断点，那只会让请求卡死或超时。
