不想重复引入Node.js常用模块，除全局变量外有何替代方案？

我完全懂这种每次新建JS文件都要敲一遍const async = require('async'); const _ = require('lodash');的烦躁——重复代码不仅浪费时间，还容易漏写。你提到的全局变量问题也很关键，确实会给单元测试带来很多麻烦，比如mock起来特别棘手。下面给你几个靠谱的替代方案，其中就包含你想要的require('common')这种最优解：

方案1：自定义common模块（你的最优选择） #

这个方案完全符合你的需求，只需要一次定义，就能在所有文件里通过require('common')（或调整后路径）引入所有常用工具：

步骤1：创建统一导出的common模块 #

在项目根目录新建common.js文件，把所有你常用的模块统一导出：

// common.js
module.exports = {
  // 你的核心常用工具
  async: require('async'),
  _: require('lodash'),
  // 可以按需添加其他高频模块
  fs: require('fs').promises,
  path: require('path'),
  moment: require('moment')
};

步骤2：在业务文件中引入 #

现在在任何需要的文件里，只需要一行代码就能拿到所有工具：

// 方式1：解构导入（推荐，按需取用到的工具）
const { async, _, fs } = require('./common'); // 根据文件位置调整相对路径

// 直接使用
_.map([1,2,3], num => num * 2);
async.series([...], callback);

// 方式2：整体导入
const common = require('./common');
common.path.join(__dirname, 'file.txt');

这个方案的核心优势： #

• 零重复代码：一次定义，全项目复用
• 无全局污染：所有工具都是局部变量，完全不影响单元测试
• 易于扩展：随时可以在common.js里添加新的常用模块
• 测试友好：单元测试时可以轻松mock整个common模块，比如替换lodash为测试用的模拟版本：

  // Jest测试示例
  jest.mock('./common', () => ({
    _: {
      map: jest.fn(() => ['模拟结果'])
    },
    async: {
      series: jest.fn((tasks, cb) => cb(null, '模拟串行执行结果'))
    }
  }));
  

方案2：简化模块路径（无需写相对路径） #

如果不想每次都写./common这种相对路径，可以把common模块放到Node.js的自动搜索路径里，实现直接require('common')：

方法A：放到项目的node_modules目录 #

直接把common.js复制到项目根目录的node_modules文件夹里，这样就能直接：

const { async, _ } = require('common');

不过注意：node_modules通常用来存放第三方依赖，自己的模块放这里可能会和第三方包重名，所以更推荐下面的方法。

方法B：自定义模块搜索路径 #

在项目的入口文件（比如app.js）里，把你的工具目录添加到Node.js的模块搜索路径最前面：

// app.js
// 把项目根目录下的utils文件夹加入模块搜索路径
module.paths.unshift(__dirname + '/utils');

然后把common.js放到utils文件夹里，之后所有文件都可以直接require('common')了。

方案3：ES模块的导入映射（适合ES Module项目） #

如果你的项目已经使用ES模块（在package.json里设置了"type": "module"），可以用导入映射进一步简化：

步骤1：创建importmap.json #

在项目根目录新建importmap.json：

{
  "imports": {
    "common": "./common.js"
  }
}

步骤2：在Node.js中启用 #

需要启动时加上--experimental-import-maps参数：

node --experimental-import-maps app.js

步骤3：在文件中导入 #

现在可以直接用import引入：

import { async, _ } from 'common';

总结 #

最推荐的还是方案1的自定义common模块，既满足你想要的require('common')需求，又完全避免了全局变量的问题，同时对单元测试非常友好。

内容的提问来源于stack exchange，提问作者eighteyes