composer update vendor/package-name 可精准只更新指定包及其满足约束的依赖，无需删包或改配置；但需注意 lock 文件完整性、php/扩展兼容性及子依赖显式锁定。
composer update 只更新一个包，不是靠删掉其他包
直接运行 composer update vendor/package-name 就行，不需要修改 composer.json 或手动删锁文件。Composer 会自动比对 composer.lock，只拉取该包及其满足版本约束的依赖树，其他包保持原版本不动。
常见错误是以为要先 composer remove 再 require —— 这样会触发整棵树重解析，极可能连带升级间接依赖，完全违背“仅更新一个”的目标。
- 必须用完整命名格式：
vendor/name，比如monolog/monolog，不能只写monolog - 如果包名拼错，Composer 不报错，而是静默执行全量 update（因为没匹配到任何已安装包）
- 该命令仍会检查并更新该包的子依赖（如
package-a依赖package-b ^2.0，而 lock 里是 2.1，但新版本 2.3 可用，就会升），这是正常行为，不是 bug
想锁死子依赖？得改 composer.json 的 require-dev 或 replace
默认情况下，composer update vendor/package 允许其传递依赖升级到符合约束的最新版。如果你发现某个次要依赖意外升级导致兼容问题，说明它没被显式锁定。
真正能控制子依赖版本的，只有两种方式：
- 在
composer.json的require中显式声明那个子依赖（例如你更新guzzlehttp/guzzle，但它带进来的psr/http-client出了问题，就加一行"psr/http-client": "1.0.1"） - 用
replace段阻止特定包被安装（慎用，容易引发冲突） - 不推荐用
composer update --with-dependencies：它反而会扩大升级范围，和目标相反
更新失败时先看 composer.lock 是否被污染
执行单包 update 却提示一堆冲突或回退到旧版本？大概率是 composer.lock 里残留了已被删除包的记录，或存在手动编辑痕迹。
Composer 在单包模式下仍依赖 lock 文件做版本锚点，一旦其中某条记录损坏（比如字段缺失、缩进错乱、含不可见字符），它会降级为宽松解析，行为变得不可预测。
- 用
composer validate --strict快速检测 lock 文件合法性 - 若验证失败，别手修，直接删掉
composer.lock和vendor/，再跑一次composer install恢复干净状态 - CI 环境中建议加校验步骤，避免因 lock 文件不一致导致本地能过、流水线失败
PHP 版本或平台配置不匹配会导致单包 update 静默跳过
运行 composer update foo/bar 后发现版本没变，也无报错？检查当前环境是否满足该包的 php 或 ext-xxx 要求。
Composer 在解析可用版本时，会过滤掉所有不兼容当前平台的候选版本。如果最新版要求 PHP 8.2，而你本地是 8.1，它就只能选上一个兼容的旧版——甚至可能就是 lock 里已有的那个。
- 用
composer show foo/bar查看所有可用版本及其 platform constraints - 用
composer config platform.php 8.2可临时模拟高版本（仅用于调试，勿提交到项目配置） - 扩展缺失（如
ext-intl）也会触发同样逻辑，php -m和composer show --platform要对照着看
