应禁用已弃用的 debugger for chrome 插件，保留 vscode 内置 javascript debugger；若必须共存，则需手动修改 chrome 插件端口（如 9230）并在 launch 模式下通过 runtimeargs 设置 --inspect=9230。
Debugger for Chrome 和 JavaScript Debugger 插件共存会抢 9229 端口
VSCode 默认的 Node.js 调试器（JavaScript Debugger）和旧版 Debugger for Chrome 插件默认都监听 9229 端口。两者同时启用时，后启动的那个会报 EADDRINUSE，但错误提示往往只说“端口被占用”，不指明是哪个插件在占——实际是它们自己在打架。
常见现象：
• 启动 Node 调试会话失败，控制台显示 Unable to attach to process: connect ECONNREFUSED 127.0.0.1:9229
• 切换到 Chrome 调试配置时，Node 调试突然失效，反之亦然
• lsof -ni :9229 查到 PID 对应进程名是 Code Helper 或 Electron，而非外部 node 进程
- 根本原因不是系统服务占端口，而是 VSCode 内部两个调试扩展注册了同一 V8 inspect 端口
-
Debugger for Chrome已被官方标记为“deprecated”，JavaScript Debugger是内置替代品（VSCode 1.47+ 默认启用） - 禁用其中一个即可：推荐保留内置的
JavaScript Debugger，卸载Debugger for Chrome - 如果必须保留 Chrome 插件（比如依赖其旧版 DevTools UI），则需手动改它的端口：在 VSCode 设置里搜
debug.javascript.chrome.port，设为9230或其他空闲值
launch.json 的 port 字段只管 attach 模式，不管 launch 模式
很多人在 .vscode/launch.json 里把 "port" 改成 9230，结果还是报 9229 占用——因为这个字段仅在 "request": "attach" 时生效；而 "request": "launch"（即直接运行 Node 脚本）默认仍走 --inspect 的自动分配逻辑，除非你显式加 "runtimeArgs"。
正确写法示例（launch 模式下强制指定 inspect 端口）：
{
"type": "node",
"request": "launch",
"name": "Launch with custom inspect port",
"program": "${file}",
"runtimeArgs": ["--inspect=9230"],
"console": "integratedTerminal"
}
-
"port"字段对launch模式无效，纯属误导性配置项 -
--inspect=9230必须写进runtimeArgs，且不能带空格（--inspect =9230会失败） - 若项目用
nodemon，还需额外加--exec node --inspect=9230，否则 nodemon 自己起的子进程仍用默认 9229 - 改完必须重启整个调试会话，已挂起的
attach进程不会自动迁移端口
多个工作区同时调试时，端口冲突其实来自同一个 Extension Host
你以为开了两个 VSCode 窗口、两个项目，就该有两套独立调试环境？错。只要它们共享同一个 Extension Host 进程（比如都从同一个 VSCode 实例拖入文件夹），JavaScript Debugger 就只启动一个 V8 inspector 服务，所有 launch 或 attach 请求都排队打向这一个端口。
Java开发手册规约集合，基于阿里巴巴Java开发手册（嵩山版）。 涵盖7大维度：编程规约、异常日志、单元测试、安全规约、MySQL数据库、工程结构、设计规约。 当用户需要：(1) 编写或审查Java代码 (2) 检查命名/代码规范 (3) 处理异常和日志 (4) 编写单元测试 (5) 安全编码 (6) 数据库设...
典型表现：
• A 工作区调试正常，B 工作区一启动就报 9229 占用
• lsof -ni :9229 查到 PID 对应的是 Code Helper，不是 node
• 关掉 A 的调试会话，B 就立刻能连上
- 这不是 bug，是 VSCode 架构设计：Extension Host 是单例，调试服务也是单例
- 解决方法只有两个：要么串行调试（A 停了再开 B），要么拆成独立 VSCode 实例（用
code --new-window --disable-extensions单独开） - 别指望靠改
launch.json让两个工作区“各用各的端口”——JavaScript Debugger不支持多实例并发 inspect 服务 - 如果真要并行，得用
attach模式 + 外部node --inspect-brk=9230启动，让每个项目自己起独立 V8 实例
Chrome 调试器残留的 WebSocket 连接会锁住端口
哪怕你关掉了所有调试面板、停了所有会话，Debugger for Chrome 插件有时会在后台维持一个未关闭的 WebSocket 连接，导致 9229 端口处于 TIME_WAIT 状态，新调试请求仍被拒。
验证方式：
• 在 VSCode 内置终端运行 lsof -ni :9229（macOS/Linux）或 Get-NetTCPConnection -LocalPort 9229（PowerShell）
• 如果输出中 STATE 是 TIME_WAIT 或 CLOSE_WAIT，说明连接没彻底释放
- 这不是进程没杀干净，是 TCP 连接状态残留，
kill或taskkill无效 - 临时解法：等 60 秒（Linux/macOS 默认
tcp_fin_timeout），或改系统参数（不推荐） - 根治办法：禁用
Debugger for Chrome，改用内置JavaScript Debugger—— 它对连接生命周期管理更严谨 - 如果必须用 Chrome 插件，每次调试完手动执行
Developer: Reload Window（Ctrl+Shift+P），强制重置 Extension Host 网络栈
真正容易被忽略的点是：端口冲突未必是“谁在占”，而是“谁不该监听”。JavaScript Debugger 和 Debugger for Chrome 的设计目标不同，却共享同一套底层 V8 inspect 接口；强行共存时，VSCode 不会报“插件冲突”，只会把问题转译成“端口被占用”——你查进程、杀 PID、改配置，全在解决表象。最省事的做法，是让其中一个彻底退出历史舞台。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
