深入解析Seajs模块化与加载机制

时间：2026-06-10 06:56

Sea js遵循CMD规范，其require方法是同步的，并配合依赖预加载来保证模块执行顺序正确。当使用构建工具合并多个模块文件时，每个define必须显式指定id、deps和factory这三个参数；否则，模块缓存键值会发生冲突，导致模块识别错误且加载失败。

Seajs 核心机制：模块加载、预加载与构建工具

由于长期使用，笔者对 Sea.js 的源码进行过深入探究。以下是对几个关键问题的理解与解析：

问题1：seajs的require(XXX)是如何实现模块加载的？

代码逻辑较为复杂，源代码的详细梳理放在末尾，这里先概述模块加载的整体流程：

从 seajs.use 方法入口，启动 use 所指定模块的加载流程。
use 到的模块在 mod 缓存中一定不存在。seajs 会创建一个新的 mod 对象，并赋予初始状态。
执行 mod.load 方法。
经过一系列逻辑后，调用 seajs.request 方法，请求模块文件。模块文件加载完成后，执行 define 方法。
define 方法分析并提取模块的依赖模块列表，将其保存起来。缓存 factory 但不执行。
依赖模块继续被加载，若存在更深层依赖则递归加载，直到所有被依赖的模块均加载完成。
所有模块加载完毕后，执行 use 方法中的 callback。
模块内部从 callback 开始执行，require 方法在此过程中被触发。

问题2：为什么需要预加载？

可以看到，seajs.use 会等待所有依赖模块加载完成后才执行 callback。也就是说，业务逻辑代码在执行之前，必须事先预加载所有被依赖的模块。为何必须如此？

答案在于逻辑代码中引用其他模块的 require 方法：

var mod = require(id);

这种写法决定了 mod 的获取是一个同步过程。如果模块代码在此之前未被预加载，就只能借助异步回调来实现，那整个 seajs 的执行逻辑将完全不同。异步会使得模块执行顺序难以追踪，逻辑变得难以控制。

问题3：为什么需要构建工具？

没有构建之前，各个依赖模块是单独加载的。这会导致过多的模块请求，严重影响页面加载性能。构建工具的核心目的就是解决模块合并加载的问题。

问题4：构建前后的代码究竟有些什么区别，为什么要这么做？

构建工具具体做了什么？既然其本质是合并代码，那是否只是简单地将几个模块文件拼接成一个文件？

当然不是。如果只是简单合并几个模块到一个文件，会发现该文件根本无法正常执行。问题出在 define 方法的实现机制上。

seajs 推荐定义模块时只传入 factory 参数。回顾 define 内部逻辑：当未传入 id（等同于模块的 url）时，会通过 getCurrentScript() 获取当前正在执行的模块文件的 url 路径，然后将该路径作为键值，与模块一起缓存到 cachedMods。关键在于：seajs 内部的模块缓存机制依赖每个模块的 url 作为缓存键值。require(id) 最终也是通过 url 键在 cachedMods 中找到对应模块。这个键值不能重复、不能出错，否则模块对应关系就会混乱。若将 a、b、c 三个模块简单合并到目标文件 x 后，getCurrentScript() 只能获取到 x 的路径，三个模块的键值将无法区分，执行必然出错。

因此，要合并多个模块，必须为每个模块明确指定 uri。也就是说，define 方法必须传入 id 参数。当 id 传入时，seajs 会将 id 转换为 url 作为缓存的键值。

如果只传 id 和 factory（即 define(id, factory)），那么 deps 为 undefined，define 方法就会执行 parseDependencies(factory.toString()) 提取依赖模块，后续会走解析模块路径、线上单独加载各个模块的逻辑，合并加载就失去了意义。

所以，合并加载时，define 必须正确传入 id、deps、factory 三个参数才能正常工作。

seajs 的 CMD 模块定义方法，提倡在编写模块阶段只传 factory 一个参数，而另外两个参数在后期构建阶段生成。上面解释了为什么这两个参数在构建后是必需的。至于为什么提倡只传 factory？因为人工传入 id 和 deps 极易出错，难以维护，而构建工具可以高效且准确地生成这些参数。