composer依赖解析先构建约束图，再用回溯+启发式剪枝求解；下载器默认并发12个http任务；lock文件是解析快照，禁止手动编辑；插件不参与解析，仅在安装后触发事件。
Composer 依赖解析器怎么工作的
Composer 的依赖解析不是简单按顺序安装，而是先构建一个完整的约束图，再用回溯+启发式剪枝算法求解可行版本组合。它会把 composer.json 中所有 require、require-dev、conflict 等字段转为逻辑表达式，然后在已知包元数据（来自 packages.json 和 provider 文件）中搜索满足全部条件的版本集合。
常见错误现象包括：Dependency resolution failed、Could not find a version of package matching constraint。这类问题往往不是某一行写错了，而是多个包的版本约束存在隐式冲突——比如 A 要求 monolog ^2.0，B 要求 monolog ^3.0，而你又没显式指定 monolog 版本，Composer 就无法收敛。
- 运行
composer why-not vendor/package:version可定位阻塞来源 - 加
-v参数看详细解析日志，重点观察 “Resolving dependencies through SAT” 阶段的回溯尝试 - 避免在 root 包中硬写
"monolog/monolog": "3.0.0"这类精确版本，改用^3.0给解析器留余地
Composer 下载器如何并发处理 HTTP 请求
HttpDownloader 是实际发起网络请求的调度中心，默认最多并发 12 个任务（由 $maxJobs = 12 控制），每个任务对应一个包的 dist 或 source 下载。它不直接调用 cURL，而是通过 CurlDownloader 封装底层操作，并统一管理状态机：从 STATUS_QUEUED → STATUS_STARTED → STATUS_COMPLETED 或 STATUS_FAILED。
容易被忽略的是：并发数不是越大越好。在 CI 环境或低带宽机器上设太高反而触发限流或 DNS 超时；而某些私有仓库不支持并发访问，会返回 429 或连接重置。
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 可通过环境变量
COMPOSER_PROCESS_TIMEOUT和COMPOSER_HTTP_MAX_PORTS调整行为 - 调试时加
--no-cache可绕过 dist 缓存，强制走网络，便于复现下载问题 - 若遇到
CURLE_COULDNT_RESOLVE_HOST，优先检查~/.composer/auth.json中的仓库域名是否可解析，而非单纯调大重试次数
为什么 composer.lock 文件不能手动编辑
composer.lock 不是配置文件，而是依赖解析结果的快照，包含每个包的精确版本、完整哈希、源类型（dist/vcs）、以及嵌套依赖树的扁平化展开。它的结构与 composer.json 完全不同，且由 Locker 类严格生成，没有校验逻辑去验证人工修改后的合法性。
手动改 lock 文件最常导致的问题是：hash 不匹配触发 install 失败，或版本号与实际下载内容不一致造成运行时 class not found。
- 要升级某个包，用
composer update vendor/package，而不是改 lock - 想锁定子依赖版本？在
composer.json中显式 require 它，Composer 会自动同步进 lock - CI 流水线中必须校验
composer.lock是否被意外变更，可用composer install --dry-run检测差异
插件系统怎么影响依赖解析顺序
Composer 插件通过 EventDispatcher 注册监听器，在关键生命周期事件（如 PRE_AUTOLOAD_DUMP、POST_PACKAGE_INSTALL）中执行逻辑。但注意：插件代码本身**不参与依赖解析过程**，它只在解析完成、包已下载解压后才被加载。
这意味着，如果你的插件试图在 post-install-cmd 中动态修改 vendor/autoload.php 的生成逻辑，它不会改变当前 install 的包列表，但可能让后续 composer dump-autoload 失败——因为插件引入的新类路径还没被 autoload 规则覆盖。
- 插件的
activate()方法里不能调用Package或Repository相关类，它们此时还未初始化 - 想干预依赖选择？得用自定义
Repository实现，而不是插件 - 调试插件时，加
-vvv可看到事件触发顺序，确认你的监听器是否被注册成功
DependencyResolver 来调试依赖图——它被封装在 InstallationManager 内部，只响应命令行输入。真正能稳定介入的只有事件和插件钩子，其余都是黑盒。
