必须用 try...catch 同步捕获 require 错误,因 CommonJS 规范要求模块缺失时直接抛出 MODULE_NOT_FOUND 异常;require 不能放顶层或 if 判断,降级逻辑写在 catch 中,fs.existsSync 预判不可靠。

CommonJS 的 require 是同步阻塞调用,模块路径不存在或加载失败时会**直接抛出 Error(通常是 MODULE_NOT_FOUND)**,而不是返回 undefined 或触发回调。因此,捕获它的错误只能靠 try...catch,且必须在调用时立即包裹——没有异步延迟,也不依赖事件监听。
用 try/catch 捕获 require 失败
这是唯一可靠的方式。CommonJS 规范要求 require 在找不到模块时同步抛出异常,所以:
- 必须把
require(...)写在try块内,不能放在变量声明后单独执行 - 降级逻辑(如使用备用模块、返回默认值、记录日志)写在
catch中 - 注意:
catch捕获的是Error实例,可通过err.code === 'MODULE_NOT_FOUND'精准判断是否为模块缺失
常见降级策略示例
根据场景选择合适 fallback:
DMap GL地图JSAPI(dmapgl)开发指南。用于编写、审查、调试 DMap 地图 API 代码,涵盖地图初始化、覆盖物渲染、图层管理、事件处理、控件交互等任务。当用户提及 dmap、dmapgl、jsapi‑gl 或相关地图开发需求时自动触发。
-
加载可选的 polyfill 或工具库:
比如尝试加载abort-controller,失败则用空对象或轻量模拟实现 -
区分环境加载不同实现:
开发时用本地 mock 模块,生产时 require 实际服务模块,失败则 throw 明确错误 -
动态条件加载(慎用):
结合process.env或运行时特征判断,失败时不硬报错,而是跳过该功能分支
注意 Node.js 特定限制
某些情况 try/catch 无法覆盖:
立即学习“Java免费学习笔记(深入)”;
-
require出现在模块顶层(非函数内)时,错误会在模块加载阶段抛出,无法被外层try捕获 —— 此时只能靠启动前检查或构建时预处理 - ESM 模块中混用
require(如通过createRequire)仍需同样try/catch,但要注意import()是异步的,不适用此方式 - 第三方包内部的
require失败,你无法直接捕获,只能监听process.on('uncaughtException')做兜底(不推荐用于业务逻辑)
避免常见陷阱
别踩这些坑:
- 不要写
if (require) {...}——require总是存在的,问题在于它执行时是否成功 - 不要试图用
fs.existsSync预判路径再require—— 路径存在不代表能解析(比如循环依赖、权限问题),反而增加开销和误判 - 不要在
catch里再次require同名模块 —— 可能陷入无限递归或重复失败

















