不能——Dev Container 本质是单容器开发环境，devcontainer.json 默认只启动一个容器；需用 Docker Compose 编排多个微服务，通过 docker-compose.yml 定义各 service，并在 devcontainer.json 中指定 dockerComposeFile 路径。
Dev Container 能不能直接跑多个微服务？
不能——Dev Container 本质是单容器开发环境，devcontainer.json 默认只启动一个容器。想同时跑 auth-service、order-service 和 postgres，得靠 Docker Compose 编排，而不是靠单个 Dev Container 扛全部。
常见错误现象：Command failed: docker-compose up -d 报错找不到服务，或 VSCode 只连上了主容器，其他服务在后台静默失败。
- 必须把微服务拆成独立
service写进docker-compose.yml，再让devcontainer.json的dockerComposeFile指向它 -
devcontainer.json中的service字段只能指定一个入口服务（比如auth-service），VSCode 终端和调试器默认绑定它；其他服务需手动确认是否健康（docker-compose ps） - 端口冲突高发：多个服务都暴露
3000或8080，本地访问时会串；每个服务的ports必须显式映射到不同宿主机端口，如"3001:3000"
怎么让 VSCode 调试器连上非主服务？
VSCode 的 .vscode/launch.json 默认只 attach 到 devcontainer.json 指定的 service。要调试 order-service，得手动加配置，且容器内必须已运行调试器（如 Node.js 的 --inspect）。
使用场景：你在改 order-service 的支付回调逻辑，但当前 Dev Container 入口是 auth-service，断点打不进去。
- 确保
order-service容器启动时带调试参数，例如 Node.js 项目用node --inspect=0.0.0.0:9229 ./src/index.js - 在
.vscode/launch.json里新增一个configuration，type设为node，request设为attach，port填9229，address填order-service（Docker 内部服务名） - 别漏掉
skipFiles：微服务依赖多，不加["容易卡在底层模块里/**"]
为什么改了代码，服务没热更新？
Dev Container 不自动注入热重载能力——它只管容器启停和端口转发，文件监听、进程重启全靠你配的工具链（如 nodemon、ts-node-dev、Spring Boot DevTools）。
常见错误现象：保存 src/controllers/user.ts 后，curl http://localhost:3001/users 返回的还是旧响应。
- 检查容器内是否真在跑
nodemon：进容器执行ps aux | grep nodemon，不是只跑了npm start -
devcontainer.json的mounts或workspaceMount必须把本地代码目录挂载进容器，路径要和nodemon监听路径一致（比如挂载到/workspace，那nodemon --watch /workspace/src） - TypeScript 项目容易踩坑：如果用
ts-node-dev，得确认容器里装了typescript和@types/node，否则编译失败静默退出
Windows 用户挂载代码目录特别慢怎么办？
WSL2 + Docker Desktop 下，从 Windows 文件系统（C:\）挂载进容器，I/O 性能可能跌 5–10 倍，nodemon 监听延迟、tsc --watch 响应卡顿都是典型表现。
性能影响：一个中等规模的 NestJS 微服务，文件变更后重启常卡 3–6 秒，远超 macOS/Linux 的 300ms。
- 把代码放在 WSL2 原生路径下（如
/home/you/projects/order-service），再用workspaceMount挂载，速度立刻回归正常 - 如果必须用 Windows 路径，至少关掉
devcontainer.json里的runArgs中的--volume，改用mounts并加consistency: cached（仅 Docker Desktop for Windows 支持） - 别信“启用 WSL2 集成就万事大吉”——Docker Desktop 设置里还要手动勾选
Use the WSL2 based engine，且 WSL2 发行版需设为默认
最麻烦的其实是网络连通性：容器间用服务名互通没问题，但从宿主机 curl order-service:3000 肯定失败——因为那是 Docker 内网地址。真正该 curl 的永远是 localhost:3001 这种映射端口，这点极易忽略。
