pre-pool-create是唯一有效拦截点，因依赖解析在构建pool后即交由solver计算，此时修改约束或仓库可影响最终结果；其他事件如post-autoload-dump已无法改变解析逻辑。
能拦截依赖安装过程的 Composer Plugin 必须在 pre-pool-create 事件中修改请求约束或仓库，而不是在 install 阶段“事后补救”——后者根本来不及干预求解器行为。
为什么 pre-pool-create 是唯一有效的拦截点
Composer 的依赖解析流程是：先收集所有 require 条目 → 构建 Pool（可用包版本集合）→ 交给 Solver 计算满足约束的版本组合。一旦 Pool 构建完成，后续事件（如 pre-package-install）看到的已是确定版本，无法改变解析结果。
-
pre-pool-create是 Solver 开始前的最后钩子，此时$event->getRequest()暴露原始依赖项，可安全修改ConstraintInterface或注入临时ArrayRepository - 误用
post-autoload-dump或post-install-cmd做“版本修正”，只会导致已安装包与 lock 文件不一致，触发下次 update 异常 - 监听
COMMAND_RUN只能捕获命令名（如install），无法访问依赖图，属于粗粒度控制
如何在 onPrePoolCreate 中安全修改依赖约束
回调函数接收 PrePoolCreateEvent 实例，核心操作是遍历 $event->getRequest()->getRequirements() 并替换约束对象。直接赋值无效，必须调用 setConstraint()。
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 不要用字符串拼接构造新约束，应使用
Composer\Semver\Constraint\Constraint类（如new Constraint('==', '1.2.3')）保证格式合规 - 若需屏蔽某包的所有不稳定版本，可向
$event->getRepositories()插入一个过滤型FilterRepository，而非删除原仓库 - 修改后务必调用
$event->setRequest($modifiedRequest)，否则变更不生效（这是最常被忽略的一步） - 避免在循环中调用
$composer->getRepositoryManager()->repositories—— 它返回的是缓存副本，修改不影响当前事件
常见踩坑：插件被加载但事件不触发
现象是 activate() 执行了，但 onPrePoolCreate 完全没进断点。问题几乎都出在事件注册或 API 版本错配上。
- 确认
composer-plugin-api版本与当前 Composer 主版本严格匹配：composer --version显示 2.7.x 就必须用"composer-plugin-api": "^2.0"，不可写"^1.0" - 监听器注册必须在
activate()内完成，且签名要完全一致：$eventDispatcher->addListener('pre-pool-create', [$this, 'onPrePoolCreate'])，注意事件名是字符串，不是常量 - 插件类未被 autoload：检查
composer.json的autoload是否覆盖src/，运行composer dump-autoload -vvv看是否报 “Class not found” -
pre-pool-create仅在install和update时触发，require命令默认不走完整解析流程，测试时要用composer update --dry-run
生产环境必须验证的边界情况
看似简单的约束重写，在复杂项目里极易引发死锁或无限递归，尤其当多个插件同时介入时。
- 遇到
minimum-stability: dev项目，你的插件强制将dev-main替换为 commit hash 后，需同步检查该 commit 是否存在于目标仓库 —— 否则 Solver 会静默跳过并尝试下一个版本 - 若插件向
Pool注入虚拟包（如提供本地调试版monolog/monolog），必须确保其getName()与真实包完全一致，大小写、连字符都不能差 - 性能敏感场景下，避免在
onPrePoolCreate中执行远程 HTTP 请求或文件扫描；所有元数据应预加载或缓存 - 调试时加
-v参数，重点观察日志中 “Reading composer.json of …” 和 “Resolving dependencies through SAT” 之间的部分，那里才是你的修改生效区
