yii老项目重构需分阶段：先升至yii 2.0.45以上，再以模块化、服务化方式渐进替换为yii 3；yii 1.1须经yii 2中转，yii 2到yii 3是解耦式重构而非升级。
Yii 适合老项目重构，但关键不在“能不能”，而在“怎么分阶段做”。直接从 Yii 1.1 跳到 Yii 3 是不可行的；而从 Yii 2 迁移到 Yii 3 也不是升级，而是架构重写。真正可行的路径是：先稳住 Yii 2，再以模块化、服务化方式逐步替换为 Yii 3 组件。
Yii 1.1 老项目必须先过 Yii 2 这一关
Yii 3 完全不兼容 Yii 1.1 的任何核心机制（如 CController、CHtml、Yii::app()），也没有提供直通迁移工具。官方和社区实践都明确要求：必须先把项目迁移到 Yii 2.0.x（建议 ≥2.0.45），验证功能完整、测试通过、性能达标后，才具备向 Yii 3 演进的基础。
- 命名空间全面补全：去掉所有
C前缀，加上use yii\web\Controller等语句 - 全局访问方式替换：
Yii::app()->db→Yii::$app->db，并检查组件是否已正确配置 - 视图层重构：用
yii\widgets\ActiveForm替代CActiveForm，用yii\helpers\Html替代CHtml - 数据库迁移同步：将
protected/migrations/下的CDbMigration类全部重写为继承yii\db\Migration，并用php yii migrate重新执行
Yii 2 到 Yii 3 不是升级，是解耦式重构
Yii 3 彻底抛弃了“应用实例+ServiceLocator”模式，转向 PSR-11 容器驱动、构造函数注入、中间件生命周期。这意味着你不能“改几行代码就跑起来”，而要重新设计依赖结构和服务装配方式。
- 删掉所有
Yii::$app->xxx写法，把所需服务（如LoggerInterface、DbConnection）作为构造参数显式声明 - 控制器不再继承
yii\web\Controller，而是普通 PHP 类，靠路由中间件绑定行为 - 原
components配置全部失效，改为config/common.php中的接口→实现映射，例如：LoggerInterface::class => ['class' => FileLogger::class] - 入口文件
web/index.php必须重写为 PSR-15 兼容格式，加载中间件栈而非Yii::createWebApplication()
推荐渐进式改造策略：微服务+API桥接
不建议一次性重写整个系统。更稳妥的做法是按业务域拆分，让新功能和核心模块优先用 Yii 3 实现，旧模块保持 Yii 2 运行，两者通过轻量协议通信。
- 识别高价值、低耦合模块（如用户中心、通知服务、支付网关），用 Yii 3 单独开发为独立服务
- Yii 2 项目通过 HTTP API 或消息队列（如 RabbitMQ）调用 Yii 3 服务，避免直接代码依赖
- 共用数据库时，注意事务边界：Yii 3 默认迁移开启事务，Yii 2 需手动
$this->db->beginTransaction() - 共享配置或领域模型？提取为独立 Composer 包（如
mycompany/domain），两套框架均可 require 使用
迁移中必须避开的硬性坑
有些限制不是“建议注意”，而是“踩中即失败”。部署前务必确认：
- PHP 版本必须 ≥8.2 —— Yii 3 大量使用构造器属性提升、联合类型、
#[Attribute]，PHP 8.1 及以下无法解析 - 不能保留
framework/或protected/目录结构，也不能复用 Yii 1.1 的index.php入口 - 数据库迁移不能混用：Yii 2 的
mYYYYMMDD_...文件不能直接扔进 Yii 3 的migrations/目录，必须重写为实现MigrationInterface的类 - 不要试图在 Yii 3 中“模拟”
Yii::$app—— 容器不支持全局单例注册，所有服务必须显式注入或通过容器获取
