Webman插件化核心在于加载时机、配置合并方式和协程上下文隔离：插件目录结构错则配置无法自动合并，静态变量/单例易致状态污染，事件监听须在boot()中且防重复注册，热更新需手动刷新配置与类加载缓存。
Webman插件化不是“加个目录就能用”，核心在于加载时机、配置合并方式和协程上下文隔离这三件事没处理好，插件一多就会内存暴涨、日志串号、数据库连接复用错乱。
插件目录结构选错直接导致配置无法自动合并
Webman 识别插件配置只认两个路径：plugin/{vendor}/{name}/config/ 和 config/plugin/{vendor}/{name}/。前者用于手动创建的轻量插件，后者是 webman plugin:create 命令生成的标准 Composer 插件路径。
- 如果你用
php webman plugin:create tinywan/encryption，配置必须放config/plugin/tinywan/encryption/app.php，否则config('plugin.tinywan.encryption.app')永远返回 null - 手动建的
plugin/customlogger/config/app.php能被自动合并进主配置，但仅限于顶层键名（如'log_level'），嵌套数组不会递归合并，同名键会被完全覆盖 -
bootstrap.php文件只在主进程启动时执行一次，不能用来做请求级初始化；需要协程安全的初始化逻辑，得放在中间件或控制器里调用
插件类在常驻内存模型下容易状态污染
Webman 进程不重启，所有静态变量、单例、全局连接对象都会跨请求残留。插件若直接 new PDO 或用 static $instance，第二个协程进来时看到的是第一个协程留下的脏数据。
- 数据库类必须重写
getConnection()，每次调用都通过Co\Channel或Context::get()拿新连接，不能缓存句柄 - 禁止在构造函数里初始化外部资源（如 Redis 连接、HTTP 客户端），改用延迟工厂：
$container->bind('Encryption', function () { return new Encryption(); }); - 日志、追踪 ID 必须绑定到当前协程上下文：
Context::set('plugin.encryption.request_id', $request->id());，否则不同用户日志混在一起
事件监听注册位置错误引发重复触发或内存泄漏
插件监听业务事件（如 user.login.after）时，如果在 register() 或构造函数里调 event()->on()，每次容器解析插件实例都会重新绑定一次监听器，最终一个事件触发 N 次回调。
立即学习“PHP免费学习笔记（深入）”；
- 监听逻辑必须放在
boot()方法中，且确保只执行一次 —— 可加static $booted = false;判断 - 高频事件（如订单创建）优先用
event()->once()，避免监听器长期驻留内存 - 不要在监听器里直接调
event()->emit()，尤其不能 emit 自身监听的事件，否则可能触发无限递归 - 异步任务类（如发短信）建议封装为独立
Process，而不是塞进事件回调里阻塞主线程
插件热更新失败往往卡在配置与类加载缓存上
Webman 默认不刷新配置缓存，改了 config/plugin/xxx/app.php 后不重启服务，config() 读的还是旧值；同时 Composer 的 autoloader 也不会自动 reload 新增的类文件。
- 开发期务必关掉配置缓存：
config('app.debug', true)，否则修改配置无效 - 新增或重命名插件类后，要运行
composer dump-autoload -o，否则 PSR-4 找不到类 - 修改了
bootstrap.php或process.php，必须重启整个 Webman 进程，reload 不生效 - 静态资源（如
plugin/xxx/public/js/app.js）走的是public/plugin/xxx/映射，路径别写错，不然 404 不报错只返回空内容
最易被忽略的是：插件内所有对 support\Utils、support\Model 的调用，都隐式依赖协程上下文。一旦在非协程环境（比如自定义 Process）里用了这些类，会直接 crash —— 这类错误不会抛异常，只会静默退出子进程。
