不能在Init Container中运行composer install，因其违背容器不可变性原则，导致网络未就绪、权限不足、凭据泄露、镜像膨胀、重复执行及依赖不一致等问题；正确做法是在Docker构建阶段通过多阶段构建固化vendor目录。
不能用 Init Container 运行 composer install ——这不是“预加载”，是反模式。
为什么 Init Container 里跑 composer install 必然失败
常见现象：Pod 卡在 Init:0/1 或反复 CrashLoopBackOff，日志里出现 Connection refused、Could not fetch packages、failed to open stream: php_network_getaddresses。
- Init Container 启动时，
CoreDNS可能还没就绪，nslookup packagist.org直接失败 - 即使网络通了，
composer install需要写vendor/、生成autoload.php、读取auth.json——但 Init Container 和主容器默认不共享可写卷（除非显式挂载），且权限常被限制 - 私有仓库凭据若通过
env注入，会在kubectl describe pod中明文可见；若挂载Secret，Init Container 镜像又得包含composer+ 凭据处理逻辑，镜像膨胀且维护成本高 - 每次 Pod 重启都重跑一遍，既慢（几十秒起步）又不可控——
composer.lock若没提交，不同节点可能装出不同版本
真正该用 Init Container 做什么（PHP 场景）
Init Container 的合理用途，是补足构建期做不到、但运行前必须完成的**环境适配类任务**，和 composer 无关：
-
等待下游服务就绪：比如用
busybox轮询nslookup mysql或nc -z db 3306，确保数据库 Service 已发布、Endpoint 有 backing Pods -
注入动态配置：从
ConfigMap或Secret拷贝php.ini片段到共享emptyDir卷，再由主容器挂载覆盖默认配置 -
解密或转换凭证：调用
aws cli或gcloud auth获取短期 token，写入/app/.env（主容器只读挂载该文件） -
迁移前校验：执行
php artisan schema:has-table users（Laravel）或简单 SQLSELECT 1，确认 DB 连通且 schema 存在，失败则阻断启动
Docker 构建阶段才是 composer 的唯一合法位置
所有 vendor/ 内容必须在 docker build 时固化进镜像层，而非 K8s 运行时生成：
- 使用多阶段构建：第一阶段用
composer/composer:2-bin执行composer install --no-dev --no-scripts --prefer-dist，第二阶段用php:8.2-fpm复制vendor/和代码 -
composer.lock必须提交到 Git——没有它，composer install在不同环境会解析出不同依赖树 - 避免在生产镜像中保留
composer.json和composer.lock：它们只是构建输入，不是运行时所需 - 若需热更新配置（如
.env），应通过ConfigMap挂载，而不是让 Init Container 动态生成
容易被忽略的细节：Init Container 的退出码和重启策略
Init Container 设计上要求**必须成功退出（exit code 0）才能继续**，但很多人没意识到：
- 脚本里用
curl或nc等待服务时，超时后没exit 1，导致容器卡住不动（实际是挂起，非 Crash） -
restartPolicy: Always对 Init Container 无效——它失败后，整个 Pod 会按 Pod 级别重启策略重试（默认Always），但 Init Container 自身不会单独重试 - 调试时别只看
kubectl logs <pod>：Init Container 日志需加-c <init-container-name>，否则默认查主容器 - Init Container 镜像体积要小（推荐
busybox、alpine基础镜像），避免拖慢 Pod 启动
