psr/log 无需迁移，它只是接口契约；真正需升级的是日志实现库（如 monolog/monolog），其 composer.json 中对 psr/log 的版本约束决定实际安装版本。
psr/log 本身没有“版本迁移”这回事——它只是个接口契约，不提供实现，也不需要你主动升级。 真正要处理的，是依赖它的日志实现库（比如 monolog/monolog）及其对 psr/log 的版本约束变化。
为什么不能直接“迁移 psr/log”
因为 psr/log 是纯接口包：里面只有 LoggerInterface、LogLevel 这类空定义，没有任何逻辑或功能。Composer 安装它，只为了类型提示和自动加载支持。你手动 composer require psr/log，既不会增加日志能力，也不会影响运行时行为。
- 它被所有主流日志库（
monolog/monolog、php-di/php-di、slim/slim等）作为require声明自动拉取 - 它的版本号（如
1.0.0、2.0.0）仅表示接口契约变更（比如新增方法），但自 1.0 起已多年无破坏性更新 - 如果你看到
Class 'Psr\Log\LoggerInterface' not found，问题大概率出在 autoloader 没生效，而不是psr/log版本不对
实际要做的：检查并更新日志实现库
真正影响日志行为、兼容性和安全性的，是你项目里显式 require 的日志实现，比如 monolog/monolog。它的 composer.json 中声明了对 psr/log 的约束（例如 "psr/log": "^1.0 || ^2.0"），Composer 会据此选一个满足条件的 psr/log 版本安装。
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 运行
composer why psr/log查看哪些包在用它，重点关注第一级依赖（非dev区块里的） - 运行
composer show monolog/monolog（替换为你实际用的日志库名），看其requires字段里对psr/log的约束范围 - 如果想“升级 psr/log”，本质是让某个日志库升到支持更高版本的版本，比如从
monolog/monolog:^2.9升到^3.0（后者要求psr/log:^2.0） - 不要手动改
composer.json里"psr/log": "2.0.0"—— 这可能破坏其他包的兼容性，且 Composer 通常会拒绝安装
遇到 psr/log 版本冲突怎么办
典型错误信息：Conclusion: don't install psr/log 2.0.0 或 Root composer.json requires psr/log ^2.0, but that version is not installable。这不是 psr/log 本身的问题，而是你的某几个依赖对它提出了互斥要求。
- 先执行
composer prohibits psr/log:2.0，看哪些包阻止了该版本安装 - 常见组合：旧版
symfony/console（^5.4）锁死psr/log:^1.1，而新版monolog/monolog:^3.0要求^2.0 - 解法不是硬推
psr/log，而是统一升级“上游”：比如把symfony/console升到^6.4或^7.0（它们都支持psr/log:^2.0） - 若无法升级上游，可临时用
composer require --with-all-dependencies psr/log:^1.1强制降级，但需确认所有日志调用仍兼容（LoggerInterface::emergency()等方法在 1.x 和 2.x 中完全一致，一般安全）
最容易被忽略的一点：你根本不需要关心 psr/log 的具体版本号，只要确保你用的日志实现库是当前维护中的版本，并且所有直接依赖对它的约束能被 Composer 解出即可。它的存在意义，是让你的代码依赖接口而非实现——这点，在写 SDK、组件或测试 mock 时才真正体现价值。
