pre-autoload-dump是唯一稳定可用的安装前钩子，它在vendor解包完成、composer.lock解析完毕但vendor/autoload.php尚未生成时触发，适合.env检查、扩展验证等纯文件操作，不依赖lock变更，每次install/update必执行。

pre-autoload-dump 是唯一能稳定拦截安装流程的钩子

别再写 pre-install-cmd —— Composer 2.2+ 已明确弃用，行为不可靠：本地偶尔执行、CI 完全静默、无报错也无日志。真正可用且每次 composer install 或 composer update 都会触发的前置点，只有 pre-autoload-dump。

这个事件发生在 vendor/ 解包完成、composer.lock 已解析完毕、但 vendor/autoload.php 尚未生成的临界时刻。它不依赖 lock 是否变更，也不看命令参数，只要流程走到 autoload 步骤，就一定执行。

• 适合做：检查 .env 是否存在、验证 extension_loaded('opcache')、预热远程缓存目录（如 S3 挂载点）、清理旧 cache/ 子目录
• 不适合做：调用项目内任何未显式 require 的类（autoload.php 还没写入磁盘）
• 不能做：composer dump-autoload 自身调用，否则会递归触发事件

在云环境里用 pre-autoload-dump 拉取远程缓存要绕过两个坑

云原生部署常把缓存存在对象存储（如 S3、OSS）或共享卷中，想在 pre-autoload-dump 里提前拉取，得避开权限和路径问题。

Discussion Composer

围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par

下载

• 脚本必须用 php -f 显式调用，不能塞进一行 shell 命令；否则 Composer 不捕获退出码，失败也不中断流程
• 若需访问项目类（比如用 Aws\S3\S3Client），开头必须手动 require __DIR__.'/../vendor/autoload.php' —— 但注意：此时 vendor/autoload.php 还不存在，所以得把 SDK 提前放进 composer.json 的 require（非 require-dev），并确保它不依赖其他未安装包
• 拉取失败时，用 exit(1) 终止，Composer 会停在当前步骤；加 file_put_contents('php://stderr', "[cache] failed\n") 确保日志可见
• 不要假设 /tmp 可写或持久 —— 云函数或 EKS Pod 可能挂载只读根文件系统，缓存目标路径应指向 /app/cache 或挂载的 PVC 路径

Docker 构建阶段配合 --mount=type=cache 和 pre-autoload-dump 效果翻倍

在 BuildKit 支持的 Docker 构建中，--mount=type=cache,target=/root/.composer/cache 能复用包归档缓存，但无法解决 vendor 目录冷启动问题。这时候 pre-autoload-dump 就能补位：在构建镜像时，让它从远端同步一份预生成的 vendor/ 快照（比如从 CI 构建产物桶下载 tar.gz 并解压）。

• 关键约束：解压路径必须是 /app/vendor，且权限为 www-data 或容器运行用户可读
• 避免在 pre-autoload-dump 中执行耗时网络操作 —— 构建阶段超时常见于慢速对象存储，建议加超时控制（如 curl --max-time 30）
• 如果用了 --no-autoloader（多阶段构建常用），pre-autoload-dump 不会触发，得改用 post-package-install 或外部脚本封装
• 缓存键要包含 PHP 版本和 composer.lock 哈希，否则不同版本 PHP 共用同一份预拉取 vendor 会导致 opcache 或 classmap 错误

CI 流水线里缓存 vendor/ 比缓存 ~/.composer/cache 更值得优先做

GitHub Actions、GitLab CI 等默认每次都是干净容器，~/.composer/cache 缓存能省下载时间，但对首次 composer install 仍要解压 + symlink + 生成 classmap，耗时占大头。而直接缓存 ./vendor 目录，命中后跳过全部安装逻辑，实测快 3–8 倍。

• 缓存键必须用 ${{ hashFiles('**/composer.lock') }}，不能只用文件名或时间戳
• 加条件判断：仅在 push 或 pull_request 主分支时写缓存，避免 fork PR 污染主缓存
• 务必加 --no-dev，否则 vendor/ 体积可能暴涨 200%，尤其含 phpunit 或 infection 时
• 如果项目启用了 classmap-authoritative，缓存 vendor 后无需再跑 dump-autoload，但要注意该模式下动态加载（如 eval() 或插件机制）会失效

云原生场景下，pre-autoload-dump 不是万能钩子，它只管“安装流程中的一个切面”。真正可靠的缓存策略，得把钩子、Docker mount、CI 缓存、对象存储预热这几层拧在一起用——漏掉任意一层，都可能在某个环境里突然变慢或失败。