Yii1.1、Yii2.0和Yii3.0是三个互不兼容的框架版本，不能混用——不是容易出错，而是根本无法运行，因底层设计、PHP版本要求（分别对应PHP5.2+、7.1+/7.4+、8.2+）、依赖管理、对象生命周期及核心API存在本质断裂，混用将导致解析失败、类找不到或语法报错。
Yii1.1、Yii2.0 和 Yii3.0 是三个互不兼容的框架版本，**不能混用**——不是“容易出错”，而是“根本无法运行”。它们在底层设计、PHP 版本要求、依赖管理、对象生命周期和核心 API 上存在本质性断裂。强行混用会导致 PHP 解析失败、类找不到、语法报错或静默崩溃。
PHP 版本与语法基础不兼容
Yii1.1 基于 PHP 5.2+，支持 `` 短标签、无命名空间、无类型声明；Yii2.0 要求 PHP 5.4+，强制使用命名空间；Yii3.0 则硬性依赖 PHP 8.2+，大量使用构造器属性提升、联合类型、`#[Attribute]`、`mixed` 和 `declare(strict_types=1)`。同一份代码里若同时引用 Yii1 的 `CController` 和 Yii3 的 `#[Route]`，PHP 解释器会在解析阶段直接报 Fatal error: Uncaught ParseError 或 Undefined class constant。
自动加载与类名冲突无法共存
- Yii1.1 使用自定义 `Yii::import()` + `CApplication::autoload()`，类名带 C 前缀（如
CActiveForm）； - Yii2.0 全面采用 Composer PSR-4 自动加载，类名去前缀（
yii\widgets\ActiveForm）； - Yii3.0 彻底移除全局 Yii 类，所有组件必须通过 DI 容器注入，连
Yii::$app都不存在。
一旦在同一个 autoloader 中注册多个版本的加载规则，Composer 会因命名空间重复或类路径冲突而拒绝启动，或在运行时随机抛出 Class not found —— 即使类文件物理存在，加载器也只会按优先级选一个路径，其余被忽略。
核心对象模型完全割裂
三者对“应用实例”的理解完全不同：
- Yii1.1：单例
Yii::app()，全局可访问； - Yii2.0：静态属性
Yii::$app，仍为单例但结构重构； - Yii3.0：彻底废弃单例，所有服务必须显式注入，
Yii::$app->db这类写法会触发 Fatal error: Call to undefined property。
如果老代码中某处调用了 Yii::app()->user->isGuest，而当前环境是 Yii3，该行不会“降级兼容”，而是立刻终止脚本——没有 fallback，也没有 warning。
配置体系与生命周期机制互斥
Yii1.1 的配置是 PHP 数组 + main.php + params.php；Yii2.0 引入 config/web.php 并依赖 Application 初始化流程；Yii3.0 则完全基于 PSR-11 容器配置，所有组件注册在 config/common.php 中，且必须返回可解析的依赖图。试图把 Yii1 的 'urlManager'=>array(...) 配置块塞进 Yii3 的容器定义里，会导致 Array to string conversion 或 Invalid argument supplied for foreach() 等底层错误。
扩展与行为机制不可桥接
Yii1 的 behavior 绑定靠 $model->attachBehavior()，事件监听用字符串名（'onBeforeSave'）；Yii2 改为事件对象 + Event::on()；Yii3 则取消全局事件总线，改用中间件 + 消息总线（如 CommandBus）。一个 Yii1 的权限 behavior 无法挂载到 Yii2 的控制器上，更不可能被 Yii3 的 DI 容器识别和解析——它连构造函数参数签名都不匹配。
不复杂但容易忽略：这不是“功能缺失”或“写法不同”，而是三个独立语言环境。就像试图让 Python 2、Python 3 和 Rust 的代码在同一进程里执行一样，没有中间层能真正弥合。
