Docker Run 转 Compose

为什么转换不是纯机械替换

docker run 命令和 Compose 服务描述的是同一个容器，但回答的问题不同：命令说的是"现在做什么"，文件说的是"这个服务运行时应当是什么状态"。绝大多数参数可以干净地映射过去，而映射不过去的那些，几乎都是在描述"运行这个动作"而不是容器本身。

最典型的是 detach。写 -d 是告诉守护进程不要占住你的终端，这是本次调用的属性，不是服务的属性。在 Compose 中同样的意图由命令行的 docker compose up -d 表达，所以这个参数会从文件里消失。--rm 同理：它要求本次运行结束后清理，Compose 的对应做法是用完执行 docker compose down。

交互类参数介于两者之间。-i 和 -t 确实有对应的 Compose 键 stdin_open 与 tty，因为"保持一个可连接的 shell"有可能是服务的真实属性，所以它们会被转换而不是丢弃——尽管多数长期运行的服务并不需要。

引号是转换出错的高发区

转换失败最常见的原因，是命令在粘贴之前就已经丢了 shell 引号。以健康检查为例：整条检测命令必须作为一个参数传入，所以在命令行里要用引号包起来。如果去掉引号再粘贴，这些词就变成了独立参数，镜像名会从错误的位置被读取，结果自然是错的。

本工具会按 shell 的规则分词，正确处理单引号、双引号、反斜杠转义以及反斜杠换行续行，因此直接从脚本里复制出来的命令能保持原有结构。输出时再按 YAML 规则重新加引号，这一点比多数人以为的更重要：像 8080:80 这样的端口映射在 YAML 中必须加引号，因为未加引号的冒号分隔值存在歧义，历史上有解析器会把 22:00 读成六十进制数字。

网络，以及文件无法得知的信息

网络是唯一一处即使忠实转换也仍需你来决策的地方。如果命令加入的是 host、none 或 bridge，那属于模式，会转成 network_mode；其他名称则指向一个已经存在的网络，于是服务会得到一条 networks 记录，并在文件中把该网络声明为 external。

这条声明是对你所处环境的陈述：它表示该网络由本文件之外的机制管理。如果你更希望由 Compose 创建并持有这个网络，删掉 external 让它正常定义即可。工具无法替你判断，因为原始命令只能证明"运行那一刻网络是存在的"。

绑定挂载同样需要谨慎。像 /srv/site 这样的路径只在写下命令的那台机器上成立。一旦服务定义进入会被提交和共享的文件，改用相对路径或具名卷通常是更好的选择。