直接改 vendor 代码会绕过 Composer 依赖管理，导致本地可运行但上线被覆盖、无法追溯、不进 Git 历史，且 autoload 可能失效；应使用 composer-patches、fork 私有仓库或 replace 等合规方案替代。
直接改 vendor 里的代码，等于绕过 Composer 的整个依赖管理机制——它不会记录、不会校验、不会同步，下次 composer install 或 composer update 就会被原样覆盖，且无法追溯变更来源。
为什么改 vendor 代码后本地能跑，上线就报错
因为 vendor 是安装产物，不是源码目录。Composer 只保证它和 composer.lock 一致，不保证你手改的内容被保留或生效：
- CI/CD 流水线执行
composer install时，会完全清空并重装vendor，你本地改的任何文件都会消失 - Git 不该提交
vendor（除非极特殊场景），所以你的修改根本不会进版本历史，别人 clone 后完全不知道有这层 patch - 某些包含 autoloader 生成逻辑（如 Laravel 的
classmap），手动改文件后没重新 dump autoload，类可能根本加载不到
临时调试时怎么安全打补丁
真要改第三方行为，优先走 Composer 原生支持的补丁路径，而不是硬编码：
- 用
composer-patches插件：在composer.json里声明 patch 文件路径，它会在 install/update 时自动应用，并计入 lock 文件 - fork + 修改 + 指向私有 Git 仓库：
"vendor/package": "dev-fix-branch#commit-hash"，再通过repositories配置源，可 review、可复现 - 对少量类做运行时替换：用
class_alias()或 PSR-4 映射覆盖（仅限非 final 类），但需确保 autoloader 加载顺序可控
长期维护必须用替代方案
手改 vendor 是技术债黑洞，真正可持续的做法是把“不得不改”的逻辑收归己有：
- 提取公共逻辑为独立小包，发布到私有仓库，用
replace声明替代原包（如"monolog/monolog": "self.version"） - 用
conflict封杀掉有问题的版本范围，再配合require指定已验证兼容的稳定版 - 若原包无维护，且改动量大，建议 fork 后发布新包名（如
acme/monolog-fork），并在replace中明确替代关系
最常被忽略的一点：vendor 目录本身没有版本语义，它只是某次 composer install 的快照结果。所有对它的直接操作，本质上都是在对抗工具的设计契约。
