vscode实现容器日志与构建产物“实时回传”的本质是挂载+流式订阅+文件系统可见性，而非主动拉取；需在devcontainer.json中显式配置mounts映射输出路径，并通过attach to running container建立websocket日志流，同时确保挂载路径为相对路径、权限匹配及资源管理器正确识别。
VSCode 本身不主动“回传”容器内的日志或构建产物，所谓“自动化实时回传”本质是配置好路径映射、日志流监听和文件同步机制后，让宿主机能自然看到容器里产生的 logs/ 或 dist/ 等输出——不是靠 VSCode 主动拉取，而是靠挂载 + 流式订阅 + 文件系统可见性实现的。
devcontainer.json 中必须配置 mounts 而非 copy
很多人误以为在 devcontainer.json 里用 postCreateCommand 把构建产物 cp 出来就算“回传”，其实这既不可靠（容器重启就丢失），也无法实时。真正可持续的方式是挂载宿主机目录到容器内输出路径。
-
"mounts"字段必须显式声明，例如："source": "${localWorkspaceFolder}/dist", "target": "/workspace/dist", "type": "bind" - 容器内构建命令（如
npm run build）必须输出到/workspace/dist这个挂载点，否则宿主机看不到 - 避免使用
copy或rsync手动同步：它们无法监听增量变化，且容易覆盖或遗漏 - Linux/macOS 下注意权限：挂载后容器内进程需有写权限（常见坑是 Node.js 构建时因 UID 不匹配报
EACCES）
日志实时可见的关键是 attach 而非 exec
执行 docker exec -it <container> tail -f /app/logs/app.log</container> 是临时行为，VSCode 关闭就断；要实现“打开编辑器即看到最新日志”，必须走 Remote - Containers 的 attach 流程，而非手动 exec。
- 确保
devcontainer.json中没有禁用日志输出的配置（如"shutdownAction": "none"但没配日志流） - 启动容器后，VSCode 终端默认连接的是容器 shell，此时运行
tail -f /app/logs/*.log属于“手动附加”，不持久也不可调试 - 正确做法：用 VSCode 命令面板执行
Containers: Attach to Running Container and Stream Logs，它会复用当前 dev container 的上下文并建立 WebSocket 日志流 - 该日志流自动继承
container.logFilters配置，支持正则高亮与静音，比终端tail更稳定
Build 输出目录需被 VSCode 工作区直接识别
即使 dist/ 已挂载成功，VSCode 默认也不会自动刷新资源管理器里的文件列表，导致你改完代码、构建完成，却看不到新生成的 JS/CSS 文件。
- 在项目根目录的
.vscode/settings.json中添加："files.watcherExclude": { "**/dist/**": true }—— 反直觉但必要：关闭对dist/的递归监听，避免海量文件触发性能抖动 - 启用
"files.autoSave": "afterDelay"，配合挂载路径，确保保存即触发构建，构建即落盘到宿主机 - 如果用 Webpack/Vite，其 dev server 默认监听
dist/目录变更并热更新，但前提是该目录在 VSCode 工作区中可见（即已挂载且未被files.exclude掩盖） - 检查
.gitignore是否意外屏蔽了dist/：VSCode 有时会尊重 .gitignore 导致资源管理器不显示
最常被忽略的一点：挂载路径的 source 必须是绝对路径或基于 ${localWorkspaceFolder} 的相对路径，任何硬编码的 /home/user/project/dist 在团队协作时必然失效；而日志流能否实时，取决于容器是否以 -t（分配伪 TTY）方式启动——Remote - Containers 默认满足，但手动 docker run 启动的容器往往缺这个 flag，导致 stdout 缓冲延迟数秒才刷出。
