InitContainer 中运行 composer install 是错误做法，因其生命周期短、无重试机制，与需网络就绪、磁盘写入、缓存生成的 composer install 行为根本冲突，导致 Pod 启动不可控、依赖不一致、凭据泄露；正确做法是在 Dockerfile 多阶段构建中固化 vendor 到镜像。
InitContainer 里跑 composer install 是错的，不是配置问题，是架构误用。 它看起来能“解耦构建逻辑”，实际会让 Pod 启动不可控、依赖不一致、凭据暴露、vendor 目录不可靠——这些都不是调参数能修好的。
为什么 InitContainer 无法可靠执行 composer install
根本矛盾在于生命周期与行为不匹配：InitContainer 设计为短时、无状态、单次执行；而 composer install 需要网络就绪、磁盘写入、缓存生成、autoloader 构建，且中间任意环节失败（如 DNS 解析延迟、私仓响应超时、SSL handshake 失败）都会直接退出，K8s 不会重试，也不会等 CoreDNS Ready。
- 现象包括：
Init:0/1卡住、CrashLoopBackOff循环重启、日志中反复出现Could not fetch packages或failed to open stream: php_network_getaddresses: getaddrinfo failed - 即使加了
wait-for-it.sh或nc -z repo.example.com 443，也只验证了端口连通性，无法保证 Composer 元数据解析、tarball 下载、解压、autoload 生成全部成功 - 多个 Pod 启动时间差几秒，可能命中不同镜像源节点或私仓实例，导致装出内容不一致的
vendor/
composer install 必须放在 Dockerfile 的 RUN 阶段
依赖安装是构建期行为，不是运行时动作。所有 vendor/ 内容必须固化进最终镜像层，确保 Pod 启动即可用、只读、可复现。
- 必须先
COPY composer.lock .，再COPY composer.json .，最后RUN composer install --no-dev --optimize-autoloader—— 顺序错会导致退化成composer update - 多阶段构建中，builder 镜像（如
php:8.2-cli）和 final 镜像（如php:8.2-apache-slim）的 PHP 版本、SAPI 类型、关键扩展（zip、mbstring、pdo）必须严格对齐 - 私仓认证绝不能硬编码进 Dockerfile 或环境变量，改用 BuildKit
--secret id=auth传入 - 国内环境务必提前设置镜像源：
RUN composer config -g repo.packagist https://mirrors.aliyun.com/composer/
config.platform.php 不是可选项，是生产必需项
不显式锁定 PHP 和扩展版本，Composer 就会按当前 builder 环境推测平台能力，可能装入仅兼容 PHP 8.3 的语法（比如 readonly 属性），导致运行时报 ParseError。
-
composer.json中必须包含："config": {"platform": {"php": "8.2.15", "ext-zip": "8.2.15"}} - 构建前运行
composer update --lock并提交更新后的composer.lock，确保平台信息固化 - 验证命令：
composer show --platform输出应与目标运行环境完全一致
真正麻烦的不是怎么让 InitContainer 跑通 composer install，而是它一旦跑通，会掩盖更严重的不可复现性和安全风险——比如凭据泄露、临时 vendor/、启动时网络抖动引发的静默失败。把依赖打进镜像，才是唯一能同时满足一致性、安全性、可观测性的做法。
