Tracy 在 CodeIgniter 中需手动集成并桥接，因其默认不捕获 CI 封装的错误、SQL 和上下文数据；须在控制器或钩子中主动推送 SQL、请求参数等至 Tracy 面板，且 CI3 与 CI4 接口差异需分别适配。
CodeIgniter 本身不带 Tracy，但可以手动集成；直接用 Debugger::enable() 不会自动捕获 CI 的 SQL 或错误堆栈，必须桥接。
为什么 Debugger::enable() 在 CI 里没反应
Tracy 默认只拦截 PHP 原生错误和未捕获异常，而 CodeIgniter 3/4 自己封装了错误处理流程（比如 show_error()、log_message()），把大部分错误吞掉了，Tracy 根本收不到。CI 的数据库错误、404、表单验证失败等，都不走 PHP 的 error handler。
- CI3 中，
db_debug = TRUE会触发自己的 HTML 错误页，绕过 Tracy - CI4 中，
CI_ENVIRONMENT = 'development'时默认启用错误报告，但仍是 CI 自己的渲染器 - 即使 Tracy 浮层出现，也看不到
$this->db->last_query()或模型中的变量值——它没接入 CI 的执行上下文
怎样让 Tracy 看到 CI 的 SQL 和请求数据
得手动把 CI 的关键调试信息“推”给 Tracy，不能只靠 Debugger::enable() 被动监听。
- 在控制器基类或钩子（hook）中，查询执行后立即调用
Tracy\Debugger::bar()->addPanel(new \Tracy\BlueScreen\Panel())并注入自定义面板 - 打印当前 SQL：
Tracy\Debugger::log($this->db->last_query(), 'SQL')，但前提是save_queries = TRUE且刚执行完get() - 记录请求参数：
Tracy\Debugger::log($this->input->post(), 'POST')或$this->uri->uri_string() - 避免在视图里调用——控制器响应结束前就该推完，否则被后续逻辑覆盖
CI3 和 CI4 集成 Tracy 的关键差异
CI4 移除了 _compile_select()，也不再支持直接访问 $this->db 的受保护方法，Tracy 面板必须适配新接口。
- CI3：可直接在模型中写
Tracy\Debugger::log($this->db->_compile_select(), 'PREPARED SQL') - CI4：需改用
$builder = $this->db->table('users')->select('*')->where('id', 1); echo $builder->getCompiledSelect();，再传给Debugger::log() - CI4 的
lastQuery()返回对象，得用$this->db->getLastQuery()->getQuery()，且依赖DB_DEBUG = true - CI4 中 Tracy 的
bar()需在BaseController::__construct()末尾初始化，否则中间件可能干扰
真正卡住人的不是装不上 Tracy，而是以为装上就自动接管 CI 全链路——它只管 PHP 层，CI 的 Query Builder、Router、Loader 都是黑盒，得一层层手动打点导出。
