Composer Hooks 是通过 scripts 配置在生命周期事件（如 post-install-cmd、post-autoload-dump）中触发的自定义命令，用于自动清理缓存、生成文件、校验依赖、执行静态分析等轻量任务，不支持原生钩子函数，也不具备事务回滚能力。
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
Composer Hooks 是什么，能干什么
Composer 本身没有原生的“钩子函数”概念，scripts 是唯一被官方支持的扩展机制。所谓 Hooks，其实是通过配置 scripts 在特定生命周期（如 pre-install-cmd、post-autoload-dump）触发自定义命令，本质是 shell 或 PHP 脚本的调度点。
它适合做：自动清理缓存、生成版本文件、校验依赖兼容性、执行静态分析、同步 dev-only 配置。不适合做需要强事务保证的操作（比如修改 composer.lock 后再继续安装）——Composer 不会回滚脚本失败后的状态。
哪些 scripts 可用，怎么写才不踩坑
官方文档列了约 20 个事件名，但真正稳定可用、且行为可预期的只有以下几类：
-
pre-install-cmd 和 pre-update-cmd：在依赖解析前触发，适合做环境检查（如 PHP 版本、扩展是否启用），但不能依赖 vendor/ 目录存在
-
post-install-cmd 和 post-update-cmd：安装完成后触发，vendor/ 已就绪，适合生成 autoloader 相关文件或运行初始化脚本
-
post-autoload-dump：每次 composer dump-autoload 或 install/update 自动生成 autoload 文件后触发，适合 patch classmap 或注入额外映射逻辑
-
pre-autoload-dump：极少用，仅在 autoload 生成前调用，无法修改 Composer 内部 autoload 配置，只能读取 $composer 对象（需 PHP 脚本）
常见错误：把 post-autoload-dump 当成“每次 composer run-script 都会触发”，其实它只响应 autoload 文件生成动作；或者在 pre-install-cmd 中尝试 require vendor/autoload.php —— 此时 vendor 还不存在。
PHP 脚本 vs shell 命令，选哪个更可控
Shell 命令简单直接，适合单行操作（如 touch storage/.installed），但跨平台兼容性差（Windows 下 rm -rf 失败）、无异常传播、难调试。
PHP 脚本更推荐，尤其涉及 Composer 对象操作时：
"scripts": {
"post-autoload-dump": [
"MyScript::onAutoloadDump"
]
}
对应类需满足：
- 方法必须是
public static
- 参数签名必须为
(Composer\Script\Event $event)
- 可通过
$event->getComposer() 获取实例，$event->getIO() 输出日志
- 返回
false 或抛出异常会中断后续脚本（但不会中止 Composer 主流程，除非是 install/update 的关键阶段）
注意：MyScript 类必须能被当前 autoloader 加载——所以首次 install 时，该类不能放在 src/ 下且未被 autoload 配置覆盖，否则报 Class not found。稳妥做法是放在 scripts/ 目录并用 files autoload 加载。
为什么 post-install-cmd 有时不执行
最常被忽略的是：Composer 默认跳过已安装包的脚本执行。也就是说，如果你本地已有 vendor/，运行 composer install 时，只有 lock 文件有变更才会触发 post-install-cmd；纯重装（rm -rf vendor && composer install）才一定触发。
另一个原因是脚本配置位置错误：必须写在根 composer.json 的 scripts 里，而不是某个依赖包自己的 composer.json —— 后者只在该包作为 root 安装时生效。
还有就是 JSON 格式错误导致整个 scripts 段被忽略，建议用 composer validate 检查。
实际开发中，别指望 hooks 替代 CI 流程或部署脚本；它们只是轻量级辅助，一旦逻辑变复杂，就该移出 composer.json，改用独立的 bin script 或 Makefile 管理。
-
pre-install-cmd和pre-update-cmd：在依赖解析前触发，适合做环境检查（如 PHP 版本、扩展是否启用），但不能依赖vendor/目录存在 -
post-install-cmd和post-update-cmd：安装完成后触发，vendor/已就绪，适合生成 autoloader 相关文件或运行初始化脚本 -
post-autoload-dump：每次composer dump-autoload或 install/update 自动生成 autoload 文件后触发，适合 patch classmap 或注入额外映射逻辑 -
pre-autoload-dump：极少用，仅在 autoload 生成前调用，无法修改 Composer 内部 autoload 配置，只能读取$composer对象（需 PHP 脚本）
post-autoload-dump 当成“每次 composer run-script 都会触发”，其实它只响应 autoload 文件生成动作；或者在 pre-install-cmd 中尝试 require vendor/autoload.php —— 此时 vendor 还不存在。
PHP 脚本 vs shell 命令，选哪个更可控
Shell 命令简单直接，适合单行操作（如 touch storage/.installed），但跨平台兼容性差（Windows 下 rm -rf 失败）、无异常传播、难调试。
PHP 脚本更推荐，尤其涉及 Composer 对象操作时：
"scripts": {
"post-autoload-dump": [
"MyScript::onAutoloadDump"
]
}
对应类需满足：
- 方法必须是
public static
- 参数签名必须为
(Composer\Script\Event $event)
- 可通过
$event->getComposer() 获取实例，$event->getIO() 输出日志
- 返回
false 或抛出异常会中断后续脚本（但不会中止 Composer 主流程，除非是 install/update 的关键阶段）
注意：MyScript 类必须能被当前 autoloader 加载——所以首次 install 时，该类不能放在 src/ 下且未被 autoload 配置覆盖，否则报 Class not found。稳妥做法是放在 scripts/ 目录并用 files autoload 加载。
为什么 post-install-cmd 有时不执行
最常被忽略的是：Composer 默认跳过已安装包的脚本执行。也就是说，如果你本地已有 vendor/，运行 composer install 时，只有 lock 文件有变更才会触发 post-install-cmd；纯重装（rm -rf vendor && composer install）才一定触发。
另一个原因是脚本配置位置错误：必须写在根 composer.json 的 scripts 里，而不是某个依赖包自己的 composer.json —— 后者只在该包作为 root 安装时生效。
还有就是 JSON 格式错误导致整个 scripts 段被忽略，建议用 composer validate 检查。
实际开发中，别指望 hooks 替代 CI 流程或部署脚本；它们只是轻量级辅助，一旦逻辑变复杂，就该移出 composer.json，改用独立的 bin script 或 Makefile 管理。
public static
(Composer\Script\Event $event)
$event->getComposer() 获取实例，$event->getIO() 输出日志false 或抛出异常会中断后续脚本（但不会中止 Composer 主流程，除非是 install/update 的关键阶段）vendor/，运行 composer install 时，只有 lock 文件有变更才会触发 post-install-cmd；纯重装（rm -rf vendor && composer install）才一定触发。
另一个原因是脚本配置位置错误：必须写在根 composer.json 的 scripts 里，而不是某个依赖包自己的 composer.json —— 后者只在该包作为 root 安装时生效。
还有就是 JSON 格式错误导致整个 scripts 段被忽略，建议用 composer validate 检查。
实际开发中，别指望 hooks 替代 CI 流程或部署脚本；它们只是轻量级辅助，一旦逻辑变复杂，就该移出 composer.json，改用独立的 bin script 或 Makefile 管理。
