k8s节点本地缓存对composer无效，必须在docker构建阶段固化依赖：先copy composer.json/lock，再run composer install --no-dev --optimize-autoloader --classmap-authoritative，多阶段构建隔离缓存失效，私有源认证用buildkit secret。
不能靠K8s节点本地缓存做依赖分级——Composer的缓存必须在镜像构建阶段固化，运行时节点级缓存既不可控又无意义。
为什么K8s节点上挂载~/.composer/cache是无效操作
常见错误现象：Pod里执行composer install仍慢、反复下载、不同节点装出不同版本；日志出现Could not fetch packages或cache-read-only: true但没生效。
根本原因不是缓存路径没挂对，而是Composer缓存设计与K8s运行模型冲突：
- K8s Pod是无状态、短生命周期的，
~/.composer/cache挂载到emptyDir或hostPath后，重启即丢，无法形成“温”缓存 - 多个Pod共享同一hostPath时，缓存文件可能被并发写损坏（Composer缓存非线程安全）
- 即使挂了PersistentVolume，不同节点间缓存不互通，且
cache-files-ttl和gc逻辑在容器退出后就失效 - 真正影响安装速度的是元数据解析（packages.json）和dist包校验，这些依赖
composer.lock锁定，而非本地缓存是否存在
composer install必须在Docker build阶段完成，且带--no-dev --optimize-autoloader --classmap-authoritative
这是冷启动性能和依赖一致性的唯一可靠路径。漏掉任一参数都会导致运行时加载变慢或行为不一致。
实操要点：
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
-
--no-dev：剔除phpunit、phpstan等，减小镜像体积，避免CI/CD误用dev工具暴露攻击面 -
--optimize-autoloader：生成vendor/composer/autoload_classmap.php，跳过PSR-4动态扫描 -
--classmap-authoritative：强制只走classmap，查不到类直接报错，杜绝fallback慢路径 - 必须用
composer install而非dump-autoload——后者不校验composer.lock，不更新installed.json，新加类不会进classmap
多阶段构建中如何隔离composer.json和代码变更带来的缓存失效
典型陷阱：Dockerfile里COPY . /app后跑composer install，改个README.md就让整个依赖层失效。
正确顺序必须倒过来：
- 先
COPY composer.json composer.lock ./，再RUN composer install --no-dev ... - 之后才
COPY . .，这样只有composer.lock变化时才重建vendor层 - 私有仓库认证用
BUILDKITsecret：--secret id=auth,jsonsrc=auth.json，绝不硬编码进Dockerfile - 若用阿里云镜像，确保
composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/末尾有/，否则静默回退官方源
所谓“分级缓存”实际只存在于构建流水线中，不是运行时K8s节点策略
真正的分级发生在CI/CD环节：
- 一级冷缓存：CI runner宿主机的
~/.composer/cache，供多次构建复用dist包和元数据 - 二级温缓存：多阶段Docker build中，buildkit cache自动复用前次
composer install层（仅当composer.lock未变） - 三级热缓存：最终镜像里的
vendor/是只读的、确定性产物，Pod启动时零延迟加载
试图在K8s里模拟这三层，只会增加运维复杂度，掩盖构建流程缺陷。关键点永远在composer.lock是否提交、是否被严格遵循、是否在构建阶段一次性固化。
