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