Docker容器无内置最大运行时间，但可通过运行超时（--timeout参数或ENTRYPOINT中嵌入timeout命令）限制主进程执行时长，以及停机超时（docker stop -t或stop_grace_period）延长SIGTERM后等待时间；二者适用场景不同，不可混用。
Docker 容器本身没有“最大运行时间”的内置概念，但可通过两种独立机制实现类似效果：限制容器主进程执行时长（运行超时） 和 延长容器停止前的优雅等待时间（停机超时）。二者解决不同问题，不能混用。
一、限制容器主进程最多运行多少秒（运行超时）
适用于一次性任务（如批处理、测试脚本），超过设定时间后整个容器被强制终止。
- 使用 docker run --timeout 参数（单位：秒），仅对 前台运行的主进程 生效
- 命令示例：
docker run --timeout 120 my-app→ 主进程运行满 120 秒即 kill - 注意：
--timeout是 Docker 20.10+ 引入的运行时参数，不写入镜像，只在run时指定 - 若需固化到镜像中，可在 Dockerfile 的
ENTRYPOINT或CMD中嵌入timeout命令（如["timeout", "120s", "npm", "start"]）
二、控制容器收到 stop 信号后最多等多久才强制结束（停机超时）
适用于长期服务（如 Web 服务器、数据库），确保有足够时间完成数据保存、连接关闭等清理动作。
- Docker 默认停机超时为 10 秒（发送 SIGTERM 后等待，超时发 SIGKILL）
- 临时调整：
docker stop -t 45 my-app→ 等 45 秒再强杀 - Docker Compose 中配置：
stop_grace_period: 60s写入服务定义，自动生效 - 关键前提：容器内主进程必须正确响应 SIGTERM 并主动退出；否则超时后仍会被 SIGKILL 终止
三、不推荐也不可靠的方式
不要试图在容器内用 date -s 修改系统时间来“倒计时”——这既无法触发自动终止，又因权限限制（默认无 CAP_SYS_TIME）多数情况下会失败。它改的是时间戳，不是运行生命周期。
真正可控的“最大运行时间”，始终由运行时参数或启动命令中的 timeout 逻辑决定，而非容器内部时间设置。
