PHP插件热加载需先卸载旧钩子、用文件时间戳作缓存键、OPcache按文件失效；参数须类型约束与只读契约；依赖需DAG拓扑排序；钩子异常应中断传播并校验返回值。
PHP 插件如何真正“热加载”而不重启 Web 服务器
PHP 本身无原生热加载机制，所谓“热加载”本质是运行时动态包含 + 事件注册表刷新。关键不在文件是否能重读，而在已注册的钩子回调是否被新版本覆盖。
常见错误：直接 include 插件入口后调用 register_hook，但旧回调仍驻留在全局事件容器中，导致新旧逻辑并存、行为不可预测。
- 每次插件启用/更新前，先从事件管理器中
unregister_all_hooks_by_plugin_id('payment_alipay_v2') - 使用绝对路径 + 文件修改时间戳做缓存键：
__DIR__ . '/plugins/payment_alipay_v2/main.php' . filemtime($file)，避免 OPcache 缓存旧字节码 - Web 环境下禁止依赖
apcu_clear_cache()清全局缓存——它不清理 OPcache，且多进程下无效；改用opcache_invalidate($file, true)
钩子参数传递必须强制类型约束与上下文隔离
很多插件系统把 do_action('order_created', $order) 当成万能胶水，结果插件 A 修改了 $order->status，插件 B 读到的就是脏数据，破坏执行顺序语义。
正确做法不是禁止传引用，而是明确“可变”与“只读”契约：
立即学习“PHP免费学习笔记（深入）”；
- 对原始对象使用
clone或 DTO 封装：传入new OrderReadOnlyDto($order)，而非裸$order - 钩子定义需声明参数模式：
add_action('order_created', 'my_handler', ['pass_by' => 'copy']) - 核心框架在触发前自动检测参数类型：若回调声明接收
OrderEntity $o，但传入的是array，立即抛InvalidArgumentException而非静默失败
插件间依赖与执行顺序不能靠“加载先后”硬编码
依赖 plugin_a 的 plugin_b 如果加载更早，do_action('a_ready') 就永远收不到——这不是竞态，是架构缺陷。
必须引入显式依赖声明和拓扑排序：
- 每个插件配置中声明
"requires": ["log_service", "cache_adapter"]，由插件管理器解析依赖图 - 执行钩子前，按 DAG 拓扑序排列监听器：
get_hook_listeners('user_logged_in')返回已排序数组，而非简单array_values($listeners) - 禁止插件在
__construct()中调用其他插件函数；所有跨插件交互必须通过钩子或服务容器（如$this->container->get('cache.adapter.redis')）
事件驱动下的错误传播必须中断链路而非静默吞掉
一个支付插件在 action: pre_charge 中抛出异常，如果框架只是 try/catch 后继续执行后续钩子，订单可能已创建却未扣款，状态彻底错乱。
事件总线需支持“可中断”语义：
- 钩子注册时指定
'break_on_exception' => true，该钩子异常将终止当前事件传播，并返回['success' => false, 'error' => $e->getMessage()] - 核心流程（如下单）必须检查事件返回值：
if (!$event_result['success']) { throw new BusinessRuleException($event_result['error']); } - 日志中记录完整中断路径：
[event] pre_charge → payment_wechat → Exception: Invalid openid format，而不是只记“下单失败”
插件系统最难的不是让功能跑起来，而是让失败时的状态可追溯、可回滚、不污染上下文。任何试图用 try/catch 包裹全部钩子调用的方案，都在掩盖数据一致性风险。
