根本原因是容器缺乏持续运行的前台主进程（PID 1），镜像本身未必有问题；需检查镜像版本一致性、退出码与日志、确保应用前台运行（如Java去&、Nginx加daemon off）、并排查JVM内存参数与容器限制冲突。
容器启动后立即退出，根本原因不是镜像“坏了”，而是容器运行时缺乏一个持续存活的前台主进程（pid 1）。镜像是静态的模板，容器是它的运行实例——镜像再完整，若启动命令没让进程常驻前台，容器就会执行完就收工。
确认镜像是否真被正确拉取和使用
别假设本地镜像就是最新版。私有仓库中 latest 标签可能已被覆盖，本地缓存的可能是旧版本：
- 执行 docker images | grep data-elements-business-node 查看本地是否存在且时间合理
- 用 docker pull image.onecode.cmict.cloud/data-delivery/data-elements-business-node:latest 强制更新
- 对比不同环境的镜像 ID：docker inspect <镜像名> | grep Id，ID 不一致说明版本不统一
检查容器退出码与日志，定位第一线索
退出码是诊断起点，不是状态描述，而是系统返回的“故障指纹”：
- docker logs <容器ID> —— 看是否有配置加载失败、连接超时、JVM 启动报错等输出
- docker inspect <容器ID> | grep -A 5 "State" —— 关注 ExitCode 和 FinishedAt，区分是主动退出（0）还是崩溃（1/127/137等）
- 若日志为空，大概率是 PID 1 进程连 stdout 都没来得及打开就失败了，比如二进制缺失、权限拒绝或 JVM 参数导致直接 abort
确保主进程以前台方式持续运行
Docker 容器不支持后台守护模式。任何把服务丢到后台（如加 &）、或依赖 systemd 的做法都会让 PID 1 提前结束：
- Java 应用避免写成 java -jar app.jar &，应去掉 &，或改用 exec java -jar app.jar（保证 PID 1 是 Java 进程）
- Nginx 要加 -g "daemon off;"，Redis 加 --daemonize no，Tomcat 用 catalina.sh run（不是 start）
- 调试时可用 tail -f /dev/null 或 sleep infinity 临时兜底，但生产环境必须换成真实服务进程
排查 JVM 相关典型陷阱
Java 类容器退出（尤其 Exit Code 137 或无日志闪退）常与 JVM 参数强相关：
- 内存参数过大（如 -Xmx4g）但容器限制仅 2G，触发 OOM Killer → 查 docker stats 和 dmesg | grep -i "killed process"
- 未适配容器内存：JDK 8u191+ 和 JDK 10+ 支持自动识别 cgroups 内存限制，老版本需显式加 -XX:+UseContainerSupport
- GC 参数激进或堆外内存泄漏，导致进程在初始化阶段就崩溃，日志来不及刷出
