Docker不支持直接修改运行中容器的端口映射；Windows/macOS需进入WSL2或HyperKit VM才能访问hostconfig.json，且易因JSON错误或未重启Docker Desktop导致失败；推荐docker commit+run或docker-compose重定义端口，并确保服务监听0.0.0.0。
不能直接修改运行中容器的端口映射 —— Docker 引擎本身不支持 docker update 或类似命令来变更已创建容器的 -p 映射规则。所有“热改端口”的操作，本质都是绕过 Docker API 的底层文件编辑或状态迁移，风险与平台强相关。
Windows / macOS 上改 hostconfig.json 为什么常失败
在 Windows Docker Desktop（WSL2 后端）或 macOS Docker Desktop（HyperKit VM）中，/var/lib/docker/containers/{container_id}/ 这个路径并不存在于宿主机文件系统里，而是藏在 WSL2 发行版或 macOS 虚拟机内部。直接在 Windows PowerShell 或 macOS Terminal 里执行 cd /var/lib/docker/containers 会提示目录不存在。
- Windows：需先进入 WSL2 环境，再定位到
docker-desktop-data发行版的容器配置目录，路径类似/mnt/wsl/docker-desktop-data/data/docker/containers/{container_id}/ - macOS：需通过
screen ~/Library/Containers/com.docker.docker/Data/vms/0/tty进入 HyperKit VM，或使用docker run -it --privileged --pid=host debian nsenter -t 1 -m -u -n -i sh挂载宿主命名空间（极不稳定） - 即使路径找对，修改后必须完整重启 Docker Desktop（不只是
systemctl restart docker），否则守护进程仍按内存缓存加载旧配置 -
hostconfig.json中的PortBindings格式极易因 JSON 语法错误（如末尾多逗号、引号不匹配）导致容器无法启动
docker commit + docker run -p 是最稳的通用方案
适用于所有平台，不依赖底层存储结构，且能保留容器内所有文件系统变更和运行时状态（如数据库数据、临时文件、已安装的包）。
- 先停止原容器：
docker stop my-app - 提交为新镜像：
docker commit my-app my-app:v2 - 用新镜像启动并指定新端口：
docker run -d -p 8081:80 --name my-app-new my-app:v2 - 验证无误后，再删旧容器：
docker rm my-app - 注意：如果原容器用了
--restart=always，新容器需显式加上；挂载的卷（-v）也要一并复用，否则数据会丢失
Mac / Windows 下用 docker-compose.yml 重定义端口更可持续
如果你原本就是用 docker-compose up 启动的容器，这才是应有姿势——端口不是写死在容器里，而是声明在编排文件中，修改即生效。
- 找到对应的
docker-compose.yml，修改ports字段，例如把- "3000:3000"改成- "3001:3000" - 执行
docker-compose down && docker-compose up -d（down会删容器但保留卷和网络） - 若不想中断服务，可加
--no-deps和--force-recreate控制重建粒度 - 该方式天然规避了手动改 JSON 的风险，也方便版本管理、CI/CD 集成
真正容易被忽略的是：**端口映射只是入口，容器内服务是否监听 0.0.0.0 而非 127.0.0.1，决定了映射是否生效**。比如 Node.js 默认 app.listen(3000) 只绑本地回环，必须改成 app.listen(3000, '0.0.0.0')；Nginx 配置里 listen 80; 默认也是只监听 localhost，要写成 listen *:80;。这类问题常被误判为“端口没改成功”，其实改对了，只是服务根本没对外暴露。
