直接 fork 并替换包是解决上游不修问题的最可靠路径，但需绕过 composer 缓存、分支匹配和版本解析三道关：强制更新依赖、配置 "no-api": true、使用 dev-* 分支名、显式声明 type: "vcs" 或改用 path 类型仓库，并在 fork 的 composer.json 中正确设置 replace 字段以避免冲突。

直接 fork 并替换包，是解决“上游不修、我又不能等”的最可靠路径。它比 patch 更稳定，比改 vendor 更可持续——但 90% 的失败，不是因为不会 fork，而是没绕过 Composer 的缓存、分支匹配和版本解析三道关。

为什么 composer update 不拉你的新提交

Composer 默认缓存 Git 仓库的 commit hash，哪怕你 git push 了新代码，composer.lock 里仍锁着旧 commit，composer update 不会主动刷新。

• 执行 composer update vendor/package --with-dependencies 强制重走依赖解析流程
• 或删掉 composer.lock 后运行 composer install（仅限开发环境）
• 更彻底的方案：在 repositories 配置中加 "no-api": true，让 Composer 跳过 Packagist 元数据缓存，直连 Git 获取最新 refs

dev-* 分支名必须带前缀，且不能用 main 或 master 当版本号

Composer 对不稳定版本有默认策略：minimum-stability 设为 stable 时，main 这类分支名会被拒绝安装，即使你写了 "monolog/monolog": "main"。

Workflow Decomposer

工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。

下载

• 正确写法是 "monolog/monolog": "dev-fix-log-level"，且确保远程分支真实存在
• type: "vcs" 必须显式声明，否则 Composer 不会按 Git 仓库解析 URL
• 如果只是本地调试，优先用 path 类型仓库，完全跳过分支匹配逻辑，例如："type": "path", "url": "../my-monolog"

怎么确认 fork 真生效了

别只看 composer.json 写没写对，最终以 composer.lock 和 composer show 输出为准。

• 运行 composer show vendor/package，检查 source 字段是否指向你的 GitHub 地址
• 打开 composer.lock，搜索对应包，看 "source": { "url": "...", "reference": "..." } 里的 url 是不是你的 fork 地址
• 如果仍是原包地址，说明 repositories 未生效，或版本约束太宽（比如用了 ^3.0），导致 Composer 选了兼容的原包旧版而非你的分支

真正容易被忽略的是 replace 字段——如果你的 fork 本意是替代原包行为，必须在 fork 包自己的 composer.json 里加 "replace": { "original/package": "self.version" }，否则用户 require 原包和你的 fork 时，Composer 可能同时装上，引发命名空间冲突或类覆盖。