node命令不直接解析--port等参数，需代码手动解析process.argv或读取process.env.PORT；推荐用环境变量PORT=4000 node server.js启动，并在代码中优先取env.PORT。
node 命令本身不接受 --port 参数
直接执行 node server.js --port 4000 不会把 --port 传给你的代码——Node.js 运行时会忽略这个参数，除非你手动解析 process.argv。绝大多数微服务框架（如 Fastify、Express）也不自动识别命令行端口参数，必须由你自己读取并传入监听逻辑。
- 常见错误现象：终端输出
Server running on http://localhost:3000，但你明明写了--port 4000，实际还是跑在 3000 - 正确做法是让服务代码主动读取环境变量或 argv，比如：
const port = parseInt(process.env.PORT) || parseInt(process.argv[2]) || 3000 - 更推荐用
process.env.PORT：启动时执行PORT=4000 node server.js（macOS/Linux）或set PORT=4000 && node server.js（Windows cmd）
Fastify 微服务怎么指定端口启动
fastify start CLI 支持 -p 或 --port，但仅限于 JS 入口；如果是 TypeScript 项目且用 fastify start -w src/index.ts，该参数会被忽略——因为 fastify start 默认不处理 .ts 文件的参数透传。
- JS 入口（如
src/index.js）：可直接用fastify start -p 4000 -w src/index.js - TypeScript 入口：改用
node --inspect=0.0.0.0:9229 -r ts-node/register/transpile-only src/index.ts，并在代码里读process.env.PORT - 务必确认
tsconfig.json中"sourceMap": true已开启，否则调试时断点无法映射到源码行
VSCode 终端里端口被占用怎么办
报错 Error: listen EADDRINUSE: address already in use :::3000 是典型端口冲突，但 VSCode 终端里杀进程比系统终端更隐蔽——它可能在后台挂着多个 node 进程没关干净。
- 先查：执行
lsof -i :3000（macOS/Linux）或netstat -ano | findstr :3000（Windows），记下 PID - 再杀：macOS/Linux 执行
kill -9 PID；Windows 执行taskkill /PID PID /F - 防复发：在
tasks.json的 task 配置中加"isBackground": true和"problemMatcher"，让 VSCode 识别服务已启动，避免重复运行 - 更稳妥：所有服务统一从
process.env.PORT读端口，并在.env文件里预设不同微服务的端口，比如AUTH_PORT=3001、API_PORT=3002
launch.json 调试时如何传入端口
VSCode 的 launch.json 不支持直接写 --port 4000 到 args 字段来影响监听行为——因为 args 是传给 Node.js 进程的，不是传给你的服务代码的。真正起作用的是 env 字段。
- 错误写法：
"args": ["--port", "4000"]→ Node.js 忽略，你的代码也收不到 - 正确写法：
"env": {"PORT": "4000"}，配合代码中process.env.PORT读取 - 多服务调试时，每个
configuration必须有独立env和port（调试器通信端口，如 9229、9230），别共用一个port字段 - 如果用了
fastify start启动，launch.json必须设"request": "attach"，不能用"launch"，否则热重载后调试会话断开
端口这事看着简单，但跨了三层：shell 环境变量传递、Node.js 进程参数解析、框架监听逻辑实现。漏掉任意一层，PORT=4000 就只是个字符串。
