断点不触发是因为SIGTERM未被正确捕获或进程过早退出；需用pwa-node调试器、禁用信号拦截、确保SIGTERM监听在server.listen后注册，并在回调中使用debugger语句。
断点不触发？大概率是服务还没真正“停住”，而是被 SIGTERM 杀掉前就退出了——优雅停机本身会干扰调试流程，必须绕开或重写信号处理逻辑。
为什么 process.on('SIGTERM') 会让断点失效
VSCode 调试器依赖 Node 的 V8 Inspector 协议，而 process.exit() 或未 await 的异步清理（如数据库连接关闭）会直接终止进程，导致断点根本没机会命中。Koa/Express 项目常在 server.close() 后立刻调用 process.exit(0)，调试器来不及响应。
- 现象：你在
gracefulShutdown()函数第一行打了断点，F5 启动后发SIGTERM（kill -15 $(pidof node)），但断点完全不触发，终端只显示 “Received SIGTERM” 就退出 - 原因：Node 默认对
SIGTERM是“立即退出”，除非你显式监听并阻止默认行为；且 VSCode 的 attach 模式下，信号可能被调试器拦截或丢失 - 关键点：
process.on('SIGTERM', ...)必须在server.listen()之后注册，且不能在回调里直接process.exit()
launch.json 中禁用自动信号拦截
VSCode 默认会在调试时屏蔽部分系统信号，导致你手动发 SIGTERM 无法到达你的监听函数。需显式允许：
- 不要用
"type": "node"，改用"type": "pwa-node"（VSCode 1.80+ 推荐） - 在
launch.json的配置中添加："env": {"NODE_OPTIONS": "--inspect-brk"}，并移除所有runtimeArgs中的--signal相关参数 - 避免使用
"console": "integratedTerminal"，改用"console": "externalTerminal"，否则终端信号可能被 VSCode 拦截 - 示例片段：
{ "type": "pwa-node", "request": "launch", "name": "Debug with graceful shutdown", "program": "${workspaceFolder}/src/server.js", "console": "externalTerminal", "env": { "NODE_OPTIONS": "--inspect-brk" } }
调试时临时替换优雅停机逻辑
生产代码里的停机逻辑往往耦合数据库、Redis、消息队列等，调试时没必要跑全链路。直接注释或 mock 掉耗时操作，聚焦信号接收和服务器关闭流程：
- 把
db.close()、redis.quit()等替换成await new Promise(r => setTimeout(r, 100)) - 确保
server.close()调用后加await，否则后续process.exit()可能提前执行 - 在
process.on('SIGTERM', async () => {回调开头加debugger;，比行号断点更可靠（V8 Inspector 保证命中断点） - 测试命令别用
kill -15，改用curl -X POST http://localhost:3000/shutdown（加个内部 shutdown 路由，绕过信号机制）
attach 模式下验证信号是否送达
如果坚持用 attach 模式（比如配合 nodemon --inspect-brk），信号可能被 nodemon 层吃掉。需确认信号真传到了你的 Node 进程：
- 启动时加日志：
console.log('PID:', process.pid)，然后kill -15 <pid></pid> - 在信号监听函数里加
console.log('SIGTERM received, starting shutdown...')—— 如果这句没输出，说明信号没到进程，检查是否被 nodemon 或 shell wrapper 拦截 - Windows 下
SIGTERM不可用，必须改用SIGINT（Ctrl+C），且launch.json中要设"windows": {"runtimeArgs": ["--inspect-brk"]} - macOS/Linux 下，若用 zsh，确保没启用
IGNOREEOF或其他信号屏蔽设置
优雅停机调试最易忽略的点：你写的 shutdown 逻辑本身没问题，但调试器根本没机会执行它——信号被拦截、进程被强杀、或异步 cleanup 没 await 导致 process.exit() 提前跑完。先让 debugger 在信号回调里停下来，再一层层往里查异步链，比盯着 server.close() 的返回值有用得多。
