Composer 不支持内联 patch，必须使用 cweagans/composer-patches 插件配合独立 .patch 文件；插件仅识别 extra.patches 下的路径字符串，要求补丁为标准 git diff 格式、LF 换行、路径匹配 vendor 解压结构，且随包版本升级极易失效。
Composer 本身不支持内联 patch（比如在 composer.json 里直接写 diff 内容），所有“打补丁”动作都依赖外部工具，主流且唯一可靠的选择是 cweagans/composer-patches 插件——它不接受字符串 diff，只认独立的 .patch 文件。
为什么不能用内联 patch 或手动改 vendor
有人试图在 composer.json 的 extra 里塞一段 diff 文本，或直接编辑 vendor/ 下的文件，结果必被覆盖。原因很实在：
-
composer install和composer update默认把vendor/当作只读快照，任何手动修改都会在下次安装时丢弃 - Composer 不解析 JSON 中的文本 diff，
extra字段只是键值对容器，没有语法解释器 - 即使你用脚本把 patch 写进
composer.json，插件也根本不会读取——它只扫描extra.patches下的路径字符串
必须用 cweagans/composer-patches：装、配、验三步缺一不可
这个插件不是“装完就跑”，配置错一个字符或路径少一个点，补丁就静默失效。关键动作如下：
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 运行
composer require cweagans/composer-patches—— 注意不是--dev，它需在生产环境也生效 - 补丁描述必须是对象，不能是字符串：
"monolog/monolog": { "Fix truncate": "patches/monolog-truncate.patch" }才合法；写成"monolog/monolog": "patches/monolog-truncate.patch"会直接报错 - 补丁路径是相对于项目根目录的，
"patches/monolog-truncate.patch"就得真有这个文件，不能放在src/或vendor/里 - 验证是否真生效：删掉
vendor/和composer.lock，再跑composer install -v，搜索输出里有没有Applying patches for monolog/monolog
补丁文件格式和生成方式最容易翻车
90% 的 “failed to apply” 不是逻辑问题，是格式或路径错位。系统底层调用的是 patch 命令，对输入极其苛刻：
- 必须是标准
git diff格式，以diff --git a/src/Helper.php b/src/Helper.php开头；IDE 直接比对生成的带绝对路径 diff 会失败 - 路径前缀必须匹配 vendor 解压结构：修
guzzlehttp/guzzle，补丁里写src/Handler/CurlFactory.php，不是vendor/guzzlehttp/guzzle/src/Handler/CurlFactory.php - 换行符必须是 LF（Unix），Windows 的 CRLF 会导致崩溃；可用
file patches/*.patch检查 - 推荐生成方式：
cd vendor/guzzlehttp/guzzle && git diff --no-prefix > ../../patches/guzzle-curl-timeout.patch
补丁不是一劳永逸，版本一动就失效
补丁只在 composer install 或 composer update 下载新包时应用一次，已存在的 vendor/ 文件不会被重打。这意味着：
- 升级目标包版本后，几乎必然失败——函数签名变、文件删了、行号偏移，都导致 hunk rejected
-
composer.lock里只存补丁文件的 sha256（防篡改），不校验目标包版本兼容性 - 远程补丁（如从 GitHub Gist 加载）必须带
"sha256"字段，否则 CI 构建可能被中间人劫持 - 临时方案就是临时方案：补丁文件要加注释说明修复的问题和上游 PR 链接，方便后续清理
