不能在Kubernetes Init Container中运行composer install，因其违背容器“一次构建、处处运行”原则：CoreDNS未就绪导致网络失败、默认不共享可写卷致vendor写入拒绝、凭据暴露风险高、重启重复安装引发版本不一致。
不能在 Kubernetes 容器初始化时运行 composer install —— 这不是配置问题，而是设计误用。
为什么 Init Container 里执行 composer install 必然失败
常见现象：Pod 卡在 Init:0/1、反复 CrashLoopBackOff，日志里出现 Connection refused、Could not fetch packages 或 failed to open stream: php_network_getaddresses。
- CoreDNS 往往还没就绪，
nslookup packagist.org直接失败 - Init Container 和主容器默认不共享可写卷，
vendor/写入会因权限或挂载缺失被拒绝 - 私有仓库凭据若通过
env注入，会在kubectl describe pod中明文暴露；若挂载Secret，Init 镜像就得额外打包composer+ 凭据处理逻辑，膨胀且难维护 - 每次 Pod 重启都重跑一遍，耗时几十秒起步，且若
composer.lock未提交，不同节点可能装出不同版本
哪些场景下你以为需要它，其实根本不需要
比如“想复用 vendor 缓存”“想按需加载私有包”“想让镜像更小”，这些诉求都指向构建阶段优化，而非运行时补救。
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 缓存复用：应在 CI 的
docker build阶段用--cache-from复用上一轮构建层，而不是靠 Init Container 拉包 - 私有包：认证凭据必须在 CI 构建时注入（如
DOCKER_BUILDKIT=1+build-arg），或通过COPY --from=auth-builder多阶段传递，运行时绝不接触凭据 - 镜像体积：用
--no-dev --no-scripts --optimize-autoloader裁剪，而非把vendor/留到启动时再生成
真正该在 Init Container 做的 PHP 相关事
Init Container 的合理用途，是解决构建期做不到、但运行前必须完成的**环境适配类任务**：
- 等待下游服务就绪：比如用
busybox轮询nc -z mysql 3306，确保 DB Service 已发布、Endpoint 有 backing Pods - 注入动态配置：从
ConfigMap拷贝php.ini片段到emptyDir卷，再由主容器挂载覆盖默认配置 - 迁移前校验：执行
php artisan schema:has-table users（Laravel）或简单 SQLSELECT 1，确认 DB 连通且 schema 存在，失败则阻断启动
复杂点在于：很多人把 composer install 当成“初始化依赖”的惯性操作，却忽略了容器镜像本应是完整可运行单元——vendor/ 必须固化在镜像层里，不是靠每次启动去拼凑。一旦接受这个前提，所有“运行时安装”的尝试都会自然退场。
