怎样在安装依赖前执行自定义的检查逻辑？利用pre-install-cmd事件钩子-composer-PHP中文网

不能。pre-install-cmd 是通知型事件，仅在 install 开始后、下载前触发，不拦截 lock 校验和平台检查；需靠脚本主动 exit(1) 才能中断流程，且该钩子在 composer 2.2+ 已被彻底移除。

怎样在安装依赖前执行自定义的检查逻辑？利用pre-install-cmd事件钩子

pre-install-cmd 钩子是否真能拦截依赖安装？

不能。Composer 的 pre-install-cmd 是一个「通知型」事件，不是「拦截型」钩子——它会在 composer install 开始执行后、实际下载/解压包之前触发，但此时已跳过 lock 文件校验和平台兼容性检查。如果想在真正拉取任何依赖前做准入判断（比如检查 PHP 版本、环境变量、私有源凭证），靠它不够可靠。

为什么 pre-install-cmd 常被误用？

常见错误是把它当成了“安装前闸门”，结果写出这样的脚本：

#!/usr/bin/env php
<?php if (getenv('ENV') !== 'prod') {
    throw new RuntimeException('Only allowed in prod');
}

问题在于：这个脚本会运行，但即使抛出异常，composer install 仍可能部分完成（比如已生成 vendor/autoload.php 或写入部分缓存）。更糟的是，它不阻止 composer update 后的 install，也不影响 CI 中从干净目录首次 install 的流程。

真正需要拦截的场景，应该前置到命令入口层。推荐做法：

把检查逻辑封装成独立 CLI 命令（如 bin/pre-check.php），并在 CI 脚本或 Makefile 中显式调用：php bin/pre-check.php && composer install
在 composer.json 的 scripts 中定义 check-env，再通过 "pre-install-cmd": ["@check-env"] 触发——但这仍是事后通知，仅适合非阻断性提示
若必须强约束，改用 Composer 插件（需实现 EventSubscriberInterface 并监听 PreInstallEvent），但插件开发成本高、调试困难，且无法阻止 lock 文件解析阶段的失败

pre-install-cmd 的合理使用场景

它适合做「轻量准备动作」，而非「准入控制」。典型用途包括：

Discussion Composer

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

下载

清理旧的构建产物：rm -rf public/build/*
生成运行时配置文件（内容不依赖未安装的包）：php scripts/generate-config.php
记录安装上下文：echo "Installing at $(date)" >> var/log/install.log
检查基础扩展是否加载（如 extension_loaded('mbstring')），但不要 throw——只 warn，因为扩展缺失通常会导致后续安装直接失败

注意：pre-install-cmd 不接收参数，无法区分是 install 还是 update 触发；若需差异化逻辑，应改用 pre-update-cmd 或 post-install-cmd 配合 COMPOSER_COMMAND 环境变量判断。

替代方案：用 install-platform-checks 更稳妥

Composer 2.2+ 内置了平台检查机制，比手写钩子更底层、更早生效。只需在 composer.json 中声明：

"config": {
    "platform-checks": true
},
"require": {
    "php": "^8.1"
}

这样，只要 PHP 版本不满足，composer install 在读取 composer.json 后立即退出，根本不会走到 pre-install-cmd 阶段。自定义检查（如验证扩展、环境变量）可配合 scripts.check-platform-reqs 实现，它会在平台检查之后、依赖解析之前运行，时机更可控。

真正的难点不在钩子怎么写，而在于分清「该由 Composer 自身保障的约束」和「必须由项目侧介入的业务逻辑」——后者往往不该塞进安装流程里，而是该提前固化在 CI 模板或本地开发容器配置中。