公共底部应放在app/views/partials/footer.php，由顶层布局default.php通过$this->include('partials/footer')统一加载，并传入动态数据；多主题时按布局分离底部文件，避免硬编码判断。
公共底部该放在哪几个位置才真正复用
CI 的“公共底部”不是靠复制粘贴实现的，而是靠视图加载顺序和布局嵌套控制。关键在于：所有控制器最终输出的视图，必须统一经过一个顶层布局文件（如 app/Views/layouts/default.php），而底部 HTML 片段应作为独立子视图被该布局包含。
常见错误是把 footer.php 直接写死在每个控制器对应的视图里——这样改一处就得改二十个文件，根本谈不上复用。
- 底部文件建议放
app/Views/partials/footer.php（partials/是约定俗成的可复用片段目录） - 主布局文件（如
default.php）里用$this->include('partials/footer')加载，而非include()或require() - 控制器中不再调用
$this->view('home/index')，而是统一调用$this->view('layouts/default', $data)，并在default.php中用$this->renderSection('content')插入页面主体
怎么让底部自动带登录状态、版权年份等动态内容
静态底部没意义，真正要复用的是“带逻辑的底部”。CI4 的视图片段支持传参和访问服务，但不能直接在 footer.php 里写 $this->session ——因为片段默认不继承控制器上下文。
- 在布局文件
default.php中，先准备好变量：$footerData = ['year' => date('Y'), 'isLoggedIn' => session()->has('user_id')]; - 再传给片段：
$this->include('partials/footer', $footerData) - 如果需要更复杂的逻辑（比如读取配置中的备案号），在
app/Services.php中注册一个footerService()，然后在布局中$footerSvc = service('footerService');后传入 - 避免在
footer.php里调service()或model()——这会让每次渲染底部都触发新实例，影响性能
为什么 $this->include() 没生效或报错
CI4 的 $this->include() 看似简单，但路径解析和作用域容易出问题。最常见的是“找不到文件”或“变量未定义”。
- 路径必须省略
.php后缀，且以斜杠开头表示从app/Views/开始：写'partials/footer'✅，写'partials/footer.php'❌，写../partials/footer'❌ - 片段内无法直接访问控制器传来的
$data，除非显式传递：即$this->include('partials/footer', $data)，否则为空数组 - 若在片段里用了
$this->uri等服务，需确认当前请求上下文是否完整——CI4 中视图片段运行在 ViewRenderer 实例内，大部分服务可用，但$this->request在某些异步渲染场景下可能为 null - 调试技巧：在
footer.php开头加<?php log_message('debug', 'footer loaded with: ' . json_encode($data)); ?>，查日志确认变量是否传入
多主题下底部怎么按需切换
当项目有 PC 端、移动端、管理后台多个主题时，“一套底部走天下”不现实。硬编码判断设备类型或路由前缀会导致耦合，正确做法是把底部选择权交给布局层。
- 不要在
footer.php里写if (is_mobile()) { ... }，而是在控制器中决定用哪个布局：$this->view('layouts/admin', $data)或$this->view('layouts/mobile', $data) - 每个布局文件各自
include对应的底部：admin.php包含'admin/footer'，mobile.php包含'mobile/footer' - 共用逻辑抽成服务：比如版权信息、统计脚本，统一由
FooterContentService提供，各主题底部只负责结构渲染 - 注意缓存干扰：CI4 默认对视图启用文件缓存，若不同主题共用同一缓存键（如
footer），会导致渲染错乱；务必在$this->include()调用时加唯一标识，例如$this->include('mobile/footer', ['theme' => 'mobile'])，并在服务中据此区分逻辑
app/Controllers/ 下每个类的 view() 调用，确保没有漏网之鱼。
