必须选advanced模板，因其原生支持frontend、backend、console三入口及common共享层，可天然满足知乎类项目对权限隔离、前后端分离、定时任务和复杂RBAC的刚性需求，避免后期改造成本爆炸。
yii2-app-advanced 是唯一能撑住知乎类项目规模的起点，直接用 basic 模板后期会卡在权限、前后端分离、缓存和迁移协同上，不是功能做不出来，而是改起来成本爆炸。
为什么必须选 advanced 模板？
知乎类项目天然需要三套运行环境：前台（用户浏览/发帖）、后台（内容审核/RBAC）、控制台（定时清理/推荐计算）。advanced 模板原生提供 frontend、backend、console 三个入口，且共享 common 层模型与配置。如果硬用 basic，你得自己拆路由、隔离 session、重写用户认证逻辑——最后代码量不比直接上 advanced 少，还容易漏掉 request 的 csrfParam 隔离或 cookieParams.path 冲突这类细节。
数据库设计绕不开“关联表法”
知乎的内容结构（问题、回答、评论、点赞）天然多对多、层级深，字段随语言/版本/状态不断膨胀。别用单表多列（比如 title_zh/title_en），它会在加第 3 种语言或新增字段时逼你 ALTER TABLE 锁表。
播客文章生成器。将音频文字稿、节目链接、摘要笔记转化为结构清晰、适合发布的图文文章。支持多种输出风格（深度解析、精华摘要、对话体重构、社交媒体切片）和多种输出格式（Markdown、微信公众号、知乎、企业内刊）。触发词：播客文章、播客转文章、podcast to article、podcast article
- 主表只存核心字段：
questions.id、questions.created_at、questions.status - 翻译表独立：
question_translations含question_id、language、title、content、slug - 关系表必须带时间戳和状态：
question_upvotes要有created_at和is_cancelled，否则无法回溯点赞行为
RBAC 权限系统不能靠 Gii 生成就完事
yii\rbac\DbManager 默认把权限数据全塞进 auth_* 表，但知乎类场景要支持「问题作者可删自己回答」「管理员可删任意评论」「版主可封禁用户但不能删问题」——这些规则没法靠静态角色覆盖。
- 必须重写
Rule类，例如OwnContentRule判断当前用户是否为$params['post']->user_id -
as AccessControl中的'roles' => ['@']只管登录态，具体操作权限得用Yii::$app->user->can('deletePost', ['post' => $model])显式校验 - 别把权限检查写在视图里，Controller 或 Service 层就要 throw
ForbiddenHttpException
URL 美化和 SEO 不是配个 urlManager 就够了
知乎的 URL 是语义化的：/question/123/why-is-php-still-popular，不是 /index.php?r=question/view&id=123。但单纯开启 enablePrettyUrl 会导致 backend 和 frontend 的路由规则互相污染。
- 前端路由必须限定
'baseUrl' => '@web'，后端单独设'baseUrl' => '/admin' - SEO 友好的
slug字段得在保存时自动生成并去重，用StringHelper::slug()+ 循环查重，别依赖 JS 前端生成 - 404 页面要区分：用户访问不存在的问题 ID 返回 404，但访问已删除的问题应返回 410（Gone），搜索引擎才不会反复抓取
console 应用里定时任务的可靠性——比如每日凌晨清理软删除内容、更新热门问题排序。这些逻辑一旦写在 frontend 的控制器里，靠用户访问触发，就永远跑不全。 
