commonjs 无法动态加载远程插件，需通过 fetch + 沙盒 eval 模拟其语义：构造隔离上下文注入 module/exports/require，禁用全局访问，配合 esm 动态导入与安全校验实现可控插件化。
CommonJS 的 require 本身是同步、静态路径解析的，不支持运行时动态加载远程 URL 或未声明的模块路径。在插件化系统中直接用 require('https://cdn.com/plugin.js') 会报错——Node.js 不支持 HTTP 路径，浏览器也不原生支持 CommonJS。所以“在插件系统中用 CommonJS 动态加载外部扩展模块”，实际要解决的是：如何在保留 CommonJS 风格（如 module.exports / require）的前提下，安全、可控地接入外部扩展逻辑。
核心思路：不依赖原生 require，而是模拟 CommonJS 执行上下文
真正可行的做法，是在运行时 fetch 脚本内容，用 eval（或 Function 构造器）在隔离作用域中执行，并手动注入 module、exports、require 等变量，使其行为接近 CommonJS 模块。这不是“调用 Node 的 require”，而是“复现其语义”。
- 构造一个干净的执行沙盒，包含
module = { exports: {} }和简化的require函数（仅支持本地已注册插件） - 用
fetch(url).then(text => evalInSandbox(text))加载远程脚本 - 插件脚本内可写
module.exports = { init, destroy }，主系统拿到module.exports后再注册进插件管理器 - 禁止插件内部调用全局
require或访问process，所有依赖必须显式注入（如通过context参数）
必须绕过 CommonJS 的三个限制
原生 CommonJS 在插件场景下有三处硬伤，需主动规避：
-
路径不可动态：CommonJS 的
require(x)中x必须是字符串字面量（如require('./a')），不能是变量或 URL。所以不能靠它加载 CDN 插件 -
无网络能力：Node.js 的
require只读文件系统，不处理 HTTP；浏览器无require全局函数 -
无生命周期控制：CommonJS 模块一旦
require就执行并缓存，无法disable或热替换
推荐替代路径：用 ESM 动态导入 + CommonJS 兼容封装
现代插件系统应以 import() 为加载主干，再对 CommonJS 风格插件做适配层：
- 插件作者仍可写 CommonJS 格式（
module.exports = { id: 'my-plugin', enable() {…} }） - 主系统提供一个包装器：把 CommonJS 内容转成 ESM 模块对象（例如用
import.meta.resolve+eval沙盒生成一个default导出） - 统一用
const plugin = await import('./adapters/cjs-bridge.js?plugin='+url)加载，保持异步、可取消、可错误捕获 - 插件管理器只认
{ id, load(), enable(context), disable() }接口，不管底层是 CJS 还是 ESM
安全与工程约束不能妥协
即使技术上能 eval 远程脚本，生产环境也必须加管控：
- 只允许加载同源或白名单域名的插件（CSP 配合
script-src） - 对插件代码做基本 AST 检查（禁用
document.write、eval、with等高危语法） - 每个插件运行在独立
WeakMap实例中，避免状态污染 - 禁用
require.cache操作——ESM 下无效，且易引发内存泄漏
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
