模块化

这一页现在不再承担“完整讲解模块化全部内容”的任务，而是作为一个更轻的导航入口存在。

原因很简单：模块化本身不是只属于一个目录的单点知识，而是同时横跨 JavaScript、Node.js 和构建三条主线。

如果把它单独写成一条厚主线，就很容易和内部专题重复。

1. 为什么还保留这一页

虽然模块化的细节已经分别下沉到不同目录，但它仍然值得保留一个总入口。

因为读者在学习时，经常会同时遇到这些问题：

1. import/export 到底属于语言层还是工程层
2. CommonJS 和 ES Module 为什么总是一起出现
3. package.json、exports、锁文件和模块化是什么关系
4. Tree Shaking、代码拆分为什么又会和模块化绑在一起

这些问题并不都属于同一个目录，所以保留一个入口页仍然有意义。

2. 这页应该怎么用

可以把这一页理解成：模块化知识地图，而不是模块化细节正文。

也就是说，这一页主要完成三件事：

1. 告诉你模块化这条主线分散在哪些目录里
2. 帮你判断一个问题更适合去哪篇专题里看
3. 避免在多个目录里重复讲同一批概念

3. 模块化到底横跨哪几条主线

3.1 JavaScript 主线

这里更适合看：

1. ES Module 作为语言层标准意味着什么
2. import/export 和模块作用域是什么关系
3. 浏览器运行时和模块边界怎么理解
4. 为什么写模块代码时要区分浏览器、Node.js 和构建阶段

对应专题：

1. 模块化、ES Module 与运行时边界

3.2 Node.js 主线

这里更适合看：

1. CommonJS 和 Node.js 里的 ESM
2. package.json、main、exports、type
3. 包是如何被解析、安装、锁定和复用的
4. npm、yarn、pnpm 的差异

对应专题：

1. 模块化、包管理与依赖生态

3.3 构建主线

这里更适合看：

1. 模块依赖为什么会影响打包结果
2. 为什么 ES Module 更利于 Tree Shaking
3. 模块代码如何被分析、转换、拆包和输出

对应专题：

1. Webpack 详解
2. Vite 详解

4. 一张更清楚的关系图

flowchart TD
    A[模块化] --> B[JavaScript]
    A --> C[Node.js]
    A --> D[构建]
    B --> E[ES Module import/export 运行时边界]
    C --> F[CommonJS ESM package.json 锁文件 包管理器]
    D --> G[Tree Shaking 代码拆分 打包输出]

这张图最重要的意思是：

1. 模块化不是孤立知识点
2. 它既涉及语言层，也涉及运行时和工程化
3. 真正稳定的写法，是把细节分别放回最合适的目录里

5. 怎么判断一个问题该去哪篇看

如果你遇到的是下面这些问题，通常可以这样判断：

你想搞清楚的问题	更适合去哪里看
import/export 是什么，浏览器里模块怎么跑	JavaScript
require、exports、package.json 怎么理解	Node.js
Tree Shaking、拆包、打包产物怎么来的	构建
为什么同样是模块化，不同环境行为不同	看 JavaScript，再看 Node.js

6. 推荐阅读顺序

如果是第一次系统整理这条主线，更自然的顺序通常是：

1. 看 模块化、ES Module 与运行时边界
2. 再看 模块化、包管理与依赖生态
3. 最后回到 Webpack 详解 或 Vite 详解，看模块化如何落到工程交付过程

这个顺序的原因是：

1. 先搞清楚模块本身是什么
2. 再搞清楚 Node.js 里包和模块如何组织
3. 最后再理解构建工具如何消费这些模块关系

7. 小结

这一页最想建立的认识是：

1. 模块化不是单独悬空的一条大主线
2. 它本质上横跨 JavaScript、Node.js 和构建三部分
3. 外层这页更适合作为知识地图，而不是重复讲一遍细节

如果只压缩成一句话，可以记住：

模块化要看，但更稳的看法不是把它当成一块孤岛，而是把它放回 JavaScript、Node.js 和构建三条主线里理解。