必须使用 view_cell() 而非手动加载，因为它是 CI4.7.1 中唯一支持生命周期管理、上下文注入和缓存策略的视图单元入口；直接 include 或 view() 会绕过 init()/render() 执行、丢失 $this->request 等上下文、无法使用 $this->cache() 和 URL 辅助函数。
view_cell() 是 CodeIgniter 4.7.1 中调用视图单元（View Cell）的唯一入口函数，它不是可选的语法糖，而是框架强制要求的封装机制——直接 include 或 view() 渲染组件类模板会绕过生命周期、丢失上下文、无法复用缓存策略。
为什么必须用 view_cell() 而不是手动加载？
视图单元本质是轻量级控制器+视图组合，由 Cell 类驱动。CI4 不允许裸写 PHP 类直接渲染，所有单元必须继承 CodeIgniter\View\Cells\Cell 并通过 view_cell() 触发实例化和生命周期管理。
-
view_cell('Header::render')会自动解析命名空间、实例化类、执行init()和render()方法，再注入当前请求上下文（如$this->request可用） - 若改用
view('cells/header')：类方法不执行、$data需手动传、无法使用$this->cache()、URL 辅助函数失效 - 错误现象常见于调试时：变量未定义、
base_url()返回空、CSRF token 缺失
Cell 类里哪些方法会被自动调用？
CI4.7.1 的视图单元类只有两个“钩子”方法被框架识别：init() 和 render()。其他方法（比如 getData()）需显式调用，不会自动触发。
-
init()：在构造之后、render()之前执行，适合做数据预处理（如查数据库、校验权限），但不能返回内容 -
render()：必须返回字符串（通常是view('cells/header', $data)结果），这是最终输出内容的唯一出口 - 类属性如
public $title = '默认标题'可被render()中直接读取，但不支持构造函数参数注入（CI4.7.1 尚未支持依赖注入到 Cell 实例）
装饰器（Decorator）不是内置功能，别被名字误导
CI4.7.1 官方文档中没有 “Decorator” 概念，也不存在 decorator 目录或配置项。所谓“装饰器”，实际是开发者对“包装型视图单元”的俗称——即一个单元负责包裹另一个单元或主视图，实现布局嵌套或逻辑隔离。
- 典型做法：在
app/Views/layouts/default.php中用view_cell('Navigation::render')+view_cell('Sidebar::render')+echo $body - 错误尝试：
$this->decorator->wrap()或decorator('admin')会报Call to undefined method - 真正可控的“装饰”行为只来自两处：①
view_cell()的第二个参数（$data 数组）决定传入什么；② 单元类内部是否调用其他单元（如render()里嵌套view_cell('Alert::render')）
缓存与性能陷阱：view_cell() 默认不缓存
每次请求都会重新实例化 Cell 类并执行 init() 和 render()，高频组件（如页脚统计、用户菜单）容易成为性能瓶颈。
- 启用缓存只需加第三个参数：
view_cell('UserMenu::render', ['user_id' => 123], ['cache' => 300])（单位秒） - 注意：缓存键基于类名 + 所有传入参数序列化生成，所以
['user_id' => 123]和['user_id' => '123']是不同缓存项 - 开发环境建议关掉缓存：
if (ENVIRONMENT !== 'production') { unset($options['cache']); }，否则改了init()逻辑却看不到效果
view_cell() 这个单一入口上。跳过它，等于放弃生命周期管理和上下文注入；迷信“装饰器”概念，反而会去翻不存在的文档或写无效代码。真正要盯住的，只有三件事：类是否继承 Cell、是否实现 render()、调用时是否用了 view_cell()。 
