CMD无法有效管理多进程容器中的长期服务，因其仅支持单命令启动、缺乏进程监控/重启/信号转发能力，且PID 1无init功能，易致僵尸进程、信号丢失和静默崩溃。
CMD 指令在多进程容器中无法有效管理多个长期运行的服务。Docker 的设计哲学是“一个容器一个主进程”，而 CMD 仅能指定一个默认启动命令（或作为 ENTRYPOINT 的参数），它本身不提供进程监控、重启、日志聚合或依赖协调能力。当容器内需同时运行 Web 服务、定时任务、日志收集器等多进程时，单纯依赖 CMD 会导致子进程脱离生命周期管控，极易出现静默崩溃、僵尸进程堆积、信号转发失败等问题。
CMD 启动的进程是容器 PID 1，但缺乏 init 功能
Docker 容器启动后，CMD 执行的命令成为 PID 1 进程。Linux 内核要求 PID 1 必须能正确处理孤儿进程和信号（如 SIGTERM）。然而，大多数 Shell 命令（如 bash -c "nginx & php-fpm"）或简单二进制（如 nginx）并不具备 init 行为：
- 无法回收僵尸子进程，长时间运行后可能耗尽 PID 资源
- 接收到终止信号时，通常只结束自身，不会向子进程传递 SIGTERM 或 SIGINT
- 若主进程意外退出，整个容器立即停止，其余后台进程被强制杀死，无优雅关闭机会
Shell 形式 CMD 会启动额外的 shell 层，加剧信号与 PID 管理问题
使用 CMD ["sh", "-c", "cmd1 & cmd2 & wait"] 看似能并发启动多进程，但存在明显缺陷：
- sh 进程成为 PID 1，但其内置 wait 仅等待直接子进程，无法感知孙子进程（如 cmd1 启动的子服务）
- Ctrl+C 或 docker stop 发送的 SIGTERM 默认只发给 sh，不会自动传播到后台作业
- 一旦某个后台命令出错退出，sh 不会自动终止其他进程，也无法触发重试或告警
替代方案应聚焦进程托管与信号代理
要可靠支撑多进程场景，需用专业进程管理工具替代裸 CMD：
- 采用 supervisord：轻量、配置驱动，支持进程启停顺序、自动重启、stdout/stderr 统一捕获，且能将信号转发给所有托管进程
- 使用 tini（Tiny Init）作为 PID 1：解决僵尸进程回收问题，再配合 exec 启动真正的进程管理器（如 exec tini -- supervisord -c /etc/supervisord.conf）
- 改用更现代的方案如 s6-overlay 或 runit：提供服务依赖、健康检查、环境变量注入等增强能力
- 重构架构：优先考虑拆分为多个单进程容器，通过 Docker Compose 或编排平台协同，符合云原生最佳实践
