Composer安装前执行清理脚本的关键机制是pre-install-cmd事件，它在依赖解析完成、下载开始前运行，适合做环境清理，且仅在composer install时触发，需确保脚本可执行并路径正确。
Composer安装前执行清理脚本的关键机制是pre-install-cmd
Composer本身不支持“安装包前自动运行任意脚本”，但可通过事件钩子（event）在install或update命令触发前执行自定义逻辑。真正起作用的是pre-install-cmd事件——它在依赖解析完成、下载开始前运行，适合做环境清理。
注意：pre-autoload-dump或post-install-cmd都不符合“前置清理”要求：前者发生在自动加载生成阶段（太晚），后者已在安装完成后执行（无法影响本次安装行为）。
-
pre-install-cmd是唯一能在composer install实际拉取/解压包之前运行的钩子 - 该事件仅在运行
composer install时触发，composer update触发的是pre-update-cmd - 脚本必须声明为可执行（Linux/macOS）或通过
php显式调用（Windows兼容）
在composer.json中注册清理脚本的正确写法
直接在"scripts"下定义钩子，并确保路径可访问。推荐使用内联PHP或封装为独立文件：
{
"scripts": {
"clean-env": "php -r \"unlink('var/cache/prod') && mkdir('var/cache/prod', 0755);\"",
"pre-install-cmd": [
"@clean-env",
"rm -rf vendor/composer/installed.json"
]
}
}
说明：
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 多个命令可用数组形式并列，按顺序执行；失败会中断后续流程（符合“清理失败则不继续安装”的预期）
- 避免在
pre-install-cmd中调用composer dump-autoload等可能干扰依赖解析的操作 - Windows用户需改用
cmd /c del /q或统一用php脚本保证跨平台，例如：php scripts/clean.php
常见失败原因：权限、路径、执行时机错位
实际部署中pre-install-cmd静默跳过或报错，往往不是语法问题，而是环境约束未满足：
- 脚本路径不存在或无执行权限（Linux/macOS下
chmod +x必要） - 清理目标路径被其他进程占用（如正在运行的PHP-FPM缓存锁文件）
- 在CI/CD中以非交互模式运行时，
composer install --no-interaction仍会触发钩子，但某些shell内置命令（如source）不可用 -
pre-install-cmd不接收composer install --dry-run参数，但也不会执行真实安装动作——此时清理仍会发生，需注意副作用
替代方案：用composer create-project配合自定义脚本更可控
如果清理逻辑复杂（如清数据库、重置配置），pre-install-cmd容易失控。更稳妥的做法是绕过钩子，把清理作为独立步骤：
#!/bin/bash rm -rf vendor/ var/cache/ composer create-project --no-dev --prefer-dist myorg/myapp .
这种模式的优势：
- 完全掌握执行顺序和错误处理（比如用
set -e确保任一失败即退出） - 避免Composer事件系统对脚本输出、返回码的隐式处理（如忽略非零退出码）
- 可在Dockerfile或CI脚本中复用，不依赖
composer.json配置
钩子机制看似方便，但一旦涉及I/O密集型清理或外部服务交互，就容易变成调试黑洞——多数人卡住的地方，其实是没意识到pre-install-cmd运行在Composer内部进程里，而非你熟悉的shell上下文。
