Dev Containers 本身不提供热加载能力，仅运行 VSCode 在容器中；热加载需由 nodemon、webpack-dev-server 等工具在容器内监听文件变更实现，且须确保挂载配置支持 inotify 事件穿透。
Dev Containers 本身不提供代码热加载能力，它只负责把 VSCode 运行在容器里；热加载必须由项目框架或构建工具（如 nodemon、webpack-dev-server、skaffold dev）在容器内启动并监听文件变更——这点常被误认为是 Dev Containers 的功能。
devcontainer.json 里写 postAttachCommand 启动热加载服务，但别指望它自动重启
很多人以为只要在 devcontainer.json 里配了 "postAttachCommand": "npm run dev"，就能像本地一样改代码自动刷新。实际不是：VSCode 容器连接后只会执行一次该命令，如果进程崩溃或文件变更未触发重启，热加载就断了。
-
postAttachCommand是单次执行命令，适合初始化，不适合长期守护进程 - 真正要热加载，得让命令本身具备监听能力，比如
nodemon server.js或webpack serve --watch - 若用
npm run dev，需确认对应 script 是否已封装了热重载逻辑（查看package.json中dev字段） - 终端里手动运行
nodemon比依赖postAttachCommand更可控，便于查错
本地文件修改后，容器内没反应？检查挂载路径和文件系统事件转发
VSCode 默认把当前工作区挂载进容器，但某些场景下文件变更事件（inotify）无法穿透到容器内，导致 nodemon 或 webpack 不触发重建。
- macOS 和 Windows 上 Docker Desktop 默认使用 gRPC-FUSE 或 Hyper-V 文件共享，对 inotify 支持有限；Linux 主机表现最好
- 可在
devcontainer.json中加"runArgs": ["--privileged"]强制启用 inotify（仅限 Linux，且有安全风险） - 更稳妥的做法是：在容器内安装
inotify-tools并测试inotifywait -m -e modify,create /workspace是否能捕获变更 - 避免将
node_modules挂载进容器——它应由容器内npm install生成，否则权限/平台差异会导致热加载失败
想在 Kubernetes Pod 里热加载？skaffold dev 是目前最稳的链路
Dev Containers 跑在本地 Docker 里，而 skaffold dev 才是专为远程集群热加载设计的工具。两者常被混用，但职责完全不同。
-
skaffold dev会监听本地文件，自动 rebuild 镜像、push 到 registry、更新 K8s Deployment，整个流程绕过 Dev Containers - 若硬要在 Dev Containers 里连远程集群，需配置
kubectl凭据 +~/.kube/config挂载，并确保容器网络能访问 K8s API Server -
skaffold dev --port-forward可把 Pod 端口映射到本地，配合 Dev Containers 内的编辑器调试，形成“本地写 + 远程跑”混合模式 - 注意：K8s Pod 重启时，容器内进程状态丢失，热加载必须靠 Skaffold 触发新镜像部署，而非依赖容器内守护进程
真正难的不是配 devcontainer.json，而是厘清“谁在监听文件”“谁在触发重建”“谁在重启进程”——这三个角色经常被塞进同一个配置项里，结果出问题时全无头绪。
