Yii适合中大型Web应用，尤其需快速交付、强后台管理与多角色权限的场景；当项目重视RBAC、Gii生成、AR稳定性及可维护性，且团队熟悉PHP时，Yii比Laravel/Django更贴合工程节奏。
Yii 不适合纯 API 服务或超轻量级微服务，但它是中大型业务系统（尤其是需要快速交付、强后台管理、多角色权限的 Web 应用）的可靠选择。
什么时候该选 Yii 而不是 Laravel 或 Django？
当你的项目需要兼顾开发速度、可维护性与企业级扩展能力，且团队熟悉 PHP、重视 RBAC、表单生成、Gii 代码生成和数据库迁移流程时，Yii 的设计哲学更贴合实际工程节奏。
它不像 Laravel 那样强调“优雅语法糖”，也不像 Django 那样强绑定 ORM 和 Admin；而是把 ActiveRecord、AR 关系映射、Validator 规则复用、UrlManager 路由配置这些关键链路做得足够稳定、可替换、易调试。
- 已有 MySQL/PostgreSQL 主库，需快速构建带复杂查询条件的后台列表页 →
ActiveDataProvider+SearchModel组合开箱即用 - 要对接 LDAP/OAuth2 并统一管理用户权限 →
yii\rbac\DbManager支持数据库驱动的权限树，比硬编码规则更易运维 - 需要高频生成 CRUD 页面且接受模板化 UI →
Gii可批量生成 Model/Controller/View，配合GridView和DetailView减少样板代码
大型系统里 Yii 的性能瓶颈在哪？
瓶颈通常不出在框架本身，而在于默认配置与开发者习惯：比如未关闭 debug 模式上线、滥用 Event::on() 全局监听、在循环中反复调用 ActiveRecord::findOne() 而不预加载关联数据。
真实压测中，Yii2 在 PHP 8.1 + OPcache + Redis 缓存配置下，QPS 稳定在 800–1200（典型后台接口），与 Laravel 相当；但它的内存占用更低，Request 生命周期更短，对 FPM 进程复用更友好。
- 避免在
beforeAction()中做重逻辑，改用中间件式行为（Behavior）或独立服务类 - 分页查询必须用
ActiveDataProvider，别手写limit/offset—— 否则深分页会拖垮 MySQL - 日志写入不要直连文件，用
FileTarget+RotateFileTarget控制大小，生产环境建议切到SyslogTarget或 Kafka
模块化和微服务拆分是否顺畅？
Yii 原生支持 Module，但模块间耦合容易变重：比如一个 UserModule 直接 new OrderService 就破坏了边界。它不提供服务发现、RPC 或事件总线，得靠外部组件补足。
可行路径是：核心业务保留在主应用（如用户中心、权限中心），其他域（订单、支付、物流）抽成独立服务，用 yii\httpclient\Client 或 Guzzle 调用；内部通信走 REST/JSON，异步任务交由 yii\queue（支持 Redis/DB/AMQP）。
- 模块内尽量只暴露
Api控制器，禁止跨模块直接访问 Model - 共用模型定义（如
UserDTO）应单独打包为 Composer 包，而非复制粘贴 - 路由前缀统一用
api/v1/，配合UrlRule规则做版本隔离，避免升级断裂
return [
'class' => 'yii\rest\UrlRule',
'controller' => ['v1/user', 'v1/order'],
'prefix' => 'api',
'extraPatterns' => [
'GET search' => 'search',
],
];
真正卡住扩展性的，从来不是框架，而是团队是否坚持接口契约、是否约束了 config/main.php 的膨胀速度、以及有没有把 common 层真正当成领域模型容器来维护——而不是塞满工具函数和全局常量。
