日常开发中稳定触发的事件是：post-autoload-dump（每次install/update必触发，autoload变化时执行）、post-update-cmd（比post-install-cmd更常用，适合依赖调整）、post-root-package-install和post-create-project-cmd（仅项目初始化时各一次）。

Composer 的生命周期事件不是按“命令名”线性执行的，而是由实际操作触发、分层嵌套、且部分事件仅在特定条件下才发生——比如 post-install-cmd 只在首次 composer install（vendor 不存在时）触发，重跑不会执行。

哪些事件真正在日常开发中稳定触发？

别被文档里几十个事件名吓住，真正高频、可靠、值得你写逻辑的就那几个：

• post-autoload-dump：每次 composer install 或 composer update 后必走（只要 autoload 文件有变化），适合生成代理类、扫描注解、刷新运行时缓存
• post-update-cmd：比 post-install-cmd 更常用——因为开发者几乎只用 update 调整依赖，install 多用于 CI 或新环境部署
• post-root-package-install 和 post-create-project-cmd：只在项目初始化时各触发一次，适合模板项目（skeleton）做 .env.example 复制或引导提示
• pre-autoload-dump：极少数场景需要，比如你想在 classmap 生成前清空旧映射、或动态注入命名空间规则

像 pre-package-install 这类事件，每个包装一次就触发一次，10 个依赖就跑 10 次脚本——容易误判执行次数，也难调试，除非你真要对某个包打补丁，否则别碰。

Discussion Composer

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

下载

为什么写了 post-install-cmd 却没执行？

这是最常被卡住的问题：你改了 composer.json，加了 "post-install-cmd": "echo hello"，然后 composer install ——结果啥也没输出。

• 根本原因：composer install 在已有 vendor/ 且 composer.lock 未变时，会跳过安装流程，直接退出，post-install-cmd 根本不触发
• 验证方法：删掉 vendor/ 再跑一次，就能看到输出
• 替代方案：想“每次 install/update 都执行”，统一绑定到 post-autoload-dump，它不看 lock 是否变化，只看 autoload 是否重建——而重建是 install/update 的必经环节
• 注意：post-autoload-dump 默认不加载项目 autoloader，调用自己写的 PHP 类得显式 require 或用 php -f

脚本里调用 phpunit 报错 “Command not found” 怎么办？

这不是 Composer 的 bug，是你没理清执行上下文：

• scripts 中的命令默认以 shell 方式执行，PATH 是系统 PATH，不包含 vendor/bin/
• 错误写法："phpunit" → 系统找不到全局 phpunit
• 正确写法："vendor/bin/phpunit" 或 "php vendor/bin/phpunit"（显式指定解释器更稳）
• 更推荐封装成单文件 PHP 脚本："php build/run-tests.php"，里面可做版本判断、参数组装、异常捕获，还能用 __DIR__ 安全定位路径
• 所有脚本都在项目根目录下运行，别写 ./src/xxx.php，除非你确认当前工作目录一定是项目根目录（CI 中不一定）

事件顺序不是死记硬背的列表，而是由 Composer 内部调度器根据操作类型动态决定的；真正影响你落地效果的，往往不是“有没有这个事件”，而是“它在什么条件下触发、是否幂等、是否加载了你需要的代码环境”。