为什么手动修改了Composer.json后必须运行Composer update？

必须运行 composer update 才能使 composer.json 中新增/删除包、修改版本号、调整 stability 或 repositories 等变更生效，因为 install 仅按 lock 文件还原 vendor，不响应 json 变更。

不运行 composer update 会导致依赖不一致

手动改了 composer.json（比如增删 require、调整版本号、修改 repositories），只是“声明了意图”，Composer 并不会自动同步这些变更到 vendor/ 目录或 composer.lock。实际加载的类、函数、文件路径，全由 vendor/ 里的代码决定——而它和 composer.lock 才是运行时的真实依据。

composer install 和 composer update 的根本区别

这两个命令行为完全不同，不能互相替代：

• composer install：只读取现有 composer.lock，按锁文件精确还原 vendor/。即使你改了 composer.json，只要 lock 没变，它就当没看见
• composer update：重新解析 composer.json，重新计算依赖树，更新 vendor/，并重写 composer.lock
• 如果你删了一个包但只跑 install，那个包仍留在 vendor/ 里，autoload 依然能加载它——这会掩盖问题，甚至引发冲突

哪些修改必须触发 composer update？

不是所有改动都需要，但以下情况跳过 update 就等于没生效：

• 新增或删除 require / require-dev 中的包（如加了 "phpunit/phpunit": "^10"）
• 修改已有包的版本约束（如从 "guzzlehttp/guzzle": "^7.2" 改成 "^7.5"）
• 更改 minimum-stability 或 prefer-stable，影响版本选择逻辑
• 添加或修改 repositories（比如指向私有 Packagist），否则 Composer 根本找不到新源

反例：只改 name、description、autoload 的 psr-4 映射路径（且未执行 composer dump-autoload）——这类改动不涉及依赖安装，但也要单独处理。

容易被忽略的关键点

很多人以为改完 composer.json 跑一次 update 就万事大吉，其实还有几个硬性条件：

• composer.lock 必须可写，否则 update 会失败并报错 Could not write lock file
• 如果项目用了 composer install --no-dev 部署，而你在 require-dev 里加了东西，update 时得显式加 --with-all-dependencies 或确保 dev 包被纳入计算
• CI/CD 流程中，若先 install 再改 json 再 update，很可能因缓存导致旧 lock 文件残留，建议清理 vendor/ 和 composer.lock 后重来

composer update guzzlehttp/guzzle --with-all-dependencies

这条命令只更新指定包及其传递依赖，比全量 update 更可控，适合线上小范围调整。

最常出问题的地方，其实是改了 composer.json 却忘了提交 composer.lock —— 它才是团队协作中依赖一致性的唯一权威来源。