视图中写逻辑会导致n+1查询、破坏事务与日志、无法预加载、测试失效、逻辑泄漏、类型不校验、解析延迟及丧失依赖注入与中间件支持。
视图里写逻辑不是“不能跑”，而是会让后续所有人——包括未来的你——反复踩坑，而且越早踩越难拔出来。
视图中执行数据库查询会触发 N+1 问题
比如在循环渲染菜单时，每个 $item 都调一次 $this->db->query() 获取子项，实际发出的 SQL 数量 = 主项数 × 子查询次数。CI4 的 Query Builder 虽有缓存机制，但默认不跨请求生效，也无法自动合并这些散落的查询。
- 真实场景下，一个含 20 个一级菜单的后台页面，可能引发上百次数据库连接
-
$this->db实例在视图中使用，会绕过 Model 层的事务控制和日志埋点 - 无法用 CI4 的
$builder->with()或预加载（eager loading）优化，因为视图层没能力构造关联查询
视图混入业务判断导致测试完全失效
一旦出现类似 if ($user->role === 'admin' && $post->status !== 'draft') 这类判断逻辑，就等于把权限规则、状态机、甚至缓存策略都钉死在 HTML 模板里。
- 你没法对这个
if写单元测试——它依赖$user和$post对象，而这两个对象通常来自 Controller 的临时组装 - 前端改个按钮文案，顺手加了个
|| $is_preview，结果线上用户突然能看到草稿 - CI4 的
view()方法本身不支持 mock，所有基于视图的集成测试都会变成“截图比对”或干脆跳过
CI4 视图自动加载机制会让逻辑泄漏更隐蔽
CI4 默认控制器方法执行完后，会尝试加载同名视图（如 public function dashboard() → 自动找 dashboard.php）。如果这个视图里又嵌了 include 'sidebar.php'，而 sidebar 里调了 \Config\Services::renderer() 再去 render 另一个视图……逻辑就彻底散掉了。
- 错误堆栈里只显示
dashboard.php on line 42，但真正出错的是被 include 的那个文件里的数据库连接 -
$this->load->view()不校验参数类型，传进去的$data是数组还是对象？运行时才报 Notice - CI4 的
ViewRenderer在开发模式下不会预编译视图，每次请求都重解析 PHP 标签，逻辑越重，首字节延迟越明显
最常被忽略的一点：CI4 的 view() 函数本身不参与依赖注入，也没法加中间件。你没法给某个视图统一加权限拦截、响应头、或请求上下文注入——这些事只能在 Controller 或 Service 层做。一旦开始在视图里补逻辑，就等于主动放弃了整个框架的可扩展支点。
