从 yii 1.1 到 yii 3 需经 yii 2 中转，不可直连；yii 2 迁移需处理命名空间、全局访问、表单视图及数据库迁移；yii 3 是架构级重构，强调 psr 标准、di 容器与显式配置，并建议渐进式微服务化过渡。
从 Yii 1.1 直接跳到 Yii 3 并不是“升级”，而是彻底重构——中间隔了 Yii 2 的完整重写，而 Yii 3 又在 Yii 2 基础上做了更激进的解耦。所谓“平滑过渡”不是一步到位，而是分阶段、有策略地演进。
先过 Yii 2 这关是硬前提
Yii 3 不兼容 Yii 1.1 的任何核心语法（比如 CController、CHtml、Yii::app()），也不兼容 Yii 2 的部分运行时约定（如应用结构、自动加载逻辑）。官方从未提供 Yii 1.1 → Yii 3 的直通路径。必须先把项目迁移到 Yii 2.0.x（推荐 ≥2.0.45），验证功能、测试覆盖率达标后，再评估是否升级到 Yii 3。
- 重点处理命名空间：所有类名去掉 C 前缀，补全 use 语句（如 yii\web\Controller）
- 替换全局访问方式：Yii::app() 全部改为 Yii::$app，同时检查 request、user、db 等组件调用是否适配
- 重写表单与视图：ActiveForm 替代 CActiveForm，Html helper 替代 CHtml，布局靠 findLayoutFile() 动态解析
- 迁移数据库：用 yii migrate 工具替代 yiic migrate，注意 migration 类继承 yii\db\Migration 而非 CDbMigration
Yii 2 到 Yii 3 是架构级切换
Yii 3 不是 Yii 2 的增强版，而是以 PSR 标准为骨架、DI 容器为核心的新框架。它不再强制 MVC 结构，也不内置 Web 应用模板；你得自己组合组件（router、view、response 等）。
- 放弃“全栈捆绑”思维：Yii 3 没有默认的 web 应用入口或控制器基类，需手动装配中间件链和请求处理器
- 依赖注入成为主线：所有服务注册、实例化都通过 yiisoft/di 容器完成，构造函数参数、接口绑定、作用域配置都要重设计
- 移除隐式约定：比如不再自动加载 @app/views 下的视图，不再默认扫描 controllers 目录；路径、命名、生命周期全部显式声明
- HTTP 抽象层标准化：Request/Response 使用 PSR-7 或 PSR-17 接口，与 Guzzle、Slim 等生态工具天然兼容
过渡期建议采用渐进式剥离
不建议重写整个系统。可选取非核心模块（如后台统计、导出服务、通知中心）作为试点，用 Yii 3 新建独立微服务，通过 API 与原有 Yii 2 主应用通信。
- 共用数据库但分离业务逻辑：Yii 3 服务只读取或写入特定表，避免事务跨框架
- 复用认证体系：将 Yii 2 的 user component 封装成标准 PSR-15 中间件，供 Yii 3 路由链调用
- 静态资源与路由解耦：前端统一走 Nginx 分流，/api/v3 → Yii 3，/admin → Yii 2，降低用户感知
- 逐步迁移模型层：把 ActiveRecord 拆成纯数据对象（DTO）+ 数据访问层（DAO），为两边共用打基础
工具与生态准备不能省
Yii 3 对开发习惯要求更高，提前铺好基础设施比代码迁移本身更重要。
- 必须用 Composer 管理依赖：所有包（包括核心组件）都按语义化版本单独 require，禁用“全量安装”
- 单元测试要覆盖 DI 配置：用 PHPUnit + Mockery 验证容器能否正确解析接口与具体类
- 日志与错误处理标准化：接入 Monolog，统一用 PSR-3 LoggerInterface，避免 Yii 2 的 CLogRouter 遗留
- CI/CD 流程适配：迁移脚本、数据库初始化、环境变量注入需重写，尤其注意 Docker 中 TTY 和 STDIN 处理
