VSCode本身不支持Kubernetes Pod内热重载，真正生效的是okteto up或skaffold dev启动的开发会话；Pod默认只读且无构建服务，需通过开发镜像替换、双向同步及容器内运行dev server才能实现保存即生效。
VSCode 本身不支持 Kubernetes Pod 内热重载，必须靠外部工具链协同实现；真正生效的不是编辑器，而是 okteto up 或 skaffold dev 启动的开发会话。
为什么直接在 Pod 里改代码不起作用
Pod 容器默认是只读文件系统（除非显式挂载 /workspace 或 /app），且没有运行构建服务或 HMR 代理。你用 VSCode 的 Remote-Containers 连上去后，保存文件只是写入容器磁盘——但没人监听、没人编译、没人触发 reload。常见错误现象包括：File saved but nothing happened、终端无 hot updated 日志、浏览器白屏或 502。
- 确认容器内是否运行了开发服务器（如
vite dev、npm run dev），而不是仅node app.js - 检查 Pod 是否以
securityContext.readOnlyRootFilesystem: false启动，否则okteto sync或skaffold file sync会静默失败 - 避免使用
live-server类插件——它只刷新页面，不注入模块，也不保留状态
okteto up 是当前最轻量的 Pod 级热重载方案
它不重建 Pod，而是用开发镜像替换原容器，并建立双向文件同步通道。关键在于 okteto.yaml 配置是否匹配你的语言栈：
- Go 项目需在
sync下声明./cmd/...和./internal/...，并确保容器内已安装dlv和go - Node.js 项目要指定
command为npm run dev（非npm start），且package.json中脚本必须启用--watch或--hot - 同步路径不能包含
node_modules或dist——这些应由容器内构建工具生成，而非从本地覆盖
执行 okteto up 后，VSCode 会自动连接到容器内终端，此时保存代码才真正触发热重载流程。
VSCode 2026 的 devcontainer-debug-proxy 能绕过端口映射做真热重载
如果你用的是 VSCode 2026 + Dev Container + Kubernetes，且目标 Pod 已注入 devcontainer-debug-proxy，那么断点和变量热重载可直接生效，无需 port-forward。前提是：
-
.devcontainer/devcontainer.json中启用了"debug.enableContainerKernelDebugging": true - Pod 的容器镜像已预装对应调试器（如 Go 项目含
dlv-dap，.NET 项目含vsdbg） - 源码挂载路径与
VSCODE_SOURCE_MOUNT值一致（默认/workspace），否则 sourcemap 映射失败，断点灰色不可命中
这个组合对调试时的变量热重载（eBPF 注入）有效，但对前端 UI 层的 HMR 仍依赖容器内 Vite/Webpack 实例——二者不互斥，可共存。
别忽略 skaffold dev 的静默 fallback 行为
当 skaffold.yaml 中定义了 sync 规则但未指定 autoSync，Skaffold 默认只同步文件变更，不触发 rebuild。你会看到文件已更新，但进程没重启。修复方式：
- 明确设置
sync: { auto: true }，或 - 在
build.artifacts中为每个 artifact 添加sync: [ "**/*.ts", "**/*.js" ]，否则 Skaffold 只监听 Dockerfile 变更 - Node.js 项目务必禁用
nodemon的--legacy-watch模式，它与 Skaffold 的 inotify 监听冲突，导致重复重启
复杂点在于：Okteto、Skaffold、Dev Container 三者同步机制底层不兼容。同一项目不要混用 okteto.yaml 和 skaffold.yaml，否则文件可能被多次覆盖或丢失时间戳。
