cweagans/composer-patches 是非原生插件，需显式安装并验证生效；补丁路径须相对项目根目录、格式须为标准 git diff；仅在 install/update 时对新下载包应用一次；远程补丁必须含 sha256 校验；补丁是临时方案，需定期清理。
cweagans/composer-patches 不是 Composer 原生功能，它只是个插件——没装它，extra.patches 配置完全被忽略，补丁根本不会动。
安装插件后必须确认是否生效
运行 composer require cweagans/composer-patches 后，别以为就完了。插件注册依赖 Composer 的插件机制，而某些环境（比如自定义 composer.json 中禁用了插件、或用了 --no-plugins）会导致它静默失效。
- 检查
vendor/cweagans/composer-patches是否存在 - 执行
composer install --verbose，看到Applying patch ...才算真正触发 - 如果只输出
Loading plugin ...但没后续 patch 日志，说明插件没在钩子中执行，可能是被其他插件拦截或配置冲突
补丁文件路径和格式必须严格匹配
extra.patches 里写的路径是相对于项目根目录的，不是 vendor/ 或补丁所在子目录；补丁内容也必须是标准 git diff 格式，否则应用会失败且错误信息极简（常只报 “failed to apply”）。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 生成补丁时，
cd vendor/your-vendor/your-package，改完后运行git diff --no-prefix > ../../patches/fix-xxx.patch - 避免用 IDE 直接对比生成 patch：容易带
a/src/和b/src/前缀，导致路径不匹配；加--no-prefix或配"level": 1可绕过，但不如源头干净 - 补丁第一行建议加注释，如
# Fix broken TTL validation in CacheItemPool，便于排查时快速识别意图
补丁不自动重应用，更新版本后大概率失效
composer-patches 只在 install 或 update 过程中对「新下载」的包执行一次 patch。已存在的 vendor/ 文件不会被重新打补丁，哪怕你改了 .patch 内容。
- 修改补丁文件后，必须删掉
vendor/+composer install，或加--with-all-dependencies强制重建依赖树 - 升级目标包版本后，原有补丁几乎必然失败——因为行号偏移、函数签名变化、甚至文件被删；得用新版本重新 checkout → 修改 →
git diff -
patches.lock.json会记录已应用补丁的哈希，但它不校验目标包版本，只防补丁文件被篡改；别把它当版本兼容性保障
远程补丁要加 sha256 校验，否则 CI 容易被劫持
从 GitHub Gist、私有 gist 或任意 URL 加载补丁时，composer-patches 支持 sha256 字段校验。不加的话，CI 流水线一旦网络中间人攻击或源站被黑，就会静默应用恶意 patch。
- 补丁配置写成：
"https://gist.githubusercontent.com/.../fix.patch": {"sha256": "a1b2c3..."} - 用
shasum -a 256 patches/xxx.patch生成本地校验值 - 远程补丁无法用
--no-interaction跳过校验，缺失sha256时会直接报错中断，这是安全设计，不是 bug
补丁永远是临时方案，最易被忽略的是：没人定期检查上游 PR 状态，也没人设自动化提醒该删补丁。一个放三个月没动的 patches/ 目录，往往意味着技术债已开始结块。
