CI 3.x需自行扩展事件系统，推荐轻量级观察者模式或ci-events库；CI 4.x内置Events类，须严格遵循生命周期并用service()获取依赖；注意异常处理、重定向限制及性能裁剪。
要在CI（CodeIgniter）框架中实现松耦合的业务逻辑解耦、响应式动作触发或跨模块通信，必须借助事件系统——但原生CI 3.x不内置事件机制，CI 4.x才正式引入Events类，而大量存量项目仍基于CI 3.x运行，需自行扩展或选用第三方方案。
CI 3.x手动实现事件系统的两种可靠路径
方法一：轻量级观察者模式封装（推荐用于中小型项目）
第一步：在application/libraries/下新建Event.php，定义基础事件注册与触发逻辑；
第二步：在application/core/MY_Loader.php中重载library()方法，确保Event可全局加载；
第三步：在控制器或模型中调用$this->event->trigger('user_registered', $data)，并在任意位置用$this->event->on('user_registered', function($data){...})监听；
注意：该方案不支持事件优先级和异步执行，但内存占用极低，适合无Composer环境。
方法二：集成第三方库ci-events（适用于已有Composer且需多监听器场景）
执行composer require jenssegers/ci-events安装；
在application/config/autoload.php中将events加入$autoload['libraries']；
【关键前提】必须确保application/config/config.php中$config['composer_autoload'] = TRUE已启用，否则类自动加载失败；
之后即可使用$this->events->fire('order_paid', ['order_id' => 123])与$this->events->listen('order_paid', [$this, 'handleOrderPaid'])。
CI 4.x原生Events类的正确用法
CI 4.x将事件系统深度集成进核心，无需额外安装，但必须严格遵循生命周期调用时机：
在任意服务提供者（如app/Services.php）中注册监听器：Events::on('spark.ready', function() { log_message('info', 'Spark loaded'); });；
在控制器中触发自定义事件：Events::trigger('user_login_success', $user_data)；
若监听器需访问服务容器（如Model或Database），必须用闭包+service()显式获取：Events::on('payment_confirmed', function($data) { $model = service('paymentModel'); $model->updateStatus($data['id']); });；
这一步不能省略service()调用——直接使用$this->paymentModel会报错，因为事件回调不在控制器作用域内。
高频踩坑点与绕过方案
问题：CI 3.x中事件监听器无法捕获构造函数抛出的异常
原因：手动实现的trigger()通常用try/catch包裹单个监听器，但未统一处理全部监听器的异常传播链；
解决方案：改用array_map()批量执行监听器，并用set_error_handler()临时捕获致命错误；
问题：CI 4.x事件监听器中调用redirect()导致Headers already sent错误
【不可逆操作】事件触发发生在响应已开始输出后，此时禁止任何重定向或exit；必须改用session()->setFlashdata()暂存状态，交由视图层判断跳转。
性能敏感场景下的事件裁剪策略
步骤一：禁用开发环境外的所有调试型事件监听器——在app/Config/Events.php中用if (ENVIRONMENT !== 'development')包裹Events::on('debug.log', ...)；
步骤二：对高频触发事件（如request.start）启用缓存过滤，仅当请求URI匹配/api/.*正则时才触发监听；
步骤三：移除所有未被Events::trigger()实际调用的Events::on()注册语句——CI 4.x不会自动清理未使用的监听器，长期驻留会增加内存开销。
