K8s Pod中composer install总从头下载包是因为每次Pod启动都是全新容器，~/.composer/cache无法持久化或跨Pod共享；真正有效的缓存必须在CI/CD构建阶段通过分层COPY和BuildKit cache实现，而非运行时挂载。
为什么K8s Pod里composer install总从头下载包
因为每个Pod是全新启动的容器实例，~/.composer/cache目录不持久、不共享，每次执行composer install都相当于在空白环境里重来。即使你挂了emptyDir或hostPath卷，也解决不了跨Pod缓存复用问题——缓存必须在构建阶段生效，而非运行时。
能否用ConfigMap或PersistentVolume挂载composer cache
不能。Composer缓存是二进制文件+哈希索引结构，对路径、权限、UID/GID敏感；ConfigMap只读且有大小限制；PersistentVolume挂载到/root/.composer/cache会导致：
• 多个Pod并发写入同一PV引发文件损坏
• 缓存校验失败（Package foo has a PHP requirement incompatible类错误频发）
• 构建镜像时无法利用该缓存，失去分层复用价值
真正有效的缓存共享发生在构建阶段
K8s本身不参与构建，但CI/CD流水线（如GitHub Actions、GitLab CI）可以控制构建上下文。关键动作在Docker build环节：
• COPY composer.json composer.lock ./ 必须单独成层，且早于任何代码复制
• RUN composer install --no-dev --prefer-dist --optimize-autoloader 这行必须紧随其后
• 使用BuildKit的--mount=type=cache,target=/root/.composer/cache仅在CI节点能复用缓存，前提是所有构建任务跑在同一台Runner上
• 更稳妥的做法是：固定composer.lock + 分层COPY，90%场景下已足够稳定
生产环境绝对不要在Pod里运行composer update
这会直接破坏composer.lock一致性，导致不同Pod装出不同依赖版本。K8s调度不可控，你无法保证哪个Pod先执行、谁覆盖谁。正确路径只有两条：
• 所有依赖变更必须走CI触发新镜像构建，再滚动更新Deployment
• 开发环境用docker-compose run --rm php composer update生成新lock，提交后再推镜像
缓存共享的本质不是“让运行时更快”，而是“让每次构建更确定”。一旦把期望移到Pod启动阶段，就掉进了不可靠的陷阱。
