Composer如何配置pre-install-cmd钩子_Composer pre-install-cmd钩子配置详解

Composer如何配置pre-install-cmd钩子_Composer pre-install-cmd钩子配置详解

pre-install-cmd 是 Composer 在真正执行依赖安装前触发的生命周期钩子，仅当 vendor 不存在或 composer.lock 变更时运行；需置于 composer.json 顶层 scripts 下、值为数组，且不启用 --no-scripts 才生效。

pre-install-cmd 是什么，它到底在什么时候执行

简单来说，pre-install-cmd是Composer内置的一个“触发器”，它会在安装流程真正启动前被激活。但这里有个关键细节：它并非每次你输入composer install都会运行。准确地说，它只在Composer确实需要执行安装动作时才会触发。如果项目里的vendor/目录已经存在，并且composer.lock文件也没有任何变动，Composer会聪明地跳过整个安装过程——自然，这个前置钩子也就不会执行了。

• 所以，别把它理解为“命令执行器”，它更像是一个“条件执行器”：真正装包前才启动。
• 它的生效有两个前提：一是不能使用--no-scripts参数，二是Composer版本建议在1.10以上（最好用2.2或更高版本）。
• 它还有个“兄弟”叫pre-update-cmd，两者设计对称但触发逻辑不同：pre-install-cmd盯着vendor和lock文件的状态；而pre-update-cmd则关注lock文件是否需要重新计算。
• 一个常见的困惑场景是：在本地反复运行composer install，却看不到脚本执行的日志。这往往不是配置出了问题，而是Composer判断无需安装，于是静默跳过了整个流程。

怎么写才有效：scripts 字段位置和值格式要求

想让pre-install-cmd生效，写法上必须严格遵循Composer的规则。它必须直接放在项目根目录下composer.json文件的最外层，也就是顶层的scripts字段里，和autoload、require这些字段平级。千万别把它塞进extra、config或者任何嵌套的对象里，那样是无效的。

• 它的值必须是一个数组（从Composer 5.6版本开始强制要求）。例如：["php scripts/check-php-version.php", "@php -r "echo 'pre-install OK\n';""]。
• 如果错误地写成了单个字符串（比如"php check.php"），Composer会静默忽略它，既不报错，也不会执行，很容易让人误以为配置成功了。
• 数组里的命令会按顺序依次执行。如果其中任何一条命令的退出码（exit code）不是0，那么后续所有命令都会中止，整个composer install过程也会以失败告终。
• 命令前以@开头（例如@php）是个好习惯，Composer会自动将其解析为当前环境的PHP可执行文件路径。这比硬编码写死php要可靠得多，尤其是在安装了多个PHP版本的环境中。

为什么脚本没运行？常见失效原因和验证方法

脚本没跑起来，十有八九问题出在“根本没达到触发条件”，而不是配置本身写错了。排查时，建议先确认是否真的应该触发，再去检查配置细节。

• 最直接的验证方法是运行composer install -v（带上verbose参数），仔细观察输出里有没有出现Executing script这一行。如果没有，那基本可以断定Composer跳过了执行流程。
• 检查是否无意中启用了--no-scripts选项，或者设置了COMPOSER_NO_INTERACTION=1这样的环境变量（一些持续集成环境可能会默认开启）。
• 如果脚本里调用了自定义的PHP类（例如MyToolChecker::run），必须确保这个类文件已经被包含在autoload的配置中。否则，Composer会报出Class not found的错误，而且提示信息可能并不明确。
• 注意拼写！写成pre-install、preinstall-cmd或者post-install-cmd都不会触发目标钩子，必须严格匹配pre-install-cmd这个键名。
• 在Windows环境下，如果脚本路径中写死了反斜杠\作为分隔符，可能会导致文件找不到。更稳妥的做法是统一使用正斜杠/，或者使用PHP的DIRECTORY_SEPARATOR常量。

适合放什么逻辑？别踩的典型坑

pre-install-cmd的定位非常明确，就是做“安装前的校验与准备工作”。它的执行时机非常早，早于自动加载文件的生成，也早于vendor包的解压。因此，千万别在里面写那些需要依赖vendor/autoload.php或者假设某些目录（如config/、storage/）已经存在的逻辑。

• 适合做的事情：检查PHP版本或必要的扩展是否存在、验证关键环境变量是否已设置、将.env.example模板文件复制为.env、清理旧的缓存目录（例如执行rm -rf bootstrap/cache/*）。
• 不适合做的事情：运行类似php artisan migrate这样的框架命令（它们通常依赖完整的自动加载）、编译或生成前端资源（此时node_modules可能还没安装）、执行数据库写入操作。
• 如果脚本逻辑本身确实需要Composer的自动加载功能，必须手动引入：require __DIR__ . '/vendor/autoload.php';。但务必注意，此时vendor/目录可能还不存在或者不完整，这么做风险很高。
• 在CI/CD流水线中，要谨慎使用耗时的操作（比如下载远程配置文件）。因为这个钩子卡在install流程的最前端，一旦耗时过长，会拖慢整个构建链路的效率。

说到底，让pre-install-cmd生效的关键，并不在于把配置写得多么面面俱到，而在于透彻理解Composer的“跳过逻辑”——它的设计哲学是“宁可不跑，也不愿重复跑”。很多团队遇到钩子不触发的情况，第一反应是配置失效，但更可能的原因是，触发它的前提条件压根就没满足。