在 ES 模块（ESM）为主的 Node.js 项目中，可通过 createRequire 创建兼容 CommonJS 的 require 函数，安全导入 .cjs 文件并调用其导出的函数，避免 eval 引发的作用域问题和安全性风险。
在 es 模块（esm）为主的 node.js 项目中，可通过 `createrequire` 创建兼容 commonjs 的 require 函数，安全导入 `.cjs` 文件并调用其导出的函数，避免 `eval` 引发的作用域问题和安全性风险。
在现代 Node.js（v12.20+，推荐 v14.13+）中，混合使用 ESM 和 CommonJS 是完全可行的，但必须遵循规范方式——绝不可依赖 eval() 动态执行未封装的脚本代码。你遇到的 ReferenceError: sarasa2 is not defined 正是由于 eval(code) 在严格模式（ESM 默认启用）下创建的是封闭作用域，函数声明不会泄漏到外部上下文。
✅ 正确做法：将待加载逻辑封装为标准 CommonJS 模块（.cjs 后缀），并通过 createRequire 实现跨模块系统加载：
1. 编写标准 CommonJS 文件（testsjs/micro/sarasa.cjs）
// testsjs/micro/sarasa.cjs
function sarasa2() {
console.log("aca toy!");
return true;
}
// ✅ 两种等效导出方式（任选其一）
module.exports = { sarasa2 };
// 或：module.exports.sarasa2 = sarasa2;⚠️ 注意：文件后缀必须为
.cjs（或配置"type": "commonjs"的子目录package.json），否则 Node.js 会按 ESM 解析，导致require is not defined错误。
2. 在 ESM 测试文件中安全加载（so_Test.js）
根据 package.json 中的 engines 字段自动检测 Node.js 版本需求，未安装 nvm 时自动安装并切换至对应版本。支持 Windows、macOS、Linux。适用于 Node.js 项目开发、版本切换和环境配置。
import { Test } from "../../myjsunit/testSuite.js";
import { createRequire } from 'node:module'; // Node.js 内置模块
class so_Test extends Test {
test_load_and_run() {
const cjsPath = new URL('./sarasa.cjs', import.meta.url);
const require = createRequire(cjsPath); // ✅ 基于文件路径创建 require
const moduleExports = require('./sarasa.cjs');
const actual = moduleExports.sarasa2();
this.assertTrue(actual);
this.done();
}
}
export { so_Test };? 关键点说明：
-
createRequire(cjsPath)根据目标.cjs文件路径生成专用require函数，自动处理模块解析、缓存与 CommonJS 语义； - 使用
import.meta.url构建URL是 ESM 中获取当前文件路径的唯一可靠方式（__dirname在 ESM 中不可用）； - 不要拼接
process.cwd()路径——它易受运行位置影响，且破坏可移植性。
❌ 替代方案对比（不推荐）：
-
eval()：无作用域隔离、无法调试、禁用静态分析、存在远程代码执行（RCE）风险； -
vm.Script：需手动绑定上下文、仍绕过模块系统、维护成本高； - 改用
.mjs+ 动态import()：无法直接加载非默认导出的命名函数（如sarasa2），需重构源码。
? 进阶提示：若需批量加载多个 .cjs 工具函数，可封装为工厂函数：
// utils/cjsLoader.js
import { createRequire } from 'node:module';
export function loadCJS(path) {
const url = new URL(path, import.meta.url);
return createRequire(url)(url);
}
// 使用时
const sarasa = loadCJS('./sarasa.cjs');
sarasa.sarasa2();此方案既满足 TDD 开发流程（本地测试 → 提交 Git → 上传 Botmaker），又保持代码可维护性与安全性，是服务端动态加载用户脚本场景下的最佳实践。
