docker exec不能直接热更新，因其仅启动新进程而非接管主进程生命周期；真正的热更新需依赖外部挂载+应用自身监听文件变更并主动重载。
docker exec 本身不支持热更新，也不能直接触发应用层的代码重载；它只是进入容器执行命令的通道。真正在容器内实现“修改即生效”，必须靠外部挂载 + 应用自身支持文件监听与热重载。
为什么 docker exec 不能直接热更新？
docker exec 启动的是新进程，不是容器主进程的子进程，更不接管其生命周期。你用它改了配置、替换了 .js 或 .class 文件，但原进程根本不会感知——除非该进程自己监听了文件系统事件并主动 reload。
- Node.js 的
nodemon、Python 的flask --debug、Java 的spring-boot-devtools都属于这类“自感知”机制 -
docker exec -it myapp sh进去手动杀进程再npm start，这不算热更新，是手动重启，会中断服务 - Java
.jar文件被替换后，JVM 不会自动加载新字节码；必须重启 JVM 进程
如何用 docker exec 辅助性能剖析？
前提是容器里已装好工具（如 curl、jq、top、jstack、pidstat），或你能在运行时动态注入（比如挂载调试工具目录）。
OpenClaw Docker Setup
下载
在 Linux 上通过 Docker 运行 OpenClaw，并使用 Tailscale 实现远程访问。⚠️ 涉及 sudo、Docker、Tailscale和凭证挂载——请先查阅安全章节...
- 查 CPU 占用：
docker exec myapp top -b -n1 | head -20 - 抓 Java 线程快照：
docker exec myapp jstack 1（假设 PID 1 是 Java 进程） - 调用健康检查端点：
docker exec myapp curl -s http://localhost:8080/actuator/prometheus | grep 'jvm_memory_bytes_used' - 注意：如果容器没装
curl或jstack，exec会报command not found；别指望临时apt-get install—— 多数生产镜像无包管理器或权限
真正可行的热更新路径：挂载 + 监听 + 重启策略
热更新不是靠 docker exec 完成的，而是靠启动时就设计好的文件同步机制和应用响应逻辑。
- 开发阶段：用
-v $(pwd):/app挂载源码，配合nodemon --watch /app src/index.js启动 - Java Spring Boot：挂载
-v ./target/classes:/app/classes，并启用spring.devtools.restart.enabled=true - 配置热更新：把
application.yml挂载为config类型（Docker Compose 中用configs或volumes），再由 Spring Cloud Config、Nacos 或应用内@RefreshScope主动拉取 - 危险操作警告：不要在
docker exec里用kill -HUP 1强制主进程 reload —— 大多数镜像未配置信号处理器，结果是进程退出
容易被忽略的关键点
挂载路径权限、用户 UID、文件系统 inotify 限制，三者不匹配就会导致监听失效。
- Linux 宿主机上编辑的文件，若容器内以非 root 用户运行（如
user: 1001），而挂载目录属主是 root，会导致 nodemon 权限拒绝监听 - Docker Desktop（macOS/Windows）默认用 gRPC-FUSE 挂载，
inotify事件可能延迟或丢失；需在 Docker Desktop 设置中开启Use the new Virtualization Framework并确认File sharing已包含项目路径 - Alpine 镜像缺
inotify-tools，nodemon会 fallback 到轮询（--legacy-watch），CPU 升高且响应变慢
