Composer中文镜像与Composer钩子(Hook)机制冲突分析-composer-PHP中文网

中文镜像导致钩子脚本找不到包的根本原因是镜像源返回的 packages.json 缺少 provider-includes 或元数据不全，使 composer 误判工具包未安装成功，实际 vendor/bin/ 文件存在但类加载失败。

composer中文镜像与composer钩子(hook)机制冲突分析

中文镜像导致钩子脚本找不到包二进制

不是镜像本身有问题，而是镜像源返回的 packages.json 缺少 provider-includes 或元数据不全，导致 Composer 误判某些工具包（如 php-cs-fixer、phpstan）未安装成功，实际 vendor/bin/ 下文件存在但依赖类加载失败。

常见错误现象：composer run-script fix 报 Class not found，但 ls vendor/bin/php-cs-fixer 确实存在；或 sh: php-cs-fixer: not found —— 这说明 shell 找不到可执行文件，根源是 Composer 没把包正确解压进 vendor/bin/，而原因常是镜像没同步完整 provider 数据。

确认镜像是否支持 provider-includes：私有 Satis 源必须生成 provider-includes 字段，否则每次拉全量 packages.json，体积大且易漏包
临时切回官方源验证：composer config repo.packagist composer https://packagist.org，再 composer install --no-cache
阿里云镜像（https://mirrors.aliyun.com/composer/）目前稳定支持 provider 分片，比已停更的 phpcomposer 镜像更可靠

钩子执行时机与镜像无关但常被误归因

post-install-cmd、pre-autoload-dump 等钩子是否运行，和用哪个镜像完全无关。它们只取决于 vendor/ 是否重建、composer.lock 是否变更、以及是否启用 --no-scripts。

真实场景里，开发者在 CI 中用了中文镜像后发现钩子不执行，其实是 CI 脚本里加了 --no-scripts，或者本地 vendor/ 已存在、composer.lock 未变，导致 Composer 直接跳过安装流程。

post-install-cmd 只在真正重装 vendor/ 时触发，不是每次 composer install 都跑
CI 默认常带 --no-scripts，需显式去掉或改用 composer install --no-interaction
检查 scripts 是否写在 composer.json 顶层，而非嵌套在 extra 或 autoload 下

镜像顺序配置错误引发钩子间接失效

当 "packagist.org": false 放在私有源前面，Composer 查完私有源没找到包，立刻碰到这个哨兵就终止，不再尝试其他源 —— 结果是某些钩子依赖的 CLI 工具根本没装上，脚本自然失败。

Discussion Composer

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

下载

这不是钩子机制出问题，而是依赖没拉下来。报错看起来像钩子崩了，实际是 vendor/bin/phpunit 根本不存在。

"packagist.org": false 必须放在 repositories 数组末尾，作为“兜底终止符”
两个私有源都声明支持同一包（如 monolog/monolog），Composer 只取第一个返回非空 {"packages":{}} 的源，后一个被忽略
用 composer install -v 观察日志里实际访问了哪些 URL，确认是否真走到了你期望的镜像地址