动态插件加载需同时满足类加载隔离、执行时序控制和上下文传递；接口须含init()、execute()、destroy()三方法，ClassLoader须独立且不可复用，执行顺序需拓扑排序，PluginContext须桥接原生上下文并透传。
动态插件加载不是“加个 jar 就能用”，核心在于类加载隔离、执行时序控制和上下文传递三者必须同时成立；否则要么 ClassNotFoundException，要么插件之间互相污染，要么 PluginContext 里拿不到真实请求头或路由参数。
插件接口必须带明确生命周期方法
只定义 execute() 是不够的。Spring Cloud Gateway 或自研网关中，插件常需在启动时注册过滤器、监听器，或在请求链中特定阶段介入（如 pre、route、post）。所以接口至少要包含：
-
init(ApplicationContext context)：用于获取 Spring 容器 Bean（如RedisTemplate）、注册全局过滤器 -
execute(PluginContext context)：实际处理逻辑，context必须含ServerWebExchange（WebFlux）或HttpServletRequest（Servlet）等原始对象 -
destroy()：卸载时清理线程池、关闭连接、注销监听器，避免内存泄漏
漏掉 init() 就没法做依赖注入；漏掉 destroy() 在频繁热加载场景下，10 分钟内可能触发 OOM。
类加载器不能复用应用 ClassLoader
直接用 Thread.currentThread().getContextClassLoader() 加载插件 class，会导致插件和主程序共享类路径 —— 一旦两个插件依赖不同版本的 netty-handler，就会 LinkageError。
- 必须为每个插件创建独立的
URLClassLoader，构造时传入插件 jar 的File.toURI().toURL() - 父加载器设为
ClassLoader.getSystemClassLoader().getParent()（即 Extension ClassLoader），避免穿透到应用级类 - 加载后立刻调用
classLoader.close()（JDK9+）或手动释放URLClassLoader引用，防止句柄泄露
Spring Boot 2.7+ 默认禁用 restart 类加载机制，DevTools 不适用于生产态插件热加载。
插件执行顺序依赖 getOrder() + 显式拓扑排序
网关过滤器链不是简单按数字排序就完事。getOrder() 只解决同类型插件（如全是鉴权类）的相对位置，但限流插件必须在鉴权前执行，日志插件必须在所有业务插件之后 —— 这需要额外的元数据声明。
- 在插件 jar 的
META-INF/plugin.yml中声明phase: pre-auth、dependsOn: ["rate-limit"] - 加载时解析该文件，构建 DAG 图，用 Kahn 算法做拓扑排序，再 fallback 到
getOrder() - 禁止插件在
execute()内部调用Thread.sleep()或阻塞 IO，WebFlux 下会直接卡住整个 event loop
没做拓扑校验时，曾出现过鉴权插件读取了尚未被限流插件重写的 X-Real-IP，导致白名单失效。
PluginContext 必须桥接网关原生上下文对象
很多团队把 PluginContext 设计成 Map(String) context.get("user_id")，既没类型安全，又无法感知上游插件是否已写入。
- 应继承网关原生上下文，如 Spring Cloud Gateway 的
ServerWebExchange，暴露getPrincipal()、getAttributes()等标准方法 - 所有插件共用同一个
PluginContext实例（非副本），保证下游插件能读到上游插件 set 的值 - 对敏感字段（如 token、密钥）做显式标记，
context.mask("Authorization")，避免日志插件误打明文
最易忽略的是异步场景：当插件开启新线程处理耗时操作（如调第三方风控 API），必须手动把 PluginContext 透传进去，否则子线程里 context.get("traceId") 为空。
