后端微服务云原生【免费下载链接】midway A Node.js Serverless Framework for front-end/full-stack developers. Build the application for next decade. Works on AWS, Alibaba Cloud, Tencent Cloud and traditional VM/Container. Super easy integrate with React and Vue. 项目地址https://gitcode.com/gh_mirrors/mi/midway点击查看免费下载导读Midway 是面向全栈 / 前后端一体化场景的 Node.js 框架仓库中同时维护了midwayjs/bootstrap与 Hooks 全栈方案本地调试能力的优劣直接影响开发效率。本文围绕 hooks/debug.md 与 docs/debugger.md 两份官方调试文档系统讲解在 VSCode、WebStorm/IDEA 等主流编辑器/IDE 中调试 Midway 应用的两种核心手段JavaScript Debug Terminal与npm Scripts 一键 Debug并补充 launch.json 手工配置、断点命中原理与启动入口分析帮助读者把「改代码 → 重启 → 看日志」的低效循环替换为「断点 → 单步 → 查变量」的精准定位流程。调试的前提理解 Midway 应用的启动入口无论使用哪种编辑器调试的本质都是「以调试模式运行应用进程再把断点挂到源码上」。因此在动手前先看清 Midway 应用是如何被启动的。以仓库中的全栈示例 samples/functional-api-hybrid/package.json 为例其scripts如下{ scripts: { build: tsc -p tsconfig.json, start: node dist/bootstrap.js, test: cross-env NODE_ENVunittest mocha } }也就是说npm start实际执行的是node dist/bootstrap.js——先由tsc将 TypeScript 编译到dist再启动编译产物中的入口文件。而dist/bootstrap.js内部调用的是 packages/bootstrap/src/bootstrap.ts 中导出的Bootstrapstatic async run() { // 注册 SIGINT / SIGQUIT / SIGTERM 等信号处理 process.once(SIGINT, this.onSignal.bind(this, SIGINT)); // ... this.runningPromise this.getStarter() .run() .then(() { this.logger.info([midway:bootstrap] current app started); global[MIDWAY_BOOTSTRAP_APP_READY] true; return this.getApplicationContext(); }) .catch(err { this.logger.error(err); process.exit(1); }); return this.runningPromise; }从源码可以看到Bootstrap.run()内部通过BootstrapStarter.init()完成应用上下文初始化读取package.json的type字段决定 ESM/CommonJS 加载方式、初始化全局容器、启动主框架并在应用就绪后打印[midway:bootstrap] current app started。这行日志可以当作调试时判断「应用是否真正启动完成」的锚点。需要留意的是调试的是 TypeScript 源码还是编译产物取决于你的启动脚本。若脚本是node dist/bootstrap.js断点应打在dist下若希望直接在src里的.ts源码上打断点则需要让调试器能够处理 TypeScript——这也是下文两种编辑器方案各自要解决的核心问题VSCode 的自动附加 / 调试器对 ts 的处理。方案一在 VSCode 中调试方法 A使用 JavaScript Debug Terminal零配置这是官方文档推荐的最快捷方式全程不需要编写任何launch.json配置文件打开 VSCode点击顶部菜单Run → Open Configurations或在活动栏切换到「运行和调试」视图Ctrl/Cmd Shift D在终端面板的下拉菜单中选择JavaScript Debug Terminal创建出一个自带调试能力的终端在该终端中直接运行任意命令例如npm start也可以是你项目scripts中配置的npm run dev等VSCode 会自动以调试模式启动该进程接下来只需在源码中打上断点请求进来时即可命中。这套机制的原理是JavaScript Debug Terminal 中的进程会被 VSCode 内置的 Node 调试器自动附加Auto Attach所有在终端里启动的 Node 进程都会继承调试能力因此「输入命令 → 自动进入调试模式」是一条链路完成的不需要手动选择进程。方法 B使用 Debug Scripts 按钮可视化选择另一种方式同样无需配置文件打开项目根目录的package.json将鼠标悬停在scripts区域上方会出现一个Debug按钮点击该按钮VSCode 会弹出当前package.json中定义的所有scripts命令如start、build、test选择start或你想要的任意命令即会以调试模式启动该脚本之后正常打断点即可。这种方式与 JavaScript Debug Terminal 殊途同归都是在调试器托管下执行 npm scripts适合「鼠标点选、避免手敲命令」的场景对刚接触调试器的开发者尤其友好。方法 C手工编写 launch.json可复现、可共享如果希望把调试配置固化为团队共享的.vscode/launch.json例如 CI 场景下排除干扰、明确指定端口和参数可以参考仓库文档 docs/debugger.md 中给出的配置模板{ version: 0.2.0, configurations: [{ name: Midway Local, type: node, request: launch, cwd: ${workspaceRoot}, runtimeExecutable: npm, windows: { runtimeExecutable: npm.cmd }, runtimeArgs: [ run, dev ], env: { NODE_ENV: local }, console: integratedTerminal, protocol: auto, restart: true, port: 7001, autoAttachChildProcesses: true }] }对这份配置的逐项说明配置项作用说明runtimeExecutable启动应用的命令载体设为npmWindows 下为npm.cmd即以 npm 托管启动runtimeArgs传给 npm 的参数[run, dev]等价于执行npm run dev可换成start、test等env.NODE_ENV运行环境变量设为local表示本地开发环境Midway 会据此加载对应环境的配置console调试输出位置integratedTerminal表示日志输出到 VSCode 集成终端restart断点编辑后自动重启为true时修改代码触发重启省去手动重跑port调试端口示例中的7001与 Midway Koa 默认端口一致用于浏览器 DevTools 等外部附加autoAttachChildProcesses自动附加子进程为true时可捕获框架内部 fork/child 出的子进程配置完成后在源码行号左侧点击打上断点再按F5启动调试即可命中。官方文档中的完整操作截图可以继续阅读 docs/debugger.md其中还包含断点命中后的调试界面演示。方案二在 JetBrainsWebStorm / IDEA中调试JetBrains 系 IDE 对 npm scripts 有一等公民的支持操作路径与 VSCode 的 Debug Scripts 类似打开项目的package.json编辑区顶部会出现各scripts命令对应的行内快捷按钮找到scripts中你希望执行的命令例如start、dev、test点击其左侧的Debug按钮绿色小虫子图标IDE 会自动创建一个临时的「npm 运行配置」并直接以调试模式启动该脚本在代码中打好断点发起请求触发对应逻辑即可进入断点单步调试。如果你更习惯显式的配置管理也可以在Run → Edit Configurations中手工新建一个npm类型的运行配置选择对应的package.json文件再从 Scripts 下拉框中选择你要执行的命令勾选 Debug 模式后运行。这种方式与点击行内 Debug 按钮效果完全一致只是把配置显式保存了下来便于跨机器复用。JetBrains 方案的天然优势在于IDE 对 TypeScript 有内建支持当你的启动脚本经由ts-node、tsx或编译产物运行时IDE 通常能正确把断点映射回src下的.ts源码无需额外配置 source-map 解析。调试实践中的几个实用要点基于仓库现状与源码补充几个容易被忽略、但直接影响调试体验的细节区分调试入口与工作目录在 packages/bootstrap/src/bootstrap.ts 中BootstrapStarter.init()默认以process.cwd()作为appDir并从package.json的type字段推断moduleLoadTypeesm或commonjs。因此在 IDE 中配置调试时务必保证运行配置的工作目录cwd指向项目根目录否则会出现「找不到配置 / 加载了错误的包」之类的诡异问题。判断应用是否就绪Bootstrap.run()成功后会输出[midway:bootstrap] current app started并把全局标记MIDWAY_BOOTSTRAP_APP_READY置为true。调试时如果迟迟没有命中第一个断点先确认终端里是否出现了这行日志——它代表框架容器、主框架都已初始化完毕此时再发请求必然能走到业务代码。环境变量与端口Midway 会按NODE_ENV加载不同环境的配置local对应本地开发。调试时建议显式指定NODE_ENVlocal如 launch.json 模板中的env段并确认监听的端口与调试端口不冲突。进程信号的优雅关闭从Bootstrap.run()的源码可见它注册了SIGINT/SIGQUIT/SIGTERM信号处理收到信号后会执行stop()并打印close done, exiting with code:0。调试中按Ctrl C结束应用是安全的属于受控退出。小结针对 Midway 应用的本地调试本文覆盖了三类常用操作VSCode零配置的 JavaScript Debug Terminal、点选式的 Debug Scripts 按钮以及可固化共享的.vscode/launch.json详见 docs/debugger.mdJetBrainsWebStorm/IDEA在package.json的scripts上直接点击 Debug 按钮或显式创建 npm 运行配置底层认知结合 packages/bootstrap/src/bootstrap.ts 的启动流程与示例项目 samples/functional-api-hybrid/package.json 的 scripts理解「调试进程 → 断点命中」的完整链路。三种方式本质都是「让调试器托管 Node 进程」区别只在于配置方式与适用场景临时调试用 JavaScript Debug Terminal习惯鼠标操作用 Debug Scripts 按钮团队协作或需要固定参数端口、环境变量时则用 launch.json。掌握其中任意一种即可告别日志打点式的排障进入断点级排查的调试模式。赞分享后端微服务云原生【免费下载链接】midway A Node.js Serverless Framework for front-end/full-stack developers. Build the application for next decade. Works on AWS, Alibaba Cloud, Tencent Cloud and traditional VM/Container. Super easy integrate with React and Vue. 项目地址https://gitcode.com/gh_mirrors/mi/midway点击查看免费下载相关推荐Midway Hooks 本地调试完全指南VSCode 与 JetBrains 全家桶断点调试实战Midway Hooks 本地调试完全指南VSCode 与 JetBrains 全家桶断点调试实战 本文聚焦 Midway Hooks一体化全栈方案应用在后端微服务云原生Midway 项目调试全指南在 VSCode 与 WebStorm 中配置断点调试Midway 项目调试全指南在 VSCode 与 WebStorm 中配置断点调试 本指南面向使用 Midway midwayjs/koa 等 Web 框后端微服务云原生IDE重置工具3步解决JetBrains全家桶试用期问题IDE重置工具3步解决JetBrains全家桶试用期问题 你是否曾经为JetBrains IDE的30天试用期到期而烦恼当IntelliJ IDEA、PyC开发工具上一篇WechatDecrypt终极指南如何快速解密微信聊天记录数据库下一篇Hitboxer终极指南5大核心功能彻底解决游戏键盘输入冲突问题创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考