Composer 只支持按包更新而非单个文件，应使用 composer update vendor/name 精确控制；手动删改 vendor 文件不可靠且易破坏依赖一致性。
composer update 只更新某个包，不是单个文件
Composer 本身不支持「更新单个文件」——它操作的是包（package），不是文件。你看到的 vendor/ 下某个具体文件（比如 vendor/foo/bar/src/Helper.php）被修改，通常是因为整个包升级了，或者你手动改了它（这很危险）。想“更新某个文件”，本质是得让 Composer 重新安装或升级它所属的包。
用 composer update 包名 精确控制范围
直接运行 composer update 会更新 composer.lock 中所有过时的依赖，风险高。要只动一个包，必须显式指定它的完整包名（vendor/name 格式）：
-
composer update monolog/monolog—— 只更新这个包及其满足版本约束的子依赖 -
composer update "guzzlehttp/guzzle:^7.0"—— 同时指定版本约束，防止意外升到 v8 - 如果该包被其他包强依赖（如
laravel/framework锁死了symfony/console的版本），composer update可能拒绝变更，需配合--with-all-dependencies
注意：composer update foo/bar 不会跳过 composer.lock —— 它仍会按 lock 文件里记录的约束解析，只是限制了作用域。
为什么不能靠删文件再 install 来“更新单个文件”
手动删除 vendor/foo/bar/src/Helper.php 再跑 composer install，不会恢复它——因为 install 只按 composer.lock 还原整个包，不会校验或修复单个文件缺失。更糟的是：
- 删错文件可能导致包无法 autoload，报
Class not found - 有些包含生成代码（如 protobuf 编译产物），删了源文件也没用，得重跑构建流程
- Git 会把
vendor/当作二进制目录忽略，手工改文件几乎无法追踪、不可复现
真要替换某个文件？优先走 patch 或自定义安装器
极少数场景（如临时绕过一个 bug），需要替换成自己改过的文件，正确做法不是动 vendor/，而是：
- 用
composer-patches插件打补丁：在composer.json里加"patches"字段，指向你的 diff 文件 - fork 原包 → 修改 → 在
repositories里声明 Git 地址 →"require"指向你的 fork 分支 - 写个简单的脚本，在
post-install-cmd/post-update-cmd钩子里自动覆盖文件（仅限 CI 或本地开发，别上生产）
这些方法都比直接编辑 vendor/ 下的文件靠谱得多，也留有记录和回滚路径。
真正容易被忽略的一点：Composer 的「更新」动作永远以包为单位，任何试图绕过这个模型去操作文件的想法，都会在下次 update 或 install 时失效，甚至破坏依赖一致性。
