composer 的自定义事件监听本质是钩子而非拦截器，无法阻止依赖安装或中断核心流程，仅能在 pre-install-cmd 和 post-update-cmd 等生命周期中做校验与告警，真正拦截需依赖外部机制如 ci 检查和 git hooks。
Composer 的自定义事件监听机制本质是钩子，不是拦截器
Composer 没有提供类似「阻止依赖安装」「拦截 require 执行」的拦截能力。所谓“拦截非常规修改”，实际只能在 pre-install-cmd、post-autoload-dump 等生命周期事件中做检查或补救，无法中断 Composer 自身流程。一旦 composer install 开始执行，核心逻辑（如包下载、解压、autoloader 生成）不可取消。
常见误判场景包括：想阻止开发者手动修改 vendor/ 下文件、禁止非 composer require 方式引入包、拦截 composer update 时的版本降级——这些都无法靠事件监听真正“拦截”，只能事后告警或还原。
用 pre-install-cmd 和 post-update-cmd 做变更前/后校验
这两个事件最接近“拦截意图”：前者在依赖操作开始前触发，后者在完成之后。适合做一致性检查，比如验证 composer.lock 是否被绕过修改、检测 vendor/ 是否存在未声明的文件。
-
pre-install-cmd脚本里可读取composer.lock的 Git HEAD 版本，对比当前是否 dirty；若 dirty 且非 CI 环境，可exit 1中断命令（注意：这会终止整个composer install，但不阻止用户删掉 lock 文件重来） -
post-update-cmd可调用composer show --installed --format=json获取当前已装包列表，与预期白名单比对，发现未声明包就发通知或写日志 - 避免在事件脚本里执行耗时操作（如全量扫描
vendor/），否则会拖慢日常开发；建议只检查关键路径，如vendor/autoload.php是否被篡改、vendor/bin/下是否有非 Composer 安装的二进制
scripts 配置里不能直接 hook 到 require 或 update 的内部逻辑
很多人试图在 composer.json 的 scripts 里覆盖 require，写成 "require": "php ./check-before-require.php && composer require" —— 这看似拦截，实则脆弱：
- 用户仍可绕过：直接运行
composer require --no-scripts，或用composer exec、第三方插件 - 无法捕获
composer update foo/bar这类带参数的子命令，因为scripts不解析参数，只是字符串替换 - Composer 8+ 对脚本执行权限更严格，默认禁用
include类动态加载，eval()或反射调用内部类会直接报错Class 'Composer\Package\Link' not found
真要限制非常规修改，得靠外部机制配合
仅靠 Composer 事件做不到权限控制或强制合规。可行组合方案：
- CI 流水线中，在
composer install前加一步：git diff --quiet composer.lock || (echo 'lock file changed without composer'; exit 1) - Git hooks（如
pre-commit）检查vendor/是否被提交，或composer.json与composer.lock版本是否匹配 - 用
composer global require symfony/thanks这类全局工具没用——它不参与项目级约束；真正有效的只有项目级scripts+ 外部检查 + 团队约定
最常被忽略的一点：Composer 事件脚本本身也是代码，如果它依赖的 PHP 扩展（如 json、mbstring）缺失，事件会静默失败，而主命令照常执行。务必在脚本开头加 function_exists('json_encode') 类校验。
