控制器通过调用模型获取数据（如$user = User::find(123)），再以关联数组形式（如['user' => $user]）传给视图，由render()等框架方法注入变量作用域，确保职责分离、避免N+1查询与隐性耦合。
控制器怎么把数据从模型传给视图
控制器不直接操作数据库，也不渲染 HTML，它只做一件事：拿数据、塞数据、选视图。关键动作就是调用模型获取数据，再以变量形式传入 render() 或 include 语句。
常见错误是把数据库查询写在视图里，或者在控制器里拼接 HTML 字符串——这破坏了职责分离，后续改样式或换数据库都得翻控制器代码。
- 正确做法：模型返回数组或对象（如
$user = $userModel->find(123)），控制器原样传给视图（['user' => $user]） - 注意参数键名：传入的键会变成视图里的变量名，
['data' => $items]→ 视图中直接用$data - 不要在控制器里做格式化：日期转字符串、金额加千分位等应由视图或辅助函数处理，控制器只管原始数据
为什么不能在视图里调用模型方法
视图文件（比如 user/profile.php）一旦直接调用 $model->getOrders()，就等于把数据访问逻辑和展示逻辑耦合在一起。下次要加缓存、换数据库驱动、或统一加权限校验时，就得逐个检查所有视图文件。
更隐蔽的问题是作用域污染：模型实例可能带连接池、事务状态等上下文，视图不该感知这些。
立即学习“PHP免费学习笔记（深入）”；
- 典型错误现象：
Fatal error: Call to a member function fetchAll() on null—— 因为视图里 new 了一个没初始化的模型 - ThinkPHP/CakePHP/Yii 等框架默认禁用视图中访问模型类，就是防这种硬编码
- 如果真需要“动态加载”，应该由控制器预加载好全部依赖数据，再一次性传入
render() 和 include 的区别在哪
render() 是框架封装的方法（如 Yii 的 $this->render('index', $data)），本质是隔离变量作用域 + 自动定位路径；include 是原生 PHP 语句，容易暴露路径和变量污染风险。
用 include 时，如果控制器里定义了 $title = '首页'，再 include 'view.php'，视图就能直接用 $title —— 听起来方便，但调试时根本分不清这个变量是谁定义的、有没有被覆盖。
-
render()通常会 extract 数组参数，自动创建局部变量，且限定在当前文件作用域内 - 路径解析由框架控制（如
app/views/user/show.php），不用硬编码相对路径 - 部分框架（如 Laravel）的
view()还支持模板继承、组件化，include完全无法支撑
传大量数据时控制器容易卡在哪
不是 CPU 卡，是内存和 IO 卡。控制器本身不慢，但它常成“中转站”：一边等模型查完 5 张表关联数据，一边等视图渲染完 200 行表格再吐出 HTML。
尤其当模型方法没加缓存、或视图里嵌套了循环调用模型（比如每行用户都 $postModel->countByUser($id)），问题会指数级放大。
- 性能陷阱：控制器里写
foreach ($users as $u) { $u->posts = $postModel->findByUserId($u->id); }—— N+1 查询实际发生在控制器层 - 正确解法：模型提供批量接口（
$postModel->findByUserIds(array_column($users, 'id'))），控制器一次取完 - 真正该瘦身的是控制器逻辑，而不是减少传参个数；传 20 个字段的数组比传 1 个对象慢不了多少，慢的是反复查库
