pre-autoload-dump 是 Composer 唯一可靠用于 composer install 前执行脚本的原生事件，需在 scripts 中注册，支持 PHP 内联命令和类方法调用，运行时 vendor 未生成故不可依赖 autoload.php。
pre-install-cmd 不是 Composer 的合法脚本事件名，直接写它会导致脚本完全不执行——这是绝大多数人卡住的第一步。
Composer 里根本没有 pre-install-cmd
官方事件列表中不存在这个钩子。你看到的“教程”大概率混淆了旧版自定义命令、第三方插件（如 composer-asset-plugin）或手动拼写的错误名称。Composer 原生支持的安装/更新前钩子只有：
-
pre-install-cmd❌ 不存在 -
pre-update-cmd✅ 存在，但只在composer update前触发 -
pre-autoload-dump✅ 在生成自动加载文件前触发（install和update都会走） -
post-root-package-install✅ 在根包安装完成后触发（常被误当作“安装前”，实际是后置）
想在 composer install 开始下载依赖前做点事，唯一可靠路径是 pre-autoload-dump —— 它在锁文件校验通过、依赖解析完成之后、vendor 文件写入之前执行，最接近“安装前”的语义。
pre-autoload-dump 怎么写才真正生效
它不是命令别名，而是事件名，必须注册在 scripts 段里，并确保对应脚本存在且可执行：
{
"scripts": {
"pre-autoload-dump": [
"@php -r \"file_put_contents('install-started', time());\"",
"MyScript::checkEnv"
]
}
}
注意要点：
- 脚本数组里的每个字符串都会被执行，顺序从上到下
- 用
@php直接调用 PHP 是最轻量的方式，避免 shell 兼容性问题 - 类方法调用（如
MyScript::checkEnv）要求该类已能被 Composer 自动加载——通常得先确保autoload配置正确，否则脚本会因类找不到而中断 - 如果脚本 exit 非 0，整个
composer install会中止，这是做环境校验的合理方式
为什么不用 pre-update-cmd 替代
因为 pre-update-cmd 只在 composer update 时触发，composer install 完全不走它。很多场景下用户真正要拦截的是首次 install（比如检查 .env 是否存在、PHP 扩展是否启用），这时靠 pre-update-cmd 就会漏掉关键时机。
更隐蔽的问题是：某些 CI 环境会先 update 再 install，导致脚本重复执行两次；而 pre-autoload-dump 在两种命令下都只触发一次，且时机更可控。
容易被忽略的权限与路径陷阱
脚本运行时的当前工作目录是项目根目录，但 vendor/ 还没生成，所以不能依赖 vendor/autoload.php —— 这是新手写自定义类时最常见的 fatal error 来源。
- 所有路径操作请用相对项目根目录的写法，例如
file_get_contents('.env') - 不要在脚本里 require
vendor/autoload.php，它此时还不存在 - 如果必须用外部工具（如
jq、git），记得检查PATH和执行权限，Docker 或 Alpine 环境里常缺这些 - 输出内容会被 Composer 日志捕获，但不会显示在终端——加
echo或file_put_contents才能看到效果
真要控制安装流程，别纠结名字，盯死 pre-autoload-dump 的行为边界和执行上下文就够了。
