Yii框架完全适合开发CMS系统，但需从零构建而非开箱即用；其ActiveRecord与Gii可高效生成模型，但需手动补充软删除、场景验证、关联查询等CMS必备逻辑，并注意分页性能优化与富文本XSS防护。
Yii 框架完全适合做 CMS，但不是开箱即用的“成品 CMS”，而是适合从零构建高定制化、高性能、可长期维护的 CMS 系统。
Yii 的 ActiveRecord + Gii 能否快速生成内容模型？
可以，且效率很高，但需注意模型生成后的手动调整点：
-
Gii生成的ActiveRecord类默认不含软删除、状态字段、排序字段等 CMS 常见逻辑，需手动在rules()和behaviors()中补充 - 若内容表带前缀（如
cms_article），tableName()返回值必须显式写成{{%article}}，不能硬编码表名，否则迁移和多环境部署会出错 -
scenarios()需区分「新建」和「编辑」场景——例如封面图上传在新建时必填、编辑时可为空，不设会导致表单验证失败 - 关联字段（如栏目
category_id）建议在模型中定义getCategory()关联方法，并在search()中用joinWith()支持后台列表按栏目筛选
后台内容列表页卡顿，是不是 Yii 性能不行？
不是框架问题，90% 出在查询写法和分页配置上：
- 直接用
Article::find()->all()查全部再array_slice()分页 —— 这会把几万条记录全查出来，内存爆掉，必须改用ActiveDataProvider+Query::offset()/limit() -
ActiveDataProvider的totalCount默认执行COUNT(*)，如果带复杂JOIN或全文检索条件，这个 COUNT 本身就很慢；可考虑缓存 totalCount（如 Redis 存 5 分钟）或改用估算值（EXPLAIN行数近似） - 列表字段含富文本内容（
content字段）却没加select(['id', 'title', 'status', 'created_at'])—— 大字段拖慢网络和 MySQL I/O，务必显式指定需要的列
如何安全地支持用户提交富文本并防止 XSS？
不能只靠前端过滤或 htmlspecialchars() 输出，得在存入和渲染两层设防：
- 存入前用
yii\helpers\HtmlPurifier过滤：$model->content = HtmlPurifier::process($model->content, [ 'HTML.SafeIframe' => true, 'URI.SafeIframeRegexp' => '%^(https?:)?//(www\.youtube\.com/embed/|player\.vimeo\.com/video/)%', ]); - 渲染时禁用
encode属性：= $model->content ?>，但前提是已确保该字段只来自 purifier 处理后的数据；任何未清洗的变量都不能直接 echo - 禁止在富文本中执行 JS 是底线，但也要警惕 CSS 表达式、data: 协议、onerror 触发的 payload，
HtmlPurifier的默认配置不够，必须显式收紧规则
真正难的不是搭出一个能增删改查的后台，而是当栏目嵌套层级变深、内容要支持多语言版本、SEO 字段要自动填充、审核流要对接钉钉审批时，Yii 的组件化结构和事件机制（如 beforeSave、afterInsert）是否还能清晰承载。这些地方一旦设计松散，后期就只能靠 patch 堆砌，而不是重构。
