thinkphp的mvc是目录结构、类继承与调用约定共同落地的协作机制：控制器按路由映射方法并返回响应，模型继承think\model封装数据逻辑，视图通过fetch()按命名规则加载模板，三者严格依赖文件位置、命名规范与配置项协同工作。
ThinkPHP 的 MVC 不是抽象概念，而是目录结构、类继承关系和调用约定共同落地的一套协作机制。你写错一个命名、漏配一个路径、或混淆 fetch() 和 display()，页面就直接报错或空白——它不靠文档解释，靠文件位置和方法签名说话。
控制器怎么接收请求并决定调谁
URL 路由最终映射到某个控制器类的某个方法，比如访问 /user/profile 可能对应 app/controller/User.php 中的 profile() 方法。这个方法不能直接 echo 输出，必须返回内容（字符串、视图渲染结果或 Response 对象）。
- 控制器里调模型，推荐用
model('User')或Db::name('user')，避免硬编码路径 - 不要在控制器里写 SQL 拼接或业务判断逻辑，只做“调度”：收参数 → 校验 → 交模型处理 → 拿结果 → 传给视图
- 如果用了路由绑定（如
Route::get('user/:id', 'user/read')），$id会自动作为参数注入read()方法，不用手动input('id')
模型层不是只有数据库增删改查
默认的 app/model/User.php 继承 \think\Model，但它只是起点。复杂项目常拆成三层：
-
model/User.php：只管字段验证、自动完成、关联定义（如hasOne） -
logic/UserLogic.php：封装注册流程、密码重置逻辑、积分计算等，不碰数据库底层 -
service/UserService.php：对接第三方（短信、支付）、做事务包装、提供 API 入口
调用时用 D('User', 'Logic') 或配置 'DEFAULT_M_LAYER' => 'Logic' 改默认层，否则 D('User') 永远只找 model/ 下的类。
视图渲染为什么 fetch() 找不到模板
fetch() 默认按控制器名/方法名拼路径，比如 User::profile() 调 fetch() 就去找 view/user/profile.html。找不到就抛异常，不 fallback 到其他路径。
- 路径区分大小写，
view/User/profile.html在 Linux 下 404 - 模板里用
{:url('user/edit')}生成 URL，别写死/index.php/user/edit -
display('hello')是直接输出字符串hello，不是渲染模板；display()空参会尝试渲染 layout，但没内容就白屏 - 开启调试模式后，
view目录下缺失模板会明确提示 “template not exists”，关了就静默失败
config/view.php 配置项影响实际行为
模板引擎行为不只靠写法，更受配置驱动。关键项有：
-
'type' => 'Think'：启用内置模板引擎；设为'type' => 'php'就直接 include 原生 PHP 文件 -
'view_path' => './template/'：改掉这个，fetch()就不再去view/下找，而去找template/ -
'tpl_suffix' => '.html'：改成'.tpl'后，fetch('index')实际加载的是index.tpl - 缓存开关
'cache' => true开启后，模板编译文件存在runtime/template/，改了 HTML 不刷新？先清这个目录
fetch() 找错目录、模型类没加 namespace、或路由规则和控制器方法名大小写不一致。这些错误不会告诉你“MVC 理解错了”，只会报“class not found”或“template not exists”——得顺着报错信息反推哪一层断了。php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
