为什么执行Composer install命令会覆盖本地手动修改的第三方包？-composer-PHP中文网

vendor目录是只读缓存，所有手动修改会在composer install/update时被覆盖；持久化修改必须通过path仓库或fork+vcs方式实现，而非直接编辑vendor文件。

为什么执行composer install命令会覆盖本地手动修改的第三方包？

vendor目录是只读缓存，不是工作区

Composer 把 vendor/ 当作纯输出目录，所有文件都由它控制生命周期。你手动改了 vendor/some/package/src/Helper.php，下次 composer install 或 composer update 时，它会按 composer.lock 里的哈希值校验、解压、覆盖——你的修改没被记录，自然就丢了。

常见错误现象：git status 在 vendor/ 下完全没反应；改完功能正常，一跑 composer update 就退回原版；CI 构建失败，因为别人机器上没你那几行 patch。

别在 vendor 里 git commit——它通常不是完整 Git 仓库（尤其 Packagist 包）
别依赖“我本地改了就行”——协作、部署、CI 全会翻车

想保留修改，必须让 Composer “认出”你的改动

真正能落地的方式只有两种：用 path 类型仓库，或 repositories + require 切换版本。

path 是最轻量的方案：把想改的包复制到项目外目录（比如 ./packages/my-fix），然后在根 composer.json 里加：

"repositories": [
  {
    "type": "path",
    "url": "./packages/my-fix"
  }
],
"require": {
  "vendor/package": "dev-main"
}

Composer 会软链接过去，改源码立刻生效，且不会被 composer update 覆盖。

Discussion Composer

围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par

下载

使用场景：调试第三方包逻辑、快速验证补丁、还没想好要不要提 PR 的临时修改
注意：url 是相对路径，CI 构建机必须能访问该路径，否则报 source does not exist
composer.lock 会记录这个 path 条目，但下次 composer update 可能把它替换成 Packagist 版本，悄无声息回退

长期修改必须走 Fork + VCS 仓库

如果你发现总要改某个包的逻辑，说明它要么设计不够扩展、要么确实有缺陷。这时应该：

先看包是否提供事件、hook、macro、service provider 或 contract 接口——比如 Laravel 的 Validator::extend()，优先走这些官方扩展点
如果必须改核心逻辑，Fork 该包到自己 GitHub/GitLab，打上语义化标签（如 v1.2.3-myfix），然后在 composer.json 里用 "vcs" 仓库引用你的 Fork
同步给上游提 PR，避免长期维护分支

别用 dev-main 这类开发分支别名“热修复”——它指向远程最新 commit，不是你本地改的代码，composer install 不会拉你本地 patch。