Découvrez le module de fichiers et le module principal dans Node dans un seul article

Cet article vous fera découvrir le module de fichiers et le module principal dans Node, et parlera de la recherche de modules de fichiers, de la compilation et de l'exécution de modules de fichiers, ainsi que de la compilation et de l'exécution des modules de base JavaScript et C/C++ I. j'espère que cela sera utile à tout le monde !

Lorsque nous utilisons Nodejs pour le développement quotidien, nous utilisons souvent require pour importer deux types de modules. L'un est le module que nous avons écrit nous-mêmes ou le module tiers installé à l'aide de npm. Node. Module de fichiers ; l'autre type est constitué des modules intégrés de Node que nous pouvons utiliser, tels que os, fs et d'autres modules. les modules sont appelés Il s'agit du module principal. 文件模块；另一类则是 Node 内置的提供给我们使用的模块，如 os、fs 等模块，这些模块被称为 核心模块。

需要注意的是，文件模块与核心模块的差异不仅仅在于是否被 Node 内置，具体到模块的文件定位、编译和执行过程，两者之间都存在明显的差别。不仅如此，文件模块还可以被细分为普通文件模块、自定义模块或 C/C++ 扩展模块等等，不同的模块在文件定位、编译等流程也存在诸多细节上的不同。

本文会就这些问题，理清文件模块与核心模块的概念以及它们在文件定位、编译或执行等流程的具体过程和需要注意的细节，希望对你有所帮助。

我们先从文件模块讲起。

文件模块

什么是文件模块呢？

在 Node 中，使用 .、.. 或 / 开头的模块标识符（也就是使用相对路径或绝对路径）来 require 的模块，都会被当作文件模块。另外，还有一类特殊的模块，虽然不含有相对路径或绝对路径，也不是核心模块，但是会指向一个包，Node 在定位这类模块时，会用 模块路径 逐个查找该模块，这类模块被称为自定义模块。

因此，文件模块包含两类，一类是带路径的普通文件模块，一类是不带路径的自定义模块。

文件模块在运行时动态加载，需要完整的文件定位、编译执行过程，速度比核心模块慢。

对于文件定位而言，Node 对这两类文件模块的处理有所不同。我们来具体看看这两类文件模块的查找流程。

普通文件模块的查找

对于普通的文件模块，由于携带路径，指向非常明确，查找耗时不会很久，因此查找效率比下文要介绍的自定义模块要高一些。不过还是有两点需要注意。

一是通常情况下，使用 require 引入文件模块时一般都不会指定文件扩展名，比如：

const math = require("math");

由于没有指定扩展名，Node 还不能确定最终的文件。在这种情况下，Node 会按 .js、.json、.node 的顺序补足扩展名，依次尝试，这个过程被称为 文件扩展名分析。

另外需要注意的是，在实际开发中，除了 require 一个具体的文件外，我们通常还会指定一个目录，比如：

const axios = require("../network");

在这种情况下，Node 会先进行文件扩展名分析，如果没有查找到对应文件，但是得到了一个目录，此时 Node 会将该目录当作一个包来处理。

具体而言，Node 会将目录中的 package.json 的 main 字段所指向的文件作为查找结果返回。如果 main 所指向的文件错误，或者压根不存在 package.json 文件，Node 会使用 index 作为默认文件名，然后依次使用 .js、.node 进行扩展名分析，逐个查找目标文件，如果没有找到的话就会抛出错误。

（当然，由于 Node 存在两类模块系统 CJS 和 ESM，除了查找 main 字段外，Node 还会采用其他方式，由于不在本文讨论范围内，就不再赘述了。）

自定义模块的查找

刚才提到，Node 在查找自定义模块的过程中，会使用到模块路径，那什么是模块路径呢？

熟悉模块解析的朋友应该都知道，模块路径是一个由路径组成的数组，具体的值可以看以下这个示例：

// example.js
console.log(module.paths);

打印结果：

可以看到，Node 中的模块存在一个模块路径数组，存放在 module.paths

Il convient de noter que la différence entre le module de fichiers et le module principal ne réside pas seulement dans le fait qu'il soit intégré par Node, mais également dans le processus de positionnement, de compilation et d'exécution des fichiers du module. Il existe des différences évidentes entre les deux. . De plus, les modules de fichiers peuvent également être subdivisés en modules de fichiers ordinaires, modules personnalisés ou modules d'extension C/C++, etc. Différents modules comportent également de nombreux détails qui diffèrent dans le positionnement des fichiers, la compilation et d'autres processus. 🎜🎜Cet article abordera ces problèmes et clarifiera les concepts de modules de fichiers et de modules de base ainsi que leurs processus et détails spécifiques auxquels il faut prêter attention lors de l'emplacement, de la compilation ou de l'exécution des fichiers. J'espère qu'il vous sera utile. 🎜🎜Commençons par le module de fichiers. 🎜

Module de fichiers

🎜Qu'est-ce qu'un module de fichiers ? 🎜🎜Dans Node, les modules requis utilisant des identifiants de module commençant par ., .. ou / (c'est-à-dire utilisant des chemins relatifs ou absolus) seront traités comme des modules de fichiers. De plus, il existe un type spécial de module. Bien qu'il ne contienne pas de chemin relatif ou de chemin absolu, et qu'il ne s'agisse pas d'un module principal, il pointe vers un package lorsque Node localise ce type de module, il utilisera <. code>chemin du module pour rechercher un par un. Ce module, ce type de module est appelé module personnalisé. 🎜🎜Par conséquent, les modules de fichiers incluent deux types, l'un est des modules de fichiers ordinaires avec des chemins et l'autre est des modules personnalisés sans chemins. 🎜🎜Le module de fichiers est chargé dynamiquement au moment de l'exécution, nécessitant un processus complet de positionnement, de compilation et d'exécution du fichier, et est plus lent que le module principal. 🎜🎜Pour le positionnement des fichiers, Node gère différemment ces deux types de modules de fichiers. Examinons de plus près les processus de recherche pour ces deux types de modules de fichiers. 🎜

Recherche de modules de fichiers ordinaires

🎜Pour les modules de fichiers ordinaires, puisque le chemin est porté, le pointage est très clair et la recherche ne prendra pas longtemps, l'efficacité de la recherche est donc supérieure à celle du module personnalisé présenté ci-dessous. Il reste cependant deux points à noter. 🎜🎜Tout d'abord, généralement, lors de l'utilisation de require pour introduire un module de fichier, l'extension du fichier n'est généralement pas spécifiée, par exemple : 🎜

(function(exports, require, module, __filename, __dirname) {
    // 模块代码
});

🎜Étant donné que l'extension n'est pas spécifiée, Node ne peut pas encore déterminer le fichier final. Dans ce cas, Node complétera les extensions dans l'ordre .js, .json et .node et les essaiera une par une. Ce processus est appelé analyse des extensions de fichiers. . 🎜🎜Une autre chose à noter est que dans le développement réel, en plus d'exiger un fichier spécifique, nous spécifions généralement également un répertoire, tel que : 🎜rrreee🎜Dans ce cas, Node effectuera d'abord une analyse d'extension de fichier Si le fichier correspondant était. introuvable, mais un répertoire a été obtenu. À ce stade, Node traitera le répertoire comme un package. 🎜🎜Plus précisément, Node renverra le fichier pointé par le champ main de package.json dans le répertoire comme résultat de recherche. Si le fichier pointé par main est erroné ou si le fichier package.json n'existe pas du tout, Node utilisera index comme nom de fichier par défaut, puis utilisera .js à son tour.code>, <code>.node effectue une analyse d'extension et recherche les fichiers cibles un par un. S'ils ne sont pas trouvés, une erreur sera générée. 🎜🎜 (Bien sûr, puisque Node dispose de deux types de systèmes de modules, CJS et ESM, en plus de trouver le champ principal, Node utilisera également d'autres méthodes. Comme cela sort du cadre de cet article, je n'entrerai pas dans les détails .) 🎜

Recherche de modules personnalisés

🎜Je viens de le mentionner, Node utilisera le chemin du module lors de la recherche de modules personnalisés. Alors, quel est le chemin du module. chemin du module ? 🎜🎜Les amis qui sont familiers avec l'analyse des modules doivent savoir que le chemin du module est un tableau composé de chemins. La valeur spécifique peut être vue dans l'exemple suivant : 🎜rrreee🎜Imprimer les résultats : 🎜🎜🎜🎜Vous pouvez voir que le module dans Node a un chemin de module array, qui stocke Dans module.paths, il est utilisé pour spécifier comment Node trouve les modules personnalisés référencés par le module actuel. 🎜

具体来讲，Node 会遍历模块路径数组，逐个尝试其中的路径，查找该路径对应的 node_modules 目录中是否有指定的自定义模块，如果没有就向上逐级递归，一直到根目录下的 node_modules 目录，直到找到目标模块为止，如果找不到的话就会抛出错误。

可以看出，逐级向上递归查找 node_modules 目录是 Node 查找自定义模块的策略，而模块路径便是这个策略的具体实现。

同时我们也得出一个结论，在查找自定义模块时，层级越深，相应的查找耗时就会越多。因此相比于核心模块和普通的文件模块，自定义模块的加载速度是最慢的。

当然，根据模块路径查找到的仅仅是一个目录，并不是一个具体的文件，在查找到目录后，同样地，Node 会根据上文所描述的包处理流程进行查找，具体过程不再赘述了。

以上是普通文件模块和自定义模块的文件定位的流程和需要注意的细节，接下来我们来看者两类模块是如何编译执行的。

文件模块的编译执行

当定位到 require 所指向的文件后，通常模块标识符都不带有扩展名，根据上文提到的文件扩展名分析我们可以知道，Node 支持三种扩展名文件的编译执行：

• JavaScript 文件。通过 fs 模块同步读取文件后编译执行。除了 .node 和 .json 文件，其他文件都会被当作 .js 文件载入。

• .node 文件，这是用 C/C++ 编写后编译生成的扩展文件，Node 通过 process.dlopen() 方法加载该文件。

• json 文件，通过 fs 模块同步读取文件后，使用 JSON.parse() 解析并返回结果。

在对文件模块进行编译执行之前，Node 会使用如下所示的模块封装器对其进行包装：

(function(exports, require, module, __filename, __dirname) {
    // 模块代码
});

可以看到，通过模块封装器，Node 将模块包装进函数作用域中，与其他作用域隔离，避免变量的命名冲突、污染全局作用域等问题，同时，通过传入 exports、require 参数，使该模块具备应有的导入与导出能力。这便是 Node 对模块的实现。

了解了模块封装器后，我们先来看 json 文件的编译执行流程。

json 文件的编译执行

json 文件的编译执行是最简单的。在通过 fs 模块同步读取 JSON 文件的内容后，Node 会使用 JSON.parse() 解析出 JavaScript 对象，然后将它赋给该模块的 exports 对象，最后再返回给引用它的模块，过程十分简单粗暴。

JavaScript 文件的编译执行

在使用模块包装器对 JavaScript 文件进行包装后，包装之后的代码会通过 vm 模块的 runInThisContext()（类似 eval） 方法执行，返回一个 function 对象。

然后，将该 JavaScript 模块的 exports、require、module 等参数传递给这个 function 执行，执行之后，模块的 exports 属性被返回给调用方，这就是 JavaScript 文件的编译执行过程。

C/C++ 扩展模块的编译执行

在讲解 C/C++ 扩展模块的编译执行之前，先介绍一下什么是 C/C++ 扩展模块。

C/C++ 扩展模块属于文件模块中的一类，顾名思义，这类模块由 C/C++ 编写，与 JavaScript 模块的区别在于其加载之后不需要编译，直接执行之后就可以被外部调用了，因此其加载速度比 JavaScript 模块略快。相比于用 JS 编写的文件模块，C/C++ 扩展模块明显更具有性能上的优势。对于 Node 核心模块中无法覆盖的功能或者有特定的性能需求，用户可以编写 C/C++ 扩展模块来达到目的。

那 .node 文件又是什么呢，它跟 C/C++ 扩展模块有什么关系？

事实上，编写好之后的 C/C++ 扩展模块经过编译之后就生成了 .node 文件。也就是说，作为模块的使用者，我们并不直接引入 C/C++ 扩展模块的源代码，而是引入 C/C++ 扩展模块经过编译之后的二进制文件。因此，.node 文件并不需要编译，Node 在查找到 .node 文件后，只需加载和执行该文件即可。在执行的过程中，模块的 exports 对象被填充，然后返回给调用者。

Il est à noter que le fichier .node généré par la compilation du module d'extension C/C++ a différentes formes sous différentes plateformes : Module d'extension C/C++ sous le système *nix Il est compilé dans un fichier objet partagé de liens dynamiques par des compilateurs tels que g++/gcc, avec l'extension .so sous Windows ; il est compilé dans un fichier de bibliothèque de liens dynamiques ; par le compilateur Visual C++, l'extension est .dll. Mais l'extension que nous utilisons réellement est .node. En fait, l'extension de .node est juste pour paraître plus naturelle. En fait, dans .dll sous >Windows

et un fichier .so sous *nix. .node 文件在不同平台下有不同的形式：在 *nix 系统下C/C++ 扩展模块被 g++/gcc 等编译器编译为动态链接共享对象文件，扩展名为 .so；在 Windows 下则被 Visual C++ 编译器编译为动态链接库文件，扩展名为 .dll。但是在我们实际使用时使用的扩展名却是 .node，事实上 .node 的扩展名只是为了看起来更自然一点，实际上，在 Windows 下它是一个 .dll 文件，在 *nix 下则是一个 .so 文件。

Node 在查找到要 require 的 .node 文件之后，会调用 process.dlopen() 方法对该文件进行加载和执行。由于 .node 文件在不同平台下是不同的文件形式，为了实现跨平台，dlopen() 方法在 Windows 和 *nix 平台下分别有不同的实现，然后通过 libuv 兼容层进行封装。下图是 C/C++ 扩展模块在不同平台下编译和加载的过程：

核心模块

核心模块在 Node 源代码的编译过程中，就编译进了二进制执行文件。在 Node 进程启动时，部分核心模块就被直接加载进内存中，所以这部分核心模块引入时，文件定位和编译执行这两个步骤可以省略掉，并且在路径分析中会比文件模块优先判断，所以它的加载速度是最快的。

核心模块其实分为 C/C++ 编写的和 JavaScript 编写的两部分，其中 C/C++ 文件存放在 Node 项目的 src 目录下，JavaScript 文件存放在 lib 目录下。显然，这两部分模块的编译执行流程都有所不同。

JavaScript 核心模块的编译执行

对于 JavaScript 核心模块的编译，在 Node 源代码的编译过程中，Node 会采用 V8 附带的 js2c.py 工具，将所有内置的 JavaScript 代码，包括 JavaScript 核心模块，转换为 C++ 里的数组，JavaScript 代码就这样以字符串的形式存储在 node 命名空间中。在启动 Node 进程时，JavaScript 代码就会直接加载进内存。

当引入 JavaScript 核心模块时，Node 会调用 process.binding() 通过模块标识符分析定位到其在内存中的位置，将其取出。在取出后，JavaScript 核心模块同样会经历模块包装器的包装，然后被执行，导出 exports 对象，返回给调用者。

C/C++ 核心模块的编译执行

在核心模块中，有些模块全部由 C/C++ 编写，有些模块则由 C/C++ 完成核心部分，其他部分则由 JavaScript 实现包装或向外导出，以满足性能需求，像 buffer、fs、os 等模块都是部分通过 C/C++ 编写的。这种 C++ 模块主内完成核心，JavaScript 模块主外实现封装的模式是 Node 提高性能的常见方式。

核心模块中由纯 C/C++ 编写的部分称为内建模块，如 node_fs、node_os 等，它们通常不被用户直接调用，而是被 JavaScript 核心模块直接依赖。因此，在 Node 的核心模块的引入过程中，存在这样一条引用链：

那 JavaScript 核心模块是如何加载内建模块的呢？

还记得 process.binding() 方法吗，Node 通过调用该方法实现将 JavaScript 核心模块从内存中取出。该方法同样适用于 JavaScript 核心模块，来协助加载内建模块。

具体到该方法的实现，加载内建模块时，首先创建一个 exports 空对象，然后调用 get_builtin_module() 方法取出内建模块对象，通过执行 register_func()

Une fois que Node a trouvé le fichier .node requis, il appellera la méthode process.dlopen() pour charger et exécuter le fichier. Étant donné que les fichiers .node ont différentes formes de fichiers sous différentes plates-formes, afin d'obtenir une compatibilité multiplateforme, la méthode dlopen() est utilisée dans Windows et Il existe différentes implémentations sous la plateforme *nix, puis elles sont encapsulées via la couche de compatibilité libuv. L'image ci-dessous montre le processus de compilation et de chargement des modules d'extension C/C++ sous différentes plateformes :

Module principal

Compilation du module principal dans la source Node code Au cours du processus, un fichier exécutable binaire est compilé. Lorsque le processus Node démarre, certains modules de base sont directement chargés dans la mémoire. Par conséquent, lorsque ces modules de base sont introduits, les deux étapes de localisation, de compilation et d'exécution du fichier peuvent être omises et seront jugées avant le module de fichier dans le chemin. analyse Sa vitesse de chargement est donc la plus rapide.

Le module principal est en fait divisé en deux parties écrites en C/C++ et JavaScript. Les fichiers C/C++ sont stockés dans le répertoire src du projet Node, et les fichiers JavaScript sont stockés dans le répertoire lib. Evidemment, les processus de compilation et d'exécution de ces deux modules sont différents.

Compilation et exécution du module principal JavaScript

🎜Pour la compilation du module principal JavaScript, lors du processus de compilation du code source de Node, Node utilisera L'outil js2c.py fourni avec la V8 convertit tout le code JavaScript intégré, y compris les modules de base JavaScript, en tableaux en C++. Le code JavaScript est stocké dans l'espace de noms du nœud sous forme de chaînes. Lors du démarrage du processus Node, le code JavaScript est chargé directement en mémoire. 🎜🎜Lorsqu'un module principal JavaScript est introduit, Node appellera process.binding() pour localiser son emplacement en mémoire grâce à l'analyse de l'identifiant du module et le récupérer. Après avoir été supprimé, le module principal JavaScript sera également encapsulé par le wrapper de module, puis exécuté, l'objet exports sera exporté et renvoyé à l'appelant. 🎜

Compilation et exécution des modules de base C/C++

🎜Dans les modules de base, certains modules sont tous écrits en C/C++, et certains modules sont La partie principale est complétée par C/C++, et d'autres parties sont empaquetées ou exportées par JavaScript pour répondre aux exigences de performances, telles que buffer, fs, os code> et les autres modules sont en partie écrits en C/C++. Ce mode de module C++ complétant le noyau à l'intérieur de la partie principale et de module JavaScript implémentant l'encapsulation en dehors de la partie principale est un moyen courant pour Node d'améliorer les performances. 🎜🎜Les parties du module principal écrites en C/C++ pur sont appelées modules intégrés, tels que node_fs, node_os, etc. Ils ne sont généralement pas appelés directement par l'utilisateur, mais les modules de base JavaScript en dépendent directement. Par conséquent, dans le processus d'introduction du module principal de Node, il existe une telle chaîne de référence : 🎜🎜🎜🎜Comment le module principal JavaScript charge-t-il le module intégré ? 🎜🎜Vous vous souvenez de la méthode process.binding() ? Node retire le module principal JavaScript de la mémoire en appelant cette méthode. Cette méthode fonctionne également avec les modules principaux JavaScript pour faciliter le chargement des modules intégrés. 🎜🎜Spécifique à l'implémentation de cette méthode, lors du chargement d'un module intégré, créez d'abord un objet vide d'exportation, puis appelez la méthode get_builtin_module() pour récupérer l'objet du module intégré, et exécutez register_func() remplit l'objet d'exportation et le renvoie enfin à l'appelant pour terminer l'exportation. Il s'agit du processus de chargement et d'exécution du module intégré. 🎜🎜Grâce à l'analyse ci-dessus, pour l'introduction d'une chaîne de référence telle que le module de base, en prenant le module os comme exemple, le processus général est le suivant : 🎜🎜🎜🎜🎜En résumé, le processus d'introduction du module os passe par l'introduction du module de fichier JavaScript et du module principal JavaScript. Le chargement et l'exécution du module intégré ainsi que le chargement et l'exécution du module intégré sont très lourds et compliqués. Cependant, pour l'appelant du module, étant donné que l'implémentation complexe et les détails sous-jacents sont masqués, l'importation de l'ensemble du module ne peut être effectuée que via require(), ce qui est très concis. amical. 🎜<h2 data-id="heading-10"><strong>Résumé</strong></h2> <p>Cet article présente les concepts de base des modules de fichiers et des modules de base ainsi que leurs processus et détails spécifiques auxquels il faut prêter attention lors de l'emplacement, de la compilation ou de l'exécution des fichiers. Plus précisément : </p> <ul> <li><p>Le module de fichiers peut être divisé en modules de fichiers ordinaires et modules personnalisés en fonction des différents processus de positionnement de fichiers. Les modules de fichiers ordinaires peuvent être localisés directement en raison de leurs chemins clairs, impliquant parfois le processus d'analyse des extensions de fichiers et d'analyse de répertoire ; les modules personnalisés effectueront une recherche en fonction du chemin du module, et après une recherche réussie, l'emplacement final du fichier sera effectué via une analyse de répertoire ; . </p></li> <li><p>Les modules de fichiers peuvent être divisés en modules JavaScript et modules d'extension C/C++ selon différents processus de compilation et d'exécution. Le module JavaScript est empaqueté par le wrapper de module et exécuté via la méthode <code>runInThisContext du module vm ; le module d'extension C/C++ est déjà un fichier exécutable généré après la compilation, donc il peut s'exécuter directement et renvoyer l'objet exporté à l'appelant. vm 模块的 runInThisContext 方法进行执行；C/C++ 扩展模块由于已经是经过编译之后生成的可执行文件，因此可直接执行，返回导出对象给调用方。

核心模块分为 JavaScript 核心模块和内建模块。JavaScript 核心模块在 Node 进程启动时便被加载进内存中，通过 process.binding() 方法可将其取出，然后执行；内建模块的编译执行会经历 process.binding()、get_builtin_module() 和 register_func()

Le module principal est divisé en module principal JavaScript et module intégré. Le module principal JavaScript est chargé en mémoire au démarrage du processus Node. Il peut être retiré puis exécuté via la méthode process.binding() ; via le processus Gestion des fonctions bind(), get_builtin_module() et register_func().

De plus, nous avons également obtenu la chaîne de référence pour Node pour présenter le module principal, c'est-à-dire le module de fichiers --->Module principal JavaScript-->module intégré, et avons également appris le module

C++ pour compléter le noyau du module principal, le module JavaScript implémente la méthode d'écriture du module d'encapsulation. Pour plus de connaissances sur la programmation, veuillez visiter :

Vidéos de programmation🎜 ! ! 🎜

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!