CodeIgniter 3.x 无内置 Pusher 广播机制，因其缺乏 Laravel 的广播抽象层（如 ShouldBroadcast、BROADCAST_DRIVER）和事件序列化能力，仅支持单机内存事件；必须手动集成 Pusher SDK 并通过 HTTP 调用 API 实现实时推送。
CodeIgniter 3.x 无法原生集成 Pusher 进行实时推送，必须通过手动 HTTP 请求调用 Pusher REST API，不能依赖 Laravel 那类广播系统。
为什么 CodeIgniter 没有内置的 Pusher 广播机制
CodeIgniter 3.x 完全不提供 ShouldBroadcast、broadcastOn() 或 BROADCAST_DRIVER 这类抽象层；它的事件系统是单机内存级的，不支持序列化广播到外部服务。所谓“配置 broadcasting.php”在 CI 中根本不存在——这个文件只属于 Laravel。
常见错误是照搬 Laravel 教程，在 CI 里新建 config/broadcasting.php 或尝试 $this->load->library('pusher')，结果必然报错：Fatal error: Class 'Pusher' not found 或 Call to undefined method CI_Loader::library()。
- CI 的
Loader不识别pusher这个库名，它只认你手动写进application/libraries/的类 - Pusher PHP SDK 是纯函数式调用，没有 CI 风格的自动加载或依赖注入
- 所有广播逻辑必须由你显式触发，比如在登录成功、消息入库后，手写
curl或file_get_contents调用 Pusher 的/apps/{app_id}/events接口
手动集成 Pusher SDK 的最小可行步骤
跳过 Composer 自动加载（CI 3.x 默认不启用），直接下载官方 SDK 并放入 application/libraries/：
cd application/libraries/ wget https://github.com/pusher/pusher-http-php/archive/refs/tags/v7.2.1.zip unzip v7.2.1.zip mv pusher-http-php-7.2.1/ Pusher/
然后在控制器中这样用：
- 先在
application/config/autoload.php中添加'Pusher'到$autoload['libraries']数组（注意大小写） - 在控制器方法里初始化：
$this->load->library('Pusher\Pusher', ['key' => 'your-key', 'secret' => 'your-secret', 'app_id' => 'your-app-id', 'options' => ['cluster' => 'ap3']]'); - 触发事件：
$this->pusher->trigger('my-channel', 'my-event', ['message' => 'hello']);
注意：Pusher\Pusher 构造参数必须传数组，不能传字符串；cluster 值要和 Pusher 控制台一致，填错会导致 404 Not Found 错误。
前端订阅时容易忽略的鉴权细节
Pusher 默认频道是公开的，但一旦你改用 private- 或 presence- 前缀，就必须实现 /pusher/auth 端点，并返回签名响应。CI 中不能复用 Laravel 的 routes/web.php 写法，得自己写一个控制器方法：
- 创建
application/controllers/Pusher_auth.php - 在方法里手动解析 POST 的
socket_id和channel_name - 校验用户登录态（比如检查
$this->session->userdata('user_id')是否存在） - 用 SDK 生成签名：
$auth = $this->pusher->authenticate($socket_id, $channel_name); - 输出
json_encode($auth)，且 header 必须是Content-Type: application/json
漏掉 header 或返回非 JSON 格式，前端会卡在 Connection failed: Policy violation，但控制台不会报具体原因。
生产环境必须处理的连接稳定性问题
Pusher 客户端在弱网下会频繁重连，而 CI 后端如果每次重连都触发一次 trigger()，可能造成重复广播。更隐蔽的问题是：CI 的 session 生命周期默认 7200 秒，但 Pusher 的 socket_id 有效期仅 24 小时，且不与 CI session 绑定。
这意味着：
- 用户刷新页面后拿到新
socket_id，但旧连接可能还在后台存活，导致同一消息被推两次 - 没做去重的话，前端
bind('my-event', ...)可能被反复注册，事件监听器数量指数增长 - 不要在 CI 的
__construct()里初始化 Pusher 实例——它会被多次实例化，消耗连接池
真正可控的做法是：把 Pusher 实例封装成单例，只在需要广播时临时 new 一次，用完即弃；前端用 channel.unbind().unbind_all() 清理再绑定。
