生产环境 Docker 容器启动必须强制配置核心参数：--memory 与 --memory-swap 限内存防 OOM，--cpus 控制 CPU 配额，--restart=unless-stopped 实现自动恢复，--network=host 或自定义 bridge 优化网络，--read-only + --tmpfs 提升安全与 I/O 效率；环境配置须运行时注入，健康检查与优雅关闭不可省略，推荐用 docker-compose 统一管理。
启动 docker 容器不只是执行 docker run 那么简单。真正影响线上稳定性、资源利用率和启动一致性的，是命令中那些看似可选、实则关键的参数配置。忽略它们，轻则容器反复重启、内存爆满，重则服务不可达、日志无法采集。
核心启动参数必须明确指定
不加限制的容器就像没上锁的车——谁都能开，也容易失控。以下参数建议在生产环境强制使用：
-
--memory 和 --memory-swap：限制内存上限，防止 OOM 杀死主机进程。例如
--memory=1g --memory-swap=2g -
--cpus：控制 CPU 时间片配额，避免单个容器吃尽所有核。如
--cpus="1.5"表示最多占用 1.5 个逻辑 CPU -
--restart=unless-stopped：确保容器异常退出后自动恢复，但允许运维主动停止（区别于
always） -
--network=host 或自定义 bridge 网络：避免默认 bridge 的 NAT 开销；若需高性能网络直通，
--network=host可降低延迟（注意端口冲突） -
--read-only + --tmpfs：对不需要写盘的应用启用只读根文件系统，再用 tmpfs 挂载必要临时目录（如
/run、/tmp），提升安全性与 I/O 效率
环境与配置分离：用 -e、--env-file 和 -v 精准注入
硬编码在镜像里的配置（比如数据库地址、密钥）会破坏镜像复用性。正确做法是运行时注入：
- 敏感变量走 --env-file：把
prod.env放在安全目录，通过docker run --env-file ./prod.env ...加载 - 非敏感配置用 -e 显式声明：如
-e TZ=Asia/Shanghai -e LOG_LEVEL=warn - 配置文件用 -v 挂载：将宿主机上的
/etc/myapp/config.yaml映射进容器/app/config.yaml，便于独立更新 - 避免
COPY config.yaml /app/进镜像——每次改配置都得重建镜像，违背“一次构建，随处运行”原则
健康检查与优雅关闭不可省略
容器是否“真正在工作”，不能只看进程是否存在。Docker 提供原生机制验证业务就绪与安全退出：
-
--health-cmd：定义探测逻辑，例如
--health-cmd="curl -f http://localhost:8080/health || exit 1" -
--health-interval 和 --health-timeout：建议设为
30s和5s，避免过频或过长阻塞 -
--stop-timeout：给应用留出清理时间，默认 10 秒太短。Spring Boot 应用建议设为
60，让 JVM 完成 shutdown hook - 容器内主进程需能响应
SIGTERM：Node.js 用process.on('SIGTERM', ...)，Java 启动加-XX:+UseContainerSupport自动适配 cgroup 限额
结合 docker-compose 实现可复现的高性能部署
单条 docker run 命令难以维护复杂服务拓扑。用 docker-compose.yml 统一声明，既清晰又利于 CI/CD：
- 定义
deploy.resources控制 CPU/memory 限额（Swarm 模式下生效） - 用
healthcheck块替代命令行参数，支持更细粒度配置 -
volumes中显式声明命名卷，避免路径依赖；对日志类数据启用driver: local+o=bind直接挂载宿主机目录 - 添加
init: true：自动注入轻量 init 进程（如tini），正确转发信号、回收僵尸进程
不复杂但容易忽略
