健壮的docker前置检查脚本需精准验证依赖可达性（如数据库轻量查询、http状态+响应体）、配置合法性（语法+必填字段+环境变量）、本地资源（路径可写、磁盘余量、uid/gid），统一退出码与带标识日志。
编写健壮的 docker 容器启动前置检查脚本，核心是让容器在依赖就绪、配置合法、资源可用后再真正启动主进程，避免“启动即失败”或“假启动真挂起”。关键不在于写得多复杂，而在于检查项精准、失败可感知、重试有节制、退出语义明确。
检查依赖服务是否可达（非仅端口通）
只用 nc -z host port 或 curl -f http://host:port/health 很容易误判。真实场景中，数据库端口通了但用户权限未授权、Redis 密码错误、HTTP 服务返回 503，都应视为不可用。
- 对数据库：用客户端工具执行轻量查询，如
mysql -h db -u user -ppass -e "SELECT 1" &>/dev/null，捕获非零退出码 - 对 HTTP 服务：检查响应状态码 且 关键响应体字段，例如
curl -sf http://api/ready | jq -e '.status == "ok"' &>/dev/null - 避免无限等待：每个检查加超时（
timeout 10s），整体重试控制在 3–5 次，间隔 2–5 秒
验证配置文件语法与必要字段
容器常通过挂载或环境变量注入配置。启动前应校验，而非等主进程加载时报错退出，导致健康检查反复失败。
- YAML/JSON 配置：用
yq或jq --dry-run检查格式；再用jq -e '.database.host and .database.port' config.json确保必填字段存在 - 环境变量：用
[ -n "$DB_HOST" ] || { echo "DB_HOST missing"; exit 1; }显式报错，不依赖主程序兜底 - 敏感配置（如密钥）存在性检查后，建议立即
unset对应变量，降低泄露风险
确认本地资源与权限满足运行要求
容器内路径、磁盘空间、UID/GID 映射等问题常被忽略，直到日志里出现 Permission denied 或 No space left on device 才暴露。
- 目录可写检查：
mkdir -p /data && touch /data/.test-write && rm /data/.test-write，失败则exit 1 - 磁盘余量检查：
df --output=pcent /data | tail -1 | tr -d ' %' | awk '$1 > 95 {exit 1}' - 若应用需特定 UID 运行（如非 root），检查
id -u是否匹配，并提前chown -R $APP_UID:$APP_GID /app/data
统一退出码与日志输出规范
Docker 依赖容器主进程退出码判断状态。前置检查脚本必须用明确退出码，并把关键信息输出到 stdout/stderr，方便 docker logs 排查。
- 成功：退出码
0，输出✅ All pre-start checks passed - 临时性失败（如依赖暂未就绪）：退出码
124（timeout标准码）或125（Docker 保留），便于编排工具识别可重试 - 永久性失败（如配置错误、权限不足）：退出码
1，并带具体原因，例如❌ Failed to write to /data: Permission denied - 所有日志行以时间戳或阶段标识开头，例如
[check-config] Validating config.json...
不复杂但容易忽略——健壮不是追求面面俱到，而是聚焦“不启动比启动错更好”，用最小代价守住最关键的几道门。
