不能。Composer 不支持按 PHP 命名空间更新包，仅能按 package name（如 monolog/monolog）或 vendor 前缀（如 myorg/*）更新，其依据是 composer.json 中声明的依赖项，而非运行时命名空间。
Composer 能不能只更新某个命名空间下的包？
不能。Composer 本身没有「按命名空间更新」的原生能力。composer update 操作始终基于 composer.json 中声明的依赖项（即 package name，如 monolog/monolog），而不是 PHP 命名空间（如 Psr\Log 或 MyApp\Services）。命名空间是运行时逻辑组织方式，Composer 在安装/更新阶段根本不解析 PHP 文件内容。
想局部更新，实际能操作的最小单位是什么？
是具体的 package name，也就是 vendor/name 格式的包标识符。你可以精确指定一个或多个包来更新：
-
composer update monolog/monolog—— 只更新这一个包及其满足约束的子依赖 -
composer update doctrine/dbal symfony/console—— 同时更新多个明确列出的包 -
composer update "myorg/*"—— 使用通配符匹配 vendor 名称（需 Composer 2.2+，且仅限于 root package 的 require 中实际存在的包）
注意："myorg/*" 不会扫描所有已安装包再筛选命名空间，它只是把 composer.json 中所有 vendor 为 myorg 的条目展开后执行更新 —— 如果某个 myorg/foo 并没被 require，它不会被触碰。
为什么有人误以为“按命名空间更新”可行？
常见混淆来源有三个：
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 看到某些私有包的命名空间统一（如
acme/core、acme/api-client、acme/utils），就以为能用acme/*批量更新——其实靠的是包名前缀一致，不是命名空间 - 在 IDE 或静态分析工具里看到
use Acme\Core\Something;，误把Acme\Core当作可操作单元；但 Composer 看不到use语句 - 执行
composer update --dry-run后发现一堆包被标记为“将更新”，误以为可以按 PSR-4 映射路径过滤——但 dry-run 结果由依赖图决定，不是文件路径
真正影响更新行为的只有：当前 composer.json 的 require / require-dev、锁文件 composer.lock 记录的版本、以及各包 composer.json 中声明的 autoload 和 replace 字段。
如果真要控制某组功能模块的更新节奏，有什么务实做法？
把逻辑相关、生命周期相近的代码拆成独立 Composer 包，并统一 vendor 名称或命名规范，是最可控的方式：
- 比如把所有日志相关封装为
myapp/logger、myapp/log-driver-sentry，然后用composer update myapp/logger myapp/log-driver-sentry - 在 CI 流程中，用脚本提取
composer show --direct输出，按 vendor 过滤出目标包列表再拼接命令 - 避免在主项目中直接 require 大量细粒度包；否则局部更新会变得难以维护和验证兼容性
硬要从 PSR-4 自动推导包名？不推荐。因为同一个命名空间可能跨多个包，也可能一个包导出多个命名空间——这种映射关系不在 Composer 的职责范围内，强行桥接只会增加不可靠的解析逻辑。
