initcontainer中运行composer install是错误做法，因其违背容器“一次构建、处处运行”原则，导致镜像不可复现、启动失败、依赖不一致及凭据泄露风险；正确做法是在docker多阶段构建中将vendor打进镜像，确保pod启动时依赖已固化且只读。
InitContainer 中运行 composer install 是错的
它看起来很“干净”——把依赖安装逻辑从主镜像里抽出来，用单独容器做初始化。但实际会触发一连串不可控问题：
Pod 卡在 Init:0/1、反复 CrashLoopBackOff、日志里频繁出现 Could not fetch packages 或 failed to open stream: php_network_getaddresses: getaddrinfo failed。
根本不是 DNS 配置或 Service 网络没通，而是 InitContainer 启动时，K8s 还没准备好网络就绪（比如 CoreDNS 可能还没 Ready），而 composer install 依赖远程仓库、写磁盘、生成缓存和 autoloader —— 这些行为与 InitContainer 的短生命周期、无状态、无重试保障机制完全冲突。
更麻烦的是：不同 Pod 启动时间差几秒，可能连上不同镜像源或私仓节点，导致装出不一致的 vendor/；若 composer.lock 缺失，结果更不可控。
为什么不能靠 depends_on 或健康检查来“等网络”
K8s 没有 depends_on（那是 Docker Compose 的语法），它的 InitContainer 本身不支持等待其他服务就绪；你加了 healthCheck 或写个 wait-for-it.sh 也没用——因为 composer install 不是连接单个端口就能成功的操作，它要解析包元数据、下载 tarball、解压、写文件、生成 classmap，中间任何一步失败都会中断，且无法自动重试。
常见错误尝试包括：
- 在 InitContainer 里跑 nc -z repo.example.com 443 就认为网络 OK
- 把私仓凭据硬编码进 InitContainer 镜像或环境变量
- 让 InitContainer 把 vendor/ 写到 emptyDir 再挂载给主容器
这些做法要么暴露凭据，要么让 vendor/ 变成临时目录（重启即丢），要么根本绕不开网络不稳定导致的失败。
正确路径：所有依赖必须打进主镜像
Composer 是构建期工具，不是运行时组件。K8s Pod 应该是“拿来即跑”，不带任何外部依赖拉取动作。
关键实操点：
- 确保项目根目录存在 composer.lock（用 composer install --no-dev --optimize-autoloader 生成）
- Dockerfile 必须用多阶段构建：第一阶段用 php:8.2-cli 或 composer/composer:latest-bin 安装依赖，第二阶段 COPY vendor/ 到精简运行镜像（如 php:8.2-apache-slim）
- 私仓认证绝不能写进 Dockerfile，改用 BuildKit secret：--secret id=auth,jsonsrc=auth.json
- 主镜像里不要留 composer.phar、vendor/bin/ 下的 dev 工具，也不该有 composer.json 或 composer.lock
如果真要动态加载（极少数场景）
比如灰度发布时需切换某几个包的版本，或 A/B 测试需要不同依赖组合——这时也不是在 InitContainer 跑 composer install，而是：
- 提前构建多个带不同 vendor/ 的镜像变体（tag 区分），用 K8s imagePullPolicy: Always + Deployment rollout 控制
- 或把部分可插拔依赖打包成 PHAR，运行时通过 require_once 加载，不走 Composer autoload 流程
- 绝对避免在容器内执行 composer update 或修改 composer.lock，那等于把生产环境当开发机用
真正的边界在这里：一旦 Pod 启动，vendor/ 就该是只读的、确定的、不可变的。
