打破版本僵局：通过Composer Fork机制临时修复第三方Bug

直接 fork 并替换包是解决上游不修问题的最可靠路径

当上游依赖包出现Bug却迟迟得不到修复时，直接fork并替换，无疑是解决“上游不修、我又不能等”困境的最可靠路径。这种方法比打补丁更稳定，也比直接修改vendor目录更具可持续性。然而，实践中超过九成的失败案例，根源往往不在于不会fork，而在于没能成功绕过Composer在缓存、分支匹配和版本解析这三道关卡。

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

问题常常从这里开始：Composer默认会缓存Git仓库的提交哈希值。这意味着，即使你已经git push了修复代码，项目中的composer.lock文件依然锁定着旧的提交记录，导致常规的composer update命令对此视而不见。

• 可以尝试执行composer update vendor/package --with-dependencies，强制Composer重新走一遍该包的依赖解析流程。
• 在开发环境中，一个更直接的方法是删除composer.lock文件，然后重新运行composer install。
• 若想一劳永逸，则可以在项目的composer.json文件repositories配置项中，为你的fork仓库添加"no-api": true。这个设置会让Composer跳过Packagist的元数据缓存，直接连接Git仓库获取最新的引用信息。

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

Composer对不稳定版本有一套默认的识别策略。当项目的minimum-stability设置为stable时，像main或master这样的分支名会被直接拒绝安装，即便你在依赖声明中明确写了"monolog/monolog": "main"也无济于事。

• 正确的写法应该是"monolog/monolog": "dev-fix-log-level"，并且务必确保远程仓库中存在这个同名分支。
• 在repositories中声明仓库时，type: "vcs"必须显式写出，否则Composer不会将提供的URL当作Git仓库来解析。
• 如果只是进行本地调试，优先考虑使用path类型的仓库。这种方式完全绕过了分支匹配的逻辑，配置起来也更简单，例如："type": "path", "url": "../my-monolog"。

怎么确认 fork 真生效了

配置写对了，不代表万事大吉。最终是否生效，还得看composer.lock和composer show的输出结果。

• 运行composer show vendor/package，仔细检查输出信息中的source字段，确认它指向的是你的GitHub fork地址。
• 打开composer.lock文件，搜索对应的包名，查看"source": { "url": "...", "reference": "..." }部分，其中的url必须是你fork的仓库地址。
• 如果这里显示的仍然是原始包的地址，那说明repositories配置并未生效，或者你设置的版本约束（比如^3.0）范围太宽，导致Composer最终选择了一个兼容的原始包旧版本，而非你的定制分支。

最后，还有一个真正容易被忽略的细节：replace字段。如果你的fork包本意是要完全替代原始包的行为，那么必须在fork包自身的composer.json文件中，添加"replace": { "original/package": "self.version" }声明。否则，当项目同时require原始包和你的fork包时，Composer可能会将两者都安装进来，从而引发命名空间冲突或不可预知的类覆盖问题。