Composer检测到vendor中未提交修改即中止命令，这是主动保护机制；必须用--discard-changes强制还原，或改用fork、补丁、继承等可维护方案替代直接修改。
Composer 不会“不小心”删你改的代码，它一发现 vendor 里有未提交修改，就立刻中止命令——这是主动保护，不是误操作。
vendor 里改了文件，composer install 就卡住？这是保护，不是 bug
只要 vendor/package-name 下存在任何未提交的 Git 更改（哪怕只是改了个 README.md），composer install 就会中断并提示类似：
Changed files in vendor/package-name will be discarded. Use --discard-changes to overwrite.
这不是偶然故障，是 Composer 主动检测并阻止你陷入“一半更新一半旧代码”的混乱状态。此时：
- 不加
--discard-changes或--force，命令不会继续 -
composer dump-autoload或composer clear-cache完全无效——它们不碰 vendor 文件内容 - 删掉整个
vendor/再重装，比带--discard-changes慢得多，且丢失所有已安装的优化（如 classmap 缓存）
--discard-changes 是什么，不是什么
这个参数不是开关，而是明确指令：丢弃所有本地修改，按 composer.lock 完整恢复。
-
composer install --discard-changes：最常用，不改 lock，只重置 vendor 文件 -
composer update --discard-changes：先更新依赖再丢弃修改——会改composer.lock，慎用 -
--discard-changes不等于rm -rf vendor && composer install。它内部做的是 per-package diff + reset，更快、更精准，且保留 autoload 缓存结构
想保留修改？别改 vendor，改你的 composer.json
真要长期生效，必须把修改本身变成可版本化、可复现的声明：
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 用
"repositories"指向你 Fork 后的仓库："type": "vcs", "url": "https://github.com/yourname/package"，再把require改成"vendor/package": "dev-main" - 用
cweagans/composer-patches插件管理补丁：把改动导出为my-fix.patch，写进extra.patches配置，每次install自动打上 - 如果是类行为调整，优先继承或装饰——新建一个
MyCustomService类，覆盖需要的方法，再通过容器绑定替换原服务
这三者都确保修改可版本化、可复现、可审计，而不是藏在 vendor/ 里等下次 install 时突然消失。
"discard-changes": false 配置能帮你“防误操作”，但救不了修改
可以在 composer.json 的 config 段加上：
"discard-changes": false
效果是：一旦检测到 vendor 有未提交更改，就立刻报错退出，不给你任何机会“误点回车”。但它不会保存你的修改，也不会告诉你该把哪几行代码提成 patch。它只是一道闸门，提醒你“这里有问题，得人工介入”。
CI 环境中建议开启，避免缓存 vendor 导致补丁静默失效。
最常被忽略的一点：所谓“本地修改”，90% 都不该出现在 vendor 里。问题不在 Composer 怎么处理它，而在于你最初为什么把它放进去。
