CodeIgniter 官方不内置 Tideways，也无官方扩展包“Tideways_CodeIgniter”；需手动安装 PHP 扩展 tideways_xhprof，并在 pre_system/post_system 钩子中显式调用 tideways_enable()/tideways_disable() 进行性能分析，同时关联请求上下文信息。
CodeIgniter 官方不内置 Tideways，也无 Tideways_CodeIgniter 这个官方扩展包 —— 你看到的这个名称大概率是某第三方封装或误传的命名。 真实场景中，若想在 CodeIgniter（尤其是 CI 3.x）中使用 Tideways 做性能分析，必须手动集成原生 PHP 扩展 tideways_xhprof，再自行挂钩到请求生命周期。直接搜“Tideways_CodeIgniter”容易踩进过时、维护中断或安全风险未知的非标组件坑里。
确认 Tideways 扩展是否已正确安装并启用
这是所有后续操作的前提。Tideways 不是 Composer 包，而是 PHP 扩展，需系统级安装：
- Linux 下通常用
pecl install tideways_xhprof，然后在php.ini中添加extension=tideways_xhprof.so - 运行
php -m | grep tideways，有输出才说明加载成功 - 检查
phpinfo()页面，确认存在tideways模块节，且tideways.enabled为On - CI 应用若跑在 CLI 或不同 SAPI（如 FPM vs Apache module），要确保对应 SAPI 的
php.ini都启用了该扩展
在 CodeIgniter 请求中手动启动/停止 Tideways 分析
不能依赖任何“自动注入”的类或钩子；必须在控制器入口或核心钩子（如 pre_system）中显式调用原生函数：
- 在
application/hooks/Profiler_hook.php中写：
if (function_exists('tideways_enable')) {
tideways_enable(TIDEWAYS_FLAGS_MEMORY | TIDEWAYS_FLAGS_CPU);
}
- 在
post_system钩子中收集并保存结果：
$data = tideways_disable();
if (!empty($data)) {
file_put_contents(
WRITEPATH . 'logs/tideways_' . time() . '.xhprof',
json_encode($data)
);
}
- 注意：
WRITEPATH是 CI 3.1.11+ 引入的常量，旧版需用APPPATH . '../writable/logs/'并确保目录可写 - 不要在控制器方法里反复
tideways_enable()，它全局生效，重复调用可能覆盖前序数据
为什么别信“Tideways_CodeIgniter”自动集成包
搜索结果中所谓“Tideways_CodeIgniter”基本指向几个问题明显的来源：
- GitHub 上多数是 fork 自 2016–2018 年的冷仓库，PHP 7.4+ 和 CI 3.1+ 兼容性未经验证
- 部分包试图用
auto_prepend_file或register_tick_function实现自动分析，但会显著拖慢全站，且无法按路由/角色开关 - 它们常把
xhprof和tideways_xhprof混用，而后者不兼容原生 XHProf UI，必须搭配 tideways-ui 或第三方分析器 - 真正可靠的路径是：装好扩展 → 自己写轻量钩子 → 导出
.xhprof文件 → 用tideways-cli或 Web UI 分析
最容易被忽略的一点：Tideways 数据本身不带 HTTP 上下文（如 URI、用户 ID、响应码）。如果只导出原始 profile，排查线上问题时你会卡在“知道哪段函数慢，但不知道是哪个接口、哪个用户触发的”。必须在 tideways_disable() 后主动把请求信息（$this->uri->uri_string()、$_SERVER['REQUEST_TIME_FLOAT']）和 profile 数据一起序列化写入文件，否则等于白采。
