docker update 不支持修改启动命令，因其仅允许调整资源限制、重启策略和网络设置，而 entrypoint 和 cmd 在容器创建后已固化于 config.v2.json 中且 daemon 不支持运行时覆盖。
docker run 本身就能指定启动命令，但如果你已经有一个正在运行或已停止的容器，想改它的启动命令，docker update 不行，docker exec 也不行——它只影响下次启动行为，而 Docker Desktop（macOS）底层容器配置是只读的，必须手动编辑 JSON 文件才能生效。
为什么不能用 docker update 改启动命令
docker update 只支持调整资源限制（--memory、--cpus）、重启策略（--restart）和网络设置，**完全不支持修改 Entrypoint 或 Cmd**。你执行 docker update --entrypoint /bin/sh mycontainer 会直接报错：Error response from daemon: Cannot update container with entrypoint。
根本原因在于：容器创建后，其启动指令已固化在 config.v2.json 的 Config.Entrypoint 和 Config.Cmd 字段中，Docker daemon 启动时只读取、不校验也不允许运行时覆盖。
Mac 上改容器启动命令：进 Linux VM 找 config.v2.json
Docker Desktop 在 macOS 上实际运行在一个轻量级 Linux 虚拟机（docker-desktop VM）里，所有容器配置都存在这个 VM 的文件系统中，不在宿主机本地路径下。
操作流程如下：
- 先停掉目标容器：
docker stop mycontainer - 进入 VM：
screen ~/Library/Containers/com.docker.docker/Data/vms/0/tty（按 Ctrl+A, 再按 D 退出 screen；输入exit退出 VM） - 在 VM 中定位容器配置：
cd /var/lib/docker/containers/→ 找到对应容器 ID 的子目录（可用ls -t | head -n5看最新几个）→ 进入该目录 - 备份原始配置：
cp config.v2.json config.v2.json.bak - 用
vi或sed编辑config.v2.json，修改以下字段（注意 JSON 格式严格）：-
"Entrypoint": ["/bin/sh", "-c"]→ 改成你想要的数组形式 -
"Cmd": ["sleep", "3600"]→ 可替换成["/bin/bash"]或空数组[]（表示继承镜像默认）
-
- 保存后，**必须重启 Docker Desktop**（不是
docker restart），否则 daemon 不会重新加载配置
⚠️ 容易踩的坑：Entrypoint 和 Cmd 都是字符串数组，不能写成单个字符串；改完后如果 daemon 启动失败，大概率是 JSON 语法错误，可回退 .bak 文件再试。
改完不生效？检查 hostconfig.json 是否锁死入口逻辑
有些镜像（比如官方 redis、nginx）会在 hostconfig.json 里硬编码 RestartPolicy 或把 Cmd 塞进 Ulimits 以外的字段，导致即使改了 config.v2.json，启动时仍被覆盖。
更稳妥的做法是同时检查并同步修改 hostconfig.json 中的：
-
"RestartPolicy": {"Name": "no"}→ 如果你不希望它自动重启干扰调试，设为"no" -
"Binds"和"PortBindings"不影响启动命令，但若你顺手调了端口，这里也要对齐，否则容器起来后端口映射失效
修改完两个 JSON 文件后，建议用 jq '.' config.v2.json | head -20 快速验证格式，避免因少一个逗号或引号导致 daemon 卡死。
真正省事的替代方案：用 docker commit + docker run 重建
如果你只是临时调试（比如想进容器看文件、绕过健康检查脚本），其实没必要硬改配置——docker commit 把当前状态打成新镜像，再用 docker run -it --entrypoint /bin/bash 新镜像名 启动，比进 VM 改 JSON 快得多，也安全得多。
适用场景：
- 容器没挂重要 volume，或者 volume 是只读挂载
- 你只需要一次性的 shell 访问，不追求“永久改掉原容器行为”
- 你不确定改 JSON 后会不会影响后续
docker logs或docker stats的兼容性
复杂点在于：如果容器依赖特定 hostname、network alias 或 init 进程，commit 后的新容器默认不继承这些——这时候，还是得回到 VM 改配置，别图省事。
