先关VSCode再查端口，若localhost:3000释放则大概率是插件占用；更准方法是启动后用lsof -i :3000（macOS/Linux）或Get-NetTCPConnection -LocalPort 3000（PowerShell）定位PID，再结合ps/tasklist及命令行参数确认具体插件进程。
怎么看 VSCode 插件有没有偷偷占着 localhost:3000 这类端口
VSCode 本身不直接监听本地开发端口，但某些插件（比如 Live Server、Debugger for Chrome、Remote - SSH 的代理组件、甚至某些 LSP 服务）会启动子进程并绑定端口。最直接的判断方式是：关掉 VSCode，再运行 lsof -i :3000（macOS/Linux）或 netstat -ano | findstr :3000（Windows），如果端口空了，那大概率就是它干的。
更准的做法是启动 VSCode 后立刻执行端口检查，然后逐个禁用可疑插件再重试——别依赖“插件列表里没写端口”就排除，比如 ms-python.python 在启用 Jupyter 支持时可能拉起 node 进程占 8888，esbenp.prettier-vscode 一般不占端口，但搭配某些格式化后端（如 prettierd）就可能开 9999。
Live Server 插件默认占哪些端口、怎么改
ritwickdey.LiveServer 默认启动时随机选一个可用端口，但你可以在工作区设置里固定它，并避免冲突：
- 在
.vscode/settings.json中加："liveServer.settings.port": 5500
- 设成
0会恢复自动分配（不推荐用于排查） - 它还会顺带起一个 WebSocket 服务，默认比 HTTP 端口大 1，比如 HTTP 用
5500，WS 就是5501；这个不能单独配置，得一起改 - 如果你看到
EADDRINUSE错误，不是插件 bug，而是端口真被占了——先查lsof -i :5500或Get-NetTCPConnection -LocalPort 5500（PowerShell）
用 ps 或任务管理器定位到具体是哪个插件进程
VSCode 插件多数跑在独立的 node 或 python 子进程里，不是统一的“VSCode 进程”。所以光看主进程 PID 没用。
macOS/Linux 下可以这样链式排查：
ps aux | grep node | grep -v "main.js" | grep -v "extensionHost"
然后对疑似进程用 lsof -p 看它开了哪些端口；Windows 下可在任务管理器“详细信息”页右键列标题 → “选择列” → 勾上“命令行”，再找含 --inspect、--port=、jupyter 或插件 ID 字样的进程。
注意：有些插件（如 ms-vscode-remote.remote-ssh）会通过 sshd 或临时 node 代理转发端口，它们绑定的可能是 127.0.0.1:40000+ 范围的高编号端口，别只盯着常见开发端口。
插件端口冲突导致调试失败的典型表现
不是所有端口占用都会报错。常见静默故障包括：
- Chrome 调试器连不上
localhost:9229，但chrome://inspect里看不到目标 —— 可能是另一个插件（如msjsdiag.debugger-for-chrome的旧版残留）占了该端口 - 前端项目
yarn start报listen EADDRINUSE: address already in use :::3000，但终端里没看到其他node进程 —— 很可能 VSCode 的某个插件（比如某版Wallaby.js）已提前 bind 了 - Remote-SSH 连接后，本地
localhost:8080访问不了，其实是插件把远端8080映射到了本地，且没释放 —— 查code --status输出里的 “Forwarded ports” 部分
真正麻烦的是那些启动后不常驻、只在触发动作（如保存、hover）时才拉起短命进程的插件，它们的端口占用转瞬即逝，得用 lsof -i -sTCP:LISTEN -r 1（持续刷新）才能抓到。
