闭包本身不直接实现可插拔，但通过私有状态隔离、清晰接口契约、初始化与驱动解耦三大支点，支撑模块具备明确边界、可控行为与低耦合接入能力。
闭包本身不直接“实现可插拔”，但它为模块逻辑的可插拔性提供了底层支撑——通过作用域隔离 + 显式接口契约 + 状态独立，让模块能被安全地加载、配置、替换和组合。
闭包构建可插拔性的三个关键支点
可插拔不是指“能随便塞进去”，而是指模块具备明确边界、可控行为、低耦合接入能力。闭包从以下三方面支撑这一点：
- 私有状态隔离：每个模块实例的变量（如 token、cache、计数器）只存在于自身闭包中，不会与其它模块或全局环境冲突。替换一个模块时，旧状态自动失效，新模块自带干净上下文。
- 接口契约清晰：模块只暴露有限方法（如 init()、send()、destroy()），这些方法签名稳定、职责单一。只要新模块返回相同结构的对象，上层调用方无需修改代码即可切换实现。
- 初始化与驱动解耦：模块内部可接收外部传入的驱动对象（如 fetch、localStorage、事件总线），不硬编码平台 API。换环境时只需注入适配后的驱动，模块逻辑原封不动复用。
工厂函数是实现多实例可插拔的核心写法
单例 IIFE 适合全局工具类（如日志 SDK），但业务插件常需多个独立运行的实例（例如：不同表单校验规则、多个支付通道、各租户独立配置的推送服务）。此时必须用工厂函数：
- 每次调用 createValidator({ rules: [...] }) 都生成全新闭包，私有规则缓存、错误队列互不干扰
- 配置项作为参数传入，在闭包内完成一次性初始化（如预编译正则、绑定事件），避免运行时判断分支
- 返回对象的方法仍能访问专属私有数据，但无法越界读取其它实例内容
策略注入让模块逻辑真正可替换
可插拔的本质是“同一接口，不同策略”。闭包支持把策略作为参数传入，而非写死在模块内部：
- 传入校验策略函数，替代模块内硬编码的 if-else 判断
- 传入序列化器、加密器、重试策略等可选组件，模块只负责流程调度
- 策略函数本身也可封装为独立模块，通过闭包保护其内部状态，形成嵌套可插拔结构
销毁与清理机制保障热插拔安全
可插拔不仅包含“装”，也包含“卸”。闭包模块可内置 clean-up 逻辑，在卸载时释放资源：
- 清除定时器、事件监听器（注意加命名空间前缀，避免误删）
- 清空内部缓存、中断未完成请求
- 将 destroy() 方法暴露为公有接口，由宿主环境统一调用
- 因私有变量仅存在于闭包中，destroy 执行后整个实例可被 GC 回收，不留残留
