直接改 vendor 代码行不通，因 Composer 安装依赖时会按 composer.lock 解压原始包覆盖所有修改；必须用 cweagans/composer-patches 插件，在 composer.json 的 extra.patches 中配置标准 git diff 格式补丁，通过 composer install/update 自动注入修改。
为什么直接改 vendor 里的代码行不通
改完 vendor 里某个包的 PHP 文件，下次 composer install 或 composer update 就会被覆盖——这是 Composer 的默认行为，不是 bug，是设计使然。硬改 vendor 目录等于把临时补丁当长期方案，上线后必然出问题。
composer-patches 插件怎么装和配
它本质是让 Composer 在安装/更新依赖时，自动对目标包打上你提供的 patch 文件。不是运行时劫持，而是构建时注入修改。
- 执行
composer require cweagans/composer-patches安装插件（推荐加--dev，补丁通常只在开发/部署阶段需要） - 在
composer.json的"extra"段里声明 patch 配置，格式必须严格：
"extra": {
"patches": {
"drupal/core": {
"Fix broken cache context": "patches/core-fix-cache-context.patch"
}
}
}
注意：key 是目标包名（vendor/name 格式），value 是 patch 文件路径（相对于 composer.json）；路径必须可读，且 patch 文件得是标准 unified diff 格式（git diff 生成的）。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
patch 文件怎么写才不被拒绝
常见失败原因不是语法错，而是上下文不匹配——Composer 打补丁时会校验文件头、行号、前后几行内容。一旦源码版本变了，旧 patch 就失效。
- 用
git diff从干净的包源码分支生成 patch，别手工写@@ -10,7 +10,7 @@这类行 - 补丁目标文件路径要跟包实际安装后的路径一致，比如想改
vendor/symfony/http-foundation/Request.php，patch 头部就得写--- a/src/Request.php（看包内实际结构，不是 vendor 下的绝对路径） - 避免跨大版本打 patch：symfony/http-foundation v5.4 和 v6.2 的
Request::getHost()实现可能完全不同，一个 patch 很难通用 - 测试时先手动
git apply --check your.patch，确认能过校验
打完补丁还报错？检查这三件事
最常卡在「明明 patch 成功了，但运行时还是老逻辑」，大概率是缓存或加载顺序问题。
-
composer dump-autoload -o：强制重生成 autoloader，尤其改了类方法签名或新增了类 - 清空 OPcache（如果启用了）：
opcache_reset()或重启 PHP-FPM，否则旧字节码还在内存里 - 确认没其他地方覆盖了行为：比如 Laravel 的服务容器绑定、事件监听器、中间件，可能绕过了你 patch 的核心方法
patch 不是魔法，它只改磁盘文件；运行时是否生效，取决于类是否被重新加载、有没有更高优先级的逻辑介入。这点容易被忽略，但恰恰是调试最耗时间的地方。
