composer没有分支热修复机制，“秒级热修复”是误传；真实可行的是fork+path repository临时替换（风险极高）或cweagans/composer-patches插件（需严格约束）。
Composer 本身没有“分支机制”用于热修复——所谓“秒级热修复”是误传，真实可行的是 fork + path repository 临时替换，但风险极高，不建议直接用于线上。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
为什么不能用 Composer 的 branch 名字做热修复
很多人看到 composer require vendor/package:dev-main 或 "dev-develop" 就以为能切分支打补丁，其实这根本不是热修复：
- dev-main 是开发分支别名，指向的是远程 Git 分支的最新 commit，不是你本地改的代码
- 每次 composer update 都会拉取远程最新，你本地的修改会被覆盖
- composer install 不会重新 clone，只解压已缓存的 zip 包，你的 patch 根本进不去 vendor/
- 即使配了 "minimum-stability": "dev"，也解决不了“如何让线上立刻跑你刚改的那三行”的问题
path repository 看似简单，但线上用等于埋雷
这是目前唯一能让 vendor/ 里跑你本地代码的方式，但必须清楚代价：
- "repositories": [{"type": "path", "url": "./patches/my-fix"}] 必须写在根 composer.json 里，且 url 是相对路径
- CI 构建机找不到 ./patches/my-fix，直接报 source does not exist
- composer.lock 会记录这个 path 条目，但下次 composer update 可能把它替换成 packagist 版本，悄无声息回退
- 所有同名包（比如两个不同组件都依赖 monolog/monolog）都会被强制走这个 path，可能误伤其他模块
- 无法做灰度——要么全量切，要么全量不切，没中间态
真正能上线用的临时方案只有 patch 插件 + 严格约束
用 cweagans/composer-patches 是唯一被生产环境验证过的折中路径，但必须满足以下条件：
- 补丁文件是标准 git diff -u 输出，含 --- a/src/... 和 +++ b/src/...
- "patches" 字段写在项目根 composer.json，不能写在被 patch 的包内部
- 补丁路径相对于项目根目录，例如 "monolog/monolog": {"patches/monolog-fix-null-deref.patch"}
- 每次 composer install --no-interaction --verbose 必须进 CI 流水线，否则失败静默
- 补丁只是过渡，必须同步提 PR 给上游，并在 composer.json 注释里写明 "TODO: remove after monolog 2.12.1"
线上热修复最危险的错觉，就是以为改完 vendor/ 里的文件就能生效。只要没进 composer.lock 的确定性链条，就随时可能被覆盖、被忽略、被构建机丢弃。真正的“秒级”，只存在于本地调试；上线的每一步，都得靠锁文件、CI 验证和明确的生命周期标注来兜底。
