必须运行 composer update 才能使 composer.json 中新增/删除包、修改版本号、调整 stability 或 repositories 等变更生效，因为 install 仅按 lock 文件还原 vendor，不响应 json 变更。
不运行
会导致依赖不一致
手动改了
（比如增删
、调整版本号、修改
），只是“声明了意图”，Composer 并不会自动同步这些变更到
目录或
。实际加载的类、函数、文件路径，全由
里的代码决定——而它和
才是运行时的真实依据。
和
的根本区别
这两个命令行为完全不同，不能互相替代：
：只读取现有
，按锁文件精确还原
。即使你改了
，只要
没变，它就当没看见
：重新解析
，重新计算依赖树，更新
，并重写
如果你删了一个包但只跑
，那个包仍留在
里，autoload 依然能加载它——这会掩盖问题，甚至引发冲突
哪些修改必须触发
？
不是所有改动都需要，但以下情况跳过
就等于没生效：
新增或删除
/
中的包（如加了
）
修改已有包的版本约束（如从
改成
）
更改
或
，影响版本选择逻辑
添加或修改
（比如指向私有 Packagist），否则 Composer 根本找不到新源
反例：只改
、
、
的
映射路径（且未执行
）——这类改动不涉及依赖安装，但也要单独处理。
PHP 8.5.5
PHP 8.5.5 是 PHP 8.5 分支的维护更新版本。该版本延续了“小步快跑”的迭代逻辑，通过深度错误修复、底层性能微调以及安全加固，旨在为开发者提供一个更健壮、更高效的运行环境。该版本严格遵守语义化版本规范，不包含破坏性变更。
下载
容易被忽略的关键点
很多人以为改完
跑一次
就万事大吉，其实还有几个硬性条件：
必须可写，否则
会失败并报错
如果项目用了
部署，而你在
里加了东西，
时得显式加
或确保 dev 包被纳入计算
CI/CD 流程中，若先
再改
再
，很可能因缓存导致旧 lock 文件残留，建议清理
和
后重来
这条命令只更新指定包及其传递依赖，比全量
更可控，适合线上小范围调整。
最常出问题的地方，其实是改了
却忘了提交
—— 它才是团队协作中依赖一致性的唯一权威来源。
composer updatecomposer.jsonrequirerepositoriesvendor/composer.lockvendor/composer.lockcomposer installcomposer updatecomposer installcomposer.lockvendor/composer.jsonlockcomposer updatecomposer.jsonvendor/composer.lockinstallvendor/composer updateupdaterequirerequire-dev"phpunit/phpunit": "^10""guzzlehttp/guzzle": "^7.2""^7.5"minimum-stabilityprefer-stablerepositoriesnamedescriptionautoloadpsr-4composer dump-autoloadcomposer.jsonupdatecomposer.lockupdateCould not write lock filecomposer install --no-devrequire-devupdate--with-all-dependenciesinstalljsonupdatevendor/composer.lockcomposer update guzzlehttp/guzzle --with-all-dependenciesupdatecomposer.jsoncomposer.lock