composer检测到vendor中任何手动修改即报错中断，这是保护机制而非bug；必须用--discard-changes强制还原，或改用fork、补丁、继承等可维护方案替代直接修改。
Composer 不允许、也不支持在 vendor 中手动修改代码后还“安全保留”——它要么报错停住，要么强制丢弃，没有中间态。 所有想“更新依赖又不丢我改的那几行”的尝试，本质都是在对抗 Composer 的设计逻辑。真要长期生效，必须把修改移出 vendor 目录。
vendor 里改了文件，composer install 就卡住？这是保护，不是 bug
只要 vendor/package-name 下存在未提交的 Git 更改（哪怕只是改了个 README.md），composer install 就会中断并提示类似：
Changed files in vendor/package-name will be discarded. Use --force to overwrite.
这不是偶然故障，是 Composer 主动检测并阻止你陷入“一半更新一半旧代码”的混乱状态。此时：
- 不加
--discard-changes或--force，命令不会继续 -
composer dump-autoload或composer clear-cache完全无效——它们不碰 vendor 文件内容 - 删掉整个
vendor/再重装，比带--discard-changes慢得多，且丢失所有已安装的优化（如 classmap 缓存）
想保留修改？别改 vendor，改你的 composer.json
真正可维护的做法，是让修改本身成为依赖声明的一部分：
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 用
"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 怎么处理它，而在于你最初为什么需要改它——是接口缺失？是配置不够灵活？还是没找到正确的扩展点？从根上重构调用方式，远比给 vendor 打补丁更可持续。
