ThinkPHP6.x 核心架构：深入理解 MVC 模式在框架中的具体实现与解耦

先说一个核心判断：ThinkPHP6.x 的 MVC 绝不是那种挂在嘴边的概念套壳。它通过命名空间、目录约定、类继承和自动加载机制，在代码层面真正落地了一套职责分离体系。这套体系不靠强制约束，而是严格遵循 PSR-4 和框架内建规则，最终让 Model、View、Controller 各司其职，实现低耦合协作。

Model 层：不只是数据库映射，而是业务逻辑容器

在很多入门教程里，Model 被简单等同于“一张表一个类”。但在 ThinkPHP 中，Model 远不止于此。它继承 thinkModel，天然支持查询构造器、关联定义、自动验证、事件钩子和软删除等能力。

关键点在于：数据操作与业务规则应当统一收口在 Model 内。举个例子，密码修改必须调用 $user->changePassword($raw)，而不是在 Controller 里手写 SQL 或 hash 逻辑。关联关系（如 hasOne、hasMany）直接在模型中声明，视图或控制器无需感知底层的 JOIN 实现。验证规则可以内嵌在模型的 validate 属性或独立验证器中，确保数据入口一致受控。

Controller 层：专注请求流转与上下文协调

Controller 在整个请求生命周期中扮演调度中枢的角色。它的核心任务很纯粹：接收参数 → 调用 Model 处理 → 组织数据 → 分配给 View 或返回 JSON。这里有一条铁律：不要在 Controller 中写 SQL、数组遍历逻辑、格式化日期——这些属于 Model 或 Service 层的职责。

实践中，推荐将复杂业务流程进一步下沉到 app/service/ 目录下的服务类。Controller 只做轻量协调，例如 $orderService->create($data)。同时，使用依赖注入获取服务实例（如 app('order_service')），而不是 new 实例，这样更便于测试和替换。

View 层：纯模板，无逻辑，强隔离

ThinkPHP 默认使用内置模板引擎，View 文件（位于 app/view/ 下）只负责展示。这意味着，禁止在模板中间出现数据库调用、if-else 业务判断、循环中调用模型方法等行为。

所有数据必须由 Controller 显式通过 assign() 传入。模板内仅使用变量和内置标签（{:date('Y-m-d',$time)}），或者限于简单格式化的原生 PHP 输出。可以通过 {include file='common/header'} 拆分公共区块，但不能在 include 中传递运行时逻辑。如果采用前后端分离架构，View 层可以完全退化为 JSON 响应，此时 Controller 返回 json(['code'=>0, 'data'=>$list]) 即可，无需任何 .html 模板。

解耦的关键支撑机制

MVC 能真正解耦，靠的不是目录怎么摆，而是框架底层提供的几项关键能力：

• 服务容器 + 依赖注入：允许将 Model、Service、第三方 SDK 统一注册进容器，Controller 通过接口或名称获取实例，实现运行时替换。
• 中间件机制：把鉴权、日志、跨域等横切关注点抽离到 middleware 目录，Controller 不再承担非业务职责。
• 路由分组与资源路由：例如 Route::group('api', function () { Route::resource('user', 'api/User'); });，让 URL 结构与控制器职责天然对齐，减少手动 dispatch 分支。
• 环境配置驱动：数据库、缓存、日志等配置通过 .env 隔离，Model 和 Controller 无需关心当前是开发还是生产环境。