结论：composer update vendor/package 可只更新单个包，但需确保其未被依赖约束锁死；若被其他已安装包强制限定版本，则命令静默失败，不报错也不升级。
直接说结论：用 composer update vendor/package 可以只更新单个包，但必须确保它没被其他已安装包的依赖约束锁死。
为什么 composer update vendor/package 有时不生效？
Composer 不是“想更新谁就更新谁”，它得尊重 composer.lock 里已解析出的依赖图。如果当前已安装的某个包（比如 monolog/monolog）强制要求 psr/log 必须是 ^1.0，而你想更新的 psr/log 新版是 ^2.0，那命令会静默失败——不是报错，而是压根不升级。
- 检查是否真被锁住：
composer depends psr/log（看谁依赖它） - 确认目标包在
composer.json中是否显式声明（没声明时，仅靠依赖链引入的包不能被单独 update） - 运行时加
-v参数，看 Composer 输出的 “Skipping” 或 “Not in require section” 提示
composer update 单包时的参数陷阱
别加 --with-dependencies 除非你明确要连带升级它的子依赖——这会让行为变成“半全局更新”，容易意外升级其他包。默认不加任何 flag 才是最安全的“仅本包”策略。
- 正确写法：
composer update doctrine/dbal - 危险写法：
composer update doctrine/dbal --with-dependencies（可能顺手把symfony/console也升了） - 如果提示 “Package not found”，先确认名字拼写，再查
composer show输出列表里是否存在该包
更新后 composer.lock 会怎么变？
只有被更新的包及其直系依赖（且未被其他包约束的）版本号会变，composer.lock 的哈希值一定更新，但改动行数通常很少——这是判断是否“真只更了单个包”的最快方式。
- 执行后立刻
git diff composer.lock，聚焦看packages和packages-dev下对应区块 - 如果发现一堆 unrelated 包的版本都变了，大概率是某条依赖路径松动了，或你本地
composer.json的minimum-stability设置太宽 - 生产环境务必提交更新后的
composer.lock，否则别人install时不会拿到你刚更新的版本
真正难的不是敲那条命令，而是搞清当前 lock 文件里到底是谁在卡着版本——有时候删掉 vendor 和 composer.lock 重来，反而比硬调一个包更快。
