Composer本身不支持发布补丁，只能通过提PR给上游或fork后配置vcs仓库提供可安装的新版本；extra.patches是项目级私有配置，不进lock文件、不上传Packagist，路径和环境依赖强，无法被他人复用。
Composer 本身没有“发布补丁”的功能 —— 你所谓“发布”，实际是两种互斥路径：要么把修改推给上游（提 PR），要么自己托管一个可安装的包版本（fork + vcs repo）。不存在把 patch 文件“发到 Packagist”这种操作。
为什么 extra.patches 配置不能被别人复用？
extra.patches 是项目级配置，只在你自己的 composer.json 里生效。它不进 composer.lock 的依赖图谱，也不上传到 Packagist，更不会随你的包一起被别人 require。别人 clone 你项目、删掉 vendor 后运行 composer install，若没装 cweagans/composer-patches，补丁直接被忽略；就算装了，路径错一个字符、换行符是 CRLF，照样失败。
- 补丁文件路径是相对你项目根目录的，别人项目结构不同，
patches/xxx.patch很可能根本不存在 - 插件版本不一致（比如对方用 v1.6，你用 v1.7）可能导致钩子注册失败
- 同一份补丁对不同版本的依赖包可能 hunk offset 偏移失效，而
extra.patches不声明适用版本范围
想让团队或下游稳定用上你的修复，必须走 fork + vcs 流程
这不是“绕路”，而是唯一能保证可复现、可版本化、可审计的方式。核心动作不是“打补丁”，而是“提供一个带修复的新包版本”。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- fork 目标包仓库（如
monolog/monolog→yourname/monolog） - 在 fork 里建新分支（如
fix-null-dereference），提交修复并 push - 在你自己项目的
composer.json顶层加repositories：
"repositories": [
{
"type": "vcs",
"url": "https://github.com/yourname/monolog"
}
]
- 把原
require改成指向该分支别名："monolog/monolog": "dev-fix-null-dereference as 2.10.0" - 删掉
vendor和composer.lock，再composer install
此时 composer show monolog/monolog 的 source 字段会显示你的 GitHub URL，而非 Packagist。
补丁内容怎么同步进 fork 并长期维护？
别把补丁当一次性快照。每次修复都应作为独立 commit 推到 fork 分支，并生成对应 Git tag（如 v2.10.0-patch1）。这样你能做到：
- 下游
require "monolog/monolog": "2.10.0-patch1"，无需as别名，语义清晰 - 后续上游合并 PR 后，你只需 rebase 分支、解决冲突、打新 tag，下游
composer update即可平滑升级 - 所有修改留痕在 Git 历史里，审计时直接看 commit diff，比翻 patch 文件可靠得多
真正容易被忽略的是：fork 分支的 composer.json 里 name 必须保持原样（monolog/monolog），否则 Composer 无法识别为同一包；而 version 字段可留空，Packagist 和 Composer 都以 Git tag 为准。
