initcontainer中运行composer install是根本性反模式，因k8s网络未就绪、无重试容错、生命周期过短导致必然失败；正确方案是在docker多阶段构建中固化vendor到主镜像。
别在 InitContainer 里跑 composer install —— 这不是配置问题，是根本性反模式。 它会导致 Pod 卡在 Init:0/1、反复 CrashLoopBackOff，且修复手段（如加 wait-for-it.sh）全无效。真正可落地的方案只有一条：把 vendor/ 打进主镜像。
为什么 InitContainer 中运行 composer install 必然失败
InitContainer 启动时，K8s 尚未完成网络就绪：CoreDNS 往往还没 Ready，nslookup packagist.org 都超时，而 composer install 要做的远不止连端口——它需 TLS 握手、解析元数据、下载 tarball、解压、生成 autoload、写 classmap。这些操作无重试、无容错、依赖完整网络栈，InitContainer 生命周期又极短，一次抖动就中断，K8s 只会不断重启整个 Pod。
- 私仓（GitLab/Nexus）更危险：需凭据、可能重定向、响应头校验严格，InitContainer 无法处理
- 用
nc -z repo.example.com 443判断“网络 OK”纯属误导——HTTPS 请求失败率远高于 TCP 连通性 - 哪怕所有节点都
Ready，不同 Pod 启动时间差几秒，也可能拉到不同镜像源节点，导致vendor/内容不一致
多阶段构建中固化 vendor 的实操要点
核心原则：Composer 是构建期工具，不是运行时组件。所有依赖必须在镜像构建阶段完成，Pod 启动即用。
- 确保项目根目录存在
composer.lock（用composer install --no-dev --optimize-autoloader生成） - Dockerfile 第一阶段用
composer/composer:latest-bin或php:8.2-cli，COPYcomposer.json和composer.lock后执行composer install --no-dev --no-scripts --no-autoloader - 第二阶段用精简运行镜像（如
php:8.2-fpm-alpine），用COPY --from=builder /app/vendor /var/www/html/vendor复制依赖 - 私仓认证绝不能硬编码进 Dockerfile；改用 BuildKit
--secret id=auth传入auth.json，并在RUN --secret中临时挂载使用
vendor 写入 emptyDir 的三大风险
试图让 InitContainer 把 vendor/ 写进 emptyDir 再挂载给主容器，看似解耦，实则引入不可接受的脆弱性：
-
emptyDir生命周期绑定 Pod，Pod 重启即丢 —— 下次启动又要重装，彻底违背“一次构建、处处运行” -
vendor/包含数万小文件和 symlink，写入emptyDir（默认 tmpfs）极易吃光内存或耗尽 inode - InitContainer 若以
root写入，主容器若按安全规范以非 root 用户（如www-data）运行，会因权限不足无法读取vendor/autoload.php
真正麻烦的从来不是“怎么让 composer 跑起来”，而是“怎么让它不跑”。一旦你开始写 initContainers + command: [sh, -c, 'composer install']，就已经站在了反模式的起点上——后面所有调试、重试、等待逻辑，都是在给错误设计打补丁。
