Yii2高级模板和基础模板有什么区别_项目选型对比【汇总】

基础模板适合单应用、轻量级项目，如内部工具、数据看板、API服务或个人博客，仅一个web/index.php入口，目录扁平，无前后端分离压力，便于快速验证想法、小团队维护及纯API交付。

基础模板适合什么场景？

单应用、轻量级项目直接上手就跑，比如内部工具、数据看板、API服务或个人博客。它只有一个 web/index.php 入口，所有控制器、模型、视图挤在同一个目录下，没有前后端分离压力。

• 项目初期验证想法，不想被多入口、共享配置、域名绑定这些事拖住节奏
• 团队里只有1–2人维护，不需要严格划分前后台权限和部署边界
• 需要快速交付一个纯 API 接口（如统计上报、Webhook 处理），连前端页面都不用写
• 你打算自己手动加模块（modules/），但又不希望被高级模板的目录结构干扰判断

注意：yii2-app-basic 并不是“阉割版”，它的 vendor/ 和核心框架能力跟高级版完全一致，命令行操作数据库、Gii 生成代码、RBAC 权限控制全都能用。

高级模板真需要两个应用吗？

不一定。它默认带 frontend/、backend/ 和 console/ 三个应用，外加一个 common/ 共享层，但这只是模板预设——你可以删掉 backend/，只留 frontend/ 当作单应用用，也能把 common/models 当普通类库引入基础模板项目。

• 如果你明确要前后台分离部署（比如 frontend 绑 www.example.com，backend 绑 admin.example.com），高级模板省去大量路由和 cookie 域名适配工作
• 后台管理功能复杂、权限粒度细（比如不同角色看到不同菜单、操作按钮），backend 独立配置更利于隔离安全策略
• 有定时任务、队列消费、数据导入导出等后台作业，console 应用天然支持 ./yii some-command 调用，不用自己搭脚本入口

常见错误：直接拿高级模板开干，却把所有业务逻辑塞进 frontend，backend 只放几个 CRUD 页面——这时你其实只用了1/3的能力，还平白多了跨应用调试成本。

init 脚本和 web 路径为什么总出错？

高级模板下载后必须运行 ./init（linux/macos）或 init.bat（windows），否则 config/*.php 里的环境配置不会生成，访问 /frontend/web/index.php 会报错 Invalid Configuration – yiibaseInvalidConfigException。

• 基础模板没这步，因为配置是静态写死的；高级模板靠 init 生成对应环境（dev/prod）的配置文件，跳过就炸
• 访问路径不是根目录：基础模板是 <a href="https://www.php.cn/link/9fb165a9b7dfef2a9f8ac7d69b22a42c">https://www.php.cn/link/9fb165a9b7dfef2a9f8ac7d69b22a42c</a>，高级模板必须指定子应用，比如 <a href="https://www.php.cn/link/86cbb7dba804b6c34f1f251e4869b479">https://www.php.cn/link/86cbb7dba804b6c34f1f251e4869b479</a> 或 <a href="https://www.php.cn/link/d88d880b67ce56dc1da111997d0c5160">https://www.php.cn/link/d88d880b67ce56dc1da111997d0c5160</a>
• apache/nginx 配置容易漏掉 frontend/web 和 backend/web 的别名或 root 指向，导致 404；Nginx 用户尤其要注意 location ~ .php$ 块里 fastcgi_param SCRIPT_FILENAME 必须指向正确的 web/index.php

顺手记个坑：用 docker 或宝塔时，别把整个 advanced/ 目录设为网站根目录，而是分别把 frontend/web 和 backend/web 设为两个站点根目录。

common 目录到底该放什么？

它是高级模板里最易被滥用的部分。名字叫 “common”，不代表啥都能往里扔。

• 推荐只放真正跨应用复用的东西：基础模型（如 User、BaseActiveRecord）、全局行为（TimestampBehavior 配置）、统一邮件模板、公共配置项（如 common/config/bootstrap.php）
• 别把控制器、视图、小部件（widgets/）丢进去——它们属于具体应用上下文，硬塞 common 会导致路由混乱、asset 发布失败
• 模型如果只在 backend 用，就留在 backend/models；如果 frontend 和 backend 都要查用户信息，再提到 common/models，并确保关联关系、验证规则不依赖某一方特有的扩展

一个信号：当你改 common/models/User.php 就得同时测 frontend 登录页和 backend 用户列表页，说明它确实该放这儿；如果只影响后台，那它就不该出现在 common 里。

高级模板的结构优势，得靠人主动按边界去组织，不是复制粘贴完就自动变清晰。