不能在initcontainer中运行composer install，因其违背“一次构建、处处运行”原则，导致pod启动失败、依赖不一致及凭据泄露；正确做法是在docker多阶段构建中固化vendor到镜像。
不能在 InitContainer 中运行 composer install —— 这不是配置问题，而是设计反模式。 它会导致 Pod 卡在 Init:0/1、反复 CrashLoopBackOff，且根本原因不是网络没通，而是 InitContainer 的生命周期与 Composer 的行为天然冲突。
InitContainer 启动时网络往往不可用
CoreDNS 可能还没 Ready，nslookup 都失败，composer install 却直接发起 HTTPS 请求、解析 packagist 元数据、下载 tarball —— 这些操作远超“端口连得上”这种简单判断。
- K8s 不保证 InitContainer 启动时 DNS 已就绪；你加
until nslookup repo.packagist.org也救不了，因为 Composer 还要走 TLS 握手、校验证书、解压 ZIP、生成vendor/autoload.php - 私仓（如 GitLab 或 Nexus）更糟：需要凭据、可能有重定向、响应头依赖完整，InitContainer 没有重试机制，一次失败就卡死
- 哪怕网络临时抖动几秒，
composer install就中断，而 InitContainer 不会自动重试 —— K8s 只会不断重启整个 Pod
vendor/ 写入 emptyDir 是危险的临时方案
有人试图让 InitContainer 把 vendor/ 写进 emptyDir，再挂载给主容器。这看似“解耦”，实则引入三重风险：
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
-
emptyDir生命周期绑定 Pod，Pod 重启即丢 —— 下次启动又要重装，完全违背“一次构建、处处运行” -
vendor/包含大量小文件和 symlink，写入emptyDir（通常是 tmpfs）会吃光内存，或触发 inode 耗尽 - InitContainer 若用
root用户写入，主容器若以非 root 运行（推荐），会因权限不足无法读取vendor/autoload.php
私仓凭据绝不能塞进 InitContainer 镜像或环境变量
把 auth.json COPY 进 InitContainer 镜像，或通过 env 注入，等于把 token 明文暴露在镜像层或 K8s API 对象里 —— 任何有 get secrets 权限的人都能拿到。
- InitContainer 镜像一旦推到仓库，凭据就固化在历史 layer 中，无法安全轮换
- 环境变量会被
kubectl describe pod显示，也会出现在容器内/proc/<pid>/environ</pid>中 - 正确路径是：构建阶段用 BuildKit
--secret id=auth加载凭据，安装完立即销毁，不落盘、不进镜像
真正该做的：Docker 多阶段构建 + 锁定 composer.lock
Composer 是构建期工具，不是运行时组件。所有依赖必须固化进最终镜像，启动时只读加载。
- 确保项目根目录存在
composer.lock（用composer install --no-dev --optimize-autoloader生成） - Dockerfile 第一阶段用
php:8.2-cli或composer/composer:latest-bin执行composer install，第二阶段用php:8.2-apache-slim并COPY --from=builder /app/vendor /app/vendor - 私仓认证走 BuildKit secret：
docker build --secret id=auth,src=auth.json -t myapp .，Dockerfile 内用RUN --mount=type=secret,id=auth composer install
最易被忽略的一点：很多人以为只要 composer.lock 存在就安全了，但若构建时没指定 --no-dev，开发依赖会打进生产镜像；若没加 --optimize-autoloader，每次请求都得扫描全量 classmap —— 这些细节不控制，性能和安全都会打折扣。
