post-autoload-dump 在 vendor/autoload.php 及其映射文件被实际写入或重写后触发，适用于 composer install/update/dump-autoload 或 autoload 配置变更等场景，配置需置于 scripts 下键名为 post-autoload-dump，宜执行清理、生成等轻量任务，禁用重复加载和递归调用。
post-autoload-dump 不是“安装后执行”，而是“自动加载文件写完立刻执行”——它触发时机比 post-install-cmd 更稳定，也更贴近真实依赖变更节点。
post-autoload-dump 触发条件有哪些
这个事件只在 Composer 实际写入或重写 vendor/autoload.php 及其配套映射文件（如 autoload_classmap.php、autoload_psr4.php）之后才触发。常见场景包括：
-
composer install：首次安装，或composer.lock变更导致依赖树重算 -
composer update：任何包版本变动、新增/删包 -
composer dump-autoload -o或不带参数的dump-autoload - 修改
composer.json中的autoload或autoload-dev配置后运行 install/update
注意：composer install --no-scripts 会跳过所有脚本；composer install 在 vendor 已存在且 lock 未变时，可能不触发该事件（因为 autoload 文件没重写）。
怎么在 composer.json 里正确配置
必须把命令写在 scripts 段下，键名严格为 post-autoload-dump，值可以是字符串或数组：
"scripts": {
"post-autoload-dump": [
"@php scripts/cleanup.php",
"echo '✅ Autoloader updated'"
]
}
要点：
- 不支持
pre-autoload-dump那种多级嵌套命令（如@clean调用另一个 script），建议直接调用 PHP 脚本或单条 shell 命令 - PHP 脚本路径需相对项目根目录，且不能依赖尚未加载的类（但此时
vendor/autoload.php已就绪，可放心new任意已声明 autoload 的类） - Windows 用户避免
rm -rf，改用del /q+rmdir /s /q，或统一走 PHP 脚本
能做什么？哪些操作要避开
典型用途是清理、生成、通知类任务，比如清缓存、删旧代理类、重建符号链接、触发 IDE 重索引：
- ✅ 安全操作：
unlink()临时文件、file_put_contents()写 stub、调用Illuminate\Foundation\Console\OptimizeCommand等框架类 - ✅ 可读取配置：此时
vendor/autoload.php已加载，config/*和.env（若已加载）都可用 - ❌ 禁止操作：
require 'vendor/autoload.php'（重复加载会破坏命名空间）、exec('composer dump-autoload')（递归触发死循环） - ❌ 避免耗时操作：该钩子阻塞主流程，长时间 IO（如远程请求、大文件压缩）会拖慢 install/update
为什么不用 post-install-cmd 替代
post-install-cmd 只在「首次安装」或显式加 --force 时可靠；而 post-autoload-dump 在每次 autoloader 变更时都跑，覆盖更多真实场景：
- 切换 Git 分支后
composer install→ autoload 映射很可能变，post-autoload-dump触发，post-install-cmd不触发 - CI 流水线中先
install --no-dev，再dump-autoload --dev→ 后者单独触发post-autoload-dump，但不走 install 流程 - Laravel 的
php artisan optimize:clear就绑在post-autoload-dump上，就是因为它需要等 classmap 确认生效后再清缓存
真正容易被忽略的是：它不保证“项目完全就绪”，只保证“自动加载器已就位”。如果你的清理逻辑依赖某个命令行工具（如 phpunit）或外部服务（如 Redis），得自己加存在性检查或兜底逻辑。
