Webpack5模块化黑魔法：CommonJS和ES Module混搭时发生了什么？

Webpack5模块化黑魔法：CommonJS和ES Module混搭时发生了什么？

如果你已经用了一段时间的Webpack，对基本的打包流程和配置不再陌生，但每当项目里同时出现require和import语句时，心里是不是总会咯噔一下？尤其是在维护一些历史项目，或者引入某些第三方库时，这种模块化规范混用的场景几乎无法避免。你可能会遇到一些看似诡异的错误：为什么用import导入一个CommonJS模块后，访问其导出内容需要加个.default？而用require去加载一个ES Module，拿到的对象结构又似乎不太对劲？

这些现象背后，是Webpack在默默施展它的“黑魔法”。它像一位技艺高超的翻译官，在幕后搭建了一座桥梁，让两种不同“语言”（模块规范）的代码能够顺畅交流。今天，我们就抛开表面的配置和API，直接深入到Webpack5打包产物的源码层面，亲手拆解这座桥梁的构造。我们将通过一系列具体的代码示例，对比编译结果的差异，重点剖析__webpack_require__.n等关键适配逻辑，彻底弄明白混用场景下，Webpack究竟做了什么，以及我们为什么会遇到那些特定的使用方式。

这篇文章面向的是已经熟悉Webpack基础，但在模块化混用场景下感到困惑的中级开发者。我们不满足于“怎么用”，更要探究“为什么这么用”。准备好了吗？让我们开始这次源码探险。

1. 模块化世界的两位“居民”：CommonJS与ES Module的本质差异

在深入Webpack的魔法之前，我们必须先理解它要调和的两个主角——CommonJS和ES Module——在本质上的不同。这不仅仅是语法上的require与import之别，更是两种截然不同的模块哲学和运行时机制。

CommonJS 的设计深受Node.js环境影响，其核心是动态加载。module.exports 可以是一个函数、一个对象、或任何值，并且这个赋值可以在模块代码的任何位置动态进行。require() 是一个同步的函数调用，执行时才会去加载并执行目标模块，然后将module.exports的值原样返回。它的导出是“值拷贝”的一种体现（对于原始类型是拷贝，对于对象则是引用拷贝）。

// CommonJS 模块 (math.cjs)
let count = 0;
function increment() { count++; }
// 导出一个包含方法和数据的对象
module.exports = {
  count,
  increment,
  getCurrentCount: () => count
};

ES Module 则是语言层面的标准，设计目标是静态可分析。export语句必须在模块顶层作用域，这使得打包工具和引擎能在代码执行前就确定模块的依赖关系，从而进行优化（如Tree Shaking）。它的导出是“动态只读引用”。导入方拿到的是一个指向模块内部变量的、不可重新绑定的“活”引用。

// ES Module 模块 (math.mjs)
export let count = 0; // 导出一个可变的绑定
export function increment() { count++; }
// 默认导出
export default function getCount() { return count; }

为了更清晰地对比，我们用一个表格来总结它们的关键区别：

注意：正是这些根本性的差异，使得Webpack在混合使用时必须进行额外的转换和包装，以确保它们能在