node的源码分析还挺多的，不过像我这样愣头完全平铺源码做解析的貌似还没有，所以开个先例，从一个API来了解node的调用链。
首先上一张整体的图，网上翻到的，自己懒得画：
这里的层次结构十分的清晰，从上到下如果翻译成语言层面，依次是JS、C++、windows(UNIX)的系统API。
最高层也就是我们自己写的JS代码，node会首先通过V8引擎进行编译解析成C++，随后将其分发给libuv，libuv根据操作系统的类型来分别调用底层的系统API。
下面通过fs.stat这个API来一步步探索整个过程。
JS => require(‘fs‘)
这个方法的调用从开发者的角度讲，只需要两行代码：
const fs = require(‘fs‘);fs.stat(path, [options], callback);
其中第一步，是获取内置模块fs，第二步，就是调用对应的方法。
其实两个可以合一起讲了，弄懂了模块来源，对应的api也就简单了。
在前面几章，只是很模糊和浅显的讲了一个注册内置模块的过程，其实在node的目录，有一个本地的JS库，简单的处理了参数：
// node/lib/fs.jsfs.stat = function(path, callback) { ?callback = makeStatsCallback(callback); ?path = getPathFromURL(path); ?validatePath(path); ?const req = new FSReqWrap(); ?req.oncomplete = callback; ?// const binding = process.binding(‘fs‘); ?binding.stat(pathModule.toNamespacedPath(path), req);};这是方法的源码，需要注意的只有最后一行，通过binding.stat来调用下层的C++代码，而这个binding是来源于process对象。
在之前内置模块初探的时候，我提到过一个代码包装，就是对于require的JS文件的外层有一个简单的wrap：
NativeModule.wrapper = [ ?‘(function (exports, require, module, process) {‘, ?‘\n});‘];NativeModule.wrap = function(script) { ?return NativeModule.wrapper[0] + script + NativeModule.wrapper[1];};source = NativeModule.wrap(source);这里的script对应的就是JS文件字符串，实际上最后生成的其实是一个自调用匿名函数。
node => process.binding
隐去了V8引擎编译JS代码的过程(主要这一步很恶心，暂时不想讲)，直接进入C++模块。
这个方法在内置模块引入时也提到过，就是GetBinding方法：
static void GetBinding(const FunctionCallbackInfo<Value>& args) { ?// ... ?// 找到对应的模块节点 ?node_module* mod = get_builtin_module(*module_v); ?Local<Object> exports; ?if (mod != nullptr) { ???// 初始化并返回一个对象 ???exports = InitModule(env, mod, module); ?} ?// ...}需要关注的代码只有get_builtin_module和InitModule两个。
在前面的某一章我讲过，node初始化会通过NODE_BUILTIN_MODULES宏将所有内置模块的相关信息整理成一个链表，通过一个静态指针进行引用。
所以，这里就通过那个指针，找到对应名字的内置模块，代码如下：
node_module* get_builtin_module(const char* name) { ?// modlist_builtin就是那个静态指针 ?return FindModule(modlist_builtin, name, NM_F_BUILTIN);}inline struct node_module* FindModule(struct node_module* list,const char* name,int flag) { ?struct node_module* mp; ?// 遍历链表找到符合的模块信息 ?for (mp = list; mp != nullptr; mp = mp->nm_link) { ???if (strcmp(mp->nm_modname, name) == 0) ?????break; ?} ?// 没找到的话mp就是nullptr ?CHECK(mp == nullptr || (mp->nm_flags & flag) != 0); ?return mp;} 这里传入的字符串是fs，而每一个模块信息节点的nm_modname代表模块名，所以直接进行字符串匹配就行了。
返回后只是第一步，第二步就开始真正的加载了：
static Local<Object> InitModule(Environment* env, node_module* mod, Local<String> module) { ?// 生成一个新对象作为fs ?Local<Object> exports = Object::New(env->isolate()); ?// ... ?mod->nm_context_register_func(exports, unused, env->context(), mod->nm_priv); ?return exports;}这里调用的是模块内部的一个方法，从名字来看也很直白，即带有上下文的模块注册函数。
在前面生成模块链表的方法，有这么一段注释：
// This is used to load built-in modules. Instead of using// __attribute__((constructor)), we call the _register_<modname>// function for each built-in modules explicitly in// node::RegisterBuiltinModules(). This is only forward declaration.// The definitions are in each module‘s implementation when calling// the NODE_BUILTIN_MODULE_CONTEXT_AWARE.#define V(modname) void _register_##modname(); ?NODE_BUILTIN_MODULES(V)#undef V
从最后面一行可以看出，注册方法时来源于另外一个宏，如下：
#define NODE_BUILTIN_MODULE_CONTEXT_AWARE(modname, regfunc) ??????????????????\ ?NODE_MODULE_CONTEXT_AWARE_CPP(modname, regfunc, nullptr, NM_F_BUILTIN)
这个宏会在每一个单独的模块C++文件的末尾调用，形式大同小异，以fs模块为例：
NODE_BUILTIN_MODULE_CONTEXT_AWARE(fs, node::fs::Initialize)
这里的第一个参数fs是模块名，而第二个是初始化方法，一般来说负责初始化一个对象，然后给对象添加一些方法。
当然，以fs为例，看一下初始化的内容：
void Initialize(Local<Object> target, Local<Value> unused, Local<Context> context, void* priv) { ?Environment* env = Environment::GetCurrent(context); ?// ...大量SetMethod ?env->SetMethod(target, "mkdir", MKDir); ?env->SetMethod(target, "readdir", ReadDir); ?env->SetMethod(target, "stat", Stat); ?env->SetMethod(target, "lstat", LStat); ?env->SetMethod(target, "fstat", FStat); ?env->SetMethod(target, "stat", Stat); ?// ...还有大量代码}可见，初始化就是给传入的对象设置一些属性，属性名就是那些熟悉的api了。
这里只看stat，本地方法对应Stat，简化后如下：
static void Stat(const FunctionCallbackInfo<Value>& args) { ?Environment* env = Environment::GetCurrent(args); ?// 参数检测 options是可选的 ?const int argc = args.Length(); ?CHECK_GE(argc, 2); ?// 第一个参数必定是路径 ?BufferValue path(env->isolate(), args[0]); ?CHECK_NE(*path, nullptr); ?// 这玩意不管 ?FSReqBase* req_wrap_async = GetReqWrap(env, args[1]); ?if (req_wrap_async != nullptr) { ?// stat(path, req) ???// 注意倒数第二个参数！！！ ???AsyncCall(env, req_wrap_async, args, "stat", UTF8, AfterStat, ?????????????uv_fs_stat, *path); ?} else { ?// stat(path, undefined, ctx) ???// ... ???// 注意倒数第二个参数！！！ ???int err = SyncCall(env, args[2], &req_wrap_sync, "stat", uv_fs_stat, *path); ???// ... ?}}// AsyncCall => AsyncDestCalltemplate <typename Func, typename... Args>inline FSReqBase* AsyncDestCall(/*很多参数*/, Func fn, Args... fn_args) { ?// ... ?int err = fn(env->event_loop(), req_wrap->req(), fn_args..., after); ?// ...}template <typename Func, typename... Args>inline int SyncCall(/*很多参数*/, Func fn, Args... args) { ?// ... ?int err = fn(env->event_loop(), &(req_wrap->req), args..., nullptr); ?// ...}省略了很多很多(大家都不想看)的代码，浓缩出了核心的调用，就是uv_fs_stat。
这里的if、else主要是区别同步和异步调用，那个after就是代表有没有callback，简单了解下就OK了。
libuv => uv_fs_stat
至此，正式进入第三阶段，libuv层级。
这个框架的代码十分清爽，给你们看一下：
int uv_fs_stat(uv_loop_t* loop, uv_fs_t* req, const char* path, uv_fs_cb cb) { ?int err; ?// 初始化一些信息 ?INIT(UV_FS_STAT); ?// 处理路径参数 ?err = fs__capture_path(req, path, NULL, cb != NULL); ?if (err) { ???return uv_translate_sys_error(err); ?} ?// 实际操作 ?POST;}完全不用省略任何代码，每一步都很清晰，INIT宏的参数是一个枚举，该枚举类包含所有文件操作的枚举值。
这里首先是初始化stat相关的一些信息，如下：
#define INIT(subtype) ??????????????????????????????????????????????????????????do { ???????????????????????????????????????????????????????????????????????????if (req == NULL) ???????????????????????????????????????????????????????????????return UV_EINVAL; ??????????????????????????????????????????????????????????uv_fs_req_init(loop, req, subtype, cb); ????????????????????????????????????} ????????????????????????????????????????????????????????????????????????????while (0)INLINE static void uv_fs_req_init(uv_loop_t* loop, uv_fs_t* req, uv_fs_type fs_type, const uv_fs_cb cb) { ?uv__once_init(); ?UV_REQ_INIT(req, UV_FS); ?req->loop = loop; ?req->flags = 0; ?// 只有这一步是类型相关的 ?req->fs_type = fs_type; ?req->result = 0; ?req->ptr = NULL; ?req->path = NULL; ?req->cb = cb; ?memset(&req->fs, 0, sizeof(req->fs));}因为代码比较简单直白，所以就懒得省略了。
这里的宏是一个公共宏，所有文件操作相关的调用都要经过这个宏来进行初始化。在参数上，loop(事件轮询)、req(文件操作的相关对象)、cb(回调函数)都基本上不会变，所以实际上唯一区别操作类型的只有subtype。
第二步是对路径的处理，我觉得应该不会有人想知道内容是什么。
所以直接进入最后一步，POST。这个框架也真是可以的，所有的文件操作都通过三件套批量处理了。
这个宏如下：
#define POST ???????????????????????????????????????????????????????????????????do { ???????????????????????????????????????????????????????????????????????????if (cb != NULL) { ??????????????????????????????????????????????????????????????uv__req_register(loop, req); ?????????????????????????????????????????????????uv__work_submit(loop, &req->work_req, uv__fs_work, uv__fs_done); ?????????????return 0; ??????????????????????????????????????????????????????????????????} else { ???????????????????????????????????????????????????????????????????????uv__fs_work(&req->work_req); ?????????????????????????????????????????????????return req->result; ????????????????????????????????????????????????????????} ??????????????????????????????????????????????????????????????????????????} ????????????????????????????????????????????????????????????????????????????while (0)cb来源于node调用中的最后一个参数，同步情况下传的是一个Undefined，并不需要一个回调函数。
对于开发者来说同步异步可能只是书写流程的小变化，但是对于libuv来说却不太一样，因为框架本身同样掌握着事件轮询，在异步情况下，这里的处理需要单独开一个线程进行处理，随后通过观察者模式通知异步调用结束，需要执行回调函数。
另外一个不同点是，同步调用直接返回一个结果，异步调用会包装结果作为回调函数的参数然后进行调用，通过上面的if、else结构也能看出来。
windowsAPI
这里的处理分同步和异步。
先看同步：
static void uv__fs_work(struct uv__work* w) { ?uv_fs_t* req; ?// ...#define XX(uc, lc) ?case UV_FS_##uc: fs__##lc(req); break; ?// 枚举值为UV_FS_STAT ?switch (req->fs_type) { ???// ... ???XX(CLOSE, close) ???XX(READ, read) ???XX(WRITE, write) ???XX(FSTAT, fstat) ???// ... ???default: ?????assert(!"bad uv_fs_type"); ?}}这个地方，上面的那个枚举值终于起了作用，省略了一些无关代码，最终的结果通过宏，指向了一个叫fs__fstat函数。
static void fs__fstat(uv_fs_t* req) { ?int fd = req->file.fd; ?HANDLE handle; ?VERIFY_FD(fd, req); ?// 保证可以获取到对应的文件句柄 ?handle = uv__get_osfhandle(fd); ?// 错误处理 ?if (handle == INVALID_HANDLE_VALUE) { ???SET_REQ_WIN32_ERROR(req, ERROR_INVALID_HANDLE); ???return; ?} ?// 这里进行变量赋值 ?if (fs__stat_handle(handle, &req->statbuf, 0) != 0) { ???SET_REQ_WIN32_ERROR(req, GetLastError()); ???return; ?} ?req->ptr = &req->statbuf; ?// 返回0 ?req->result = 0;}这里有两个方法需要注意：
1、uv__get_osfhandle 获取文件句柄
2、fs__stat_handle 获取文件信息
源码如下：
INLINE static HANDLE uv__get_osfhandle(int fd){ ?HANDLE handle; ?UV_BEGIN_DISABLE_CRT_ASSERT(); ?// windowsAPI 根据文件描述符获取文件句柄 ?handle = (HANDLE) _get_osfhandle(fd); ?UV_END_DISABLE_CRT_ASSERT(); ?return handle;}INLINE static int fs__stat_handle(HANDLE handle, uv_stat_t* statbuf, int do_lstat) { ?// ... ?// windowsAPI ?nt_status = pNtQueryInformationFile(handle, ?????????????????????????????????????&io_status, ?????????????????????????????????????&file_info, ?????????????????????????????????????sizeof file_info, ?????????????????????????????????????FileAllInformation); ?/* Buffer overflow (a warning status code) is expected here. */ ?if (NT_ERROR(nt_status)) { ???SetLastError(pRtlNtStatusToDosError(nt_status)); ???return -1; ?} ?// windowsAPI ?nt_status = pNtQueryVolumeInformationFile(handle, ???????????????????????????????????????????&io_status, ???????????????????????????????????????????&volume_info, ???????????????????????????????????????????sizeof volume_info, ???????????????????????????????????????????FileFsVolumeInformation); ?// ...文件信息对象的处理}可以看出，最后的底层调用了windows的API来获取对应的文件句柄，然后继续获取对应句柄的文件信息，将信息处理后弄到req->ptr上，而node中对于同步处理的结果代码如下：
Local<Value> arr = node::FillGlobalStatsArray(env, static_cast<const uv_stat_t*>(req_wrap_sync.req.ptr));args.GetReturnValue().Set(arr);
这里的req_wrap_sync.req.ptr就是上面通过windowAPI获取到的文件信息内容。
异步情况如下：
void uv__work_submit(uv_loop_t* loop, ?struct uv__work* w, ?void (*work)(struct uv__work* w), ?void (*done)(struct uv__work* w, int status)) { ?uv_once(&once, init_once); ?w->loop = loop; ?w->work = work; ?w->done = done; ?post(&w->wq);}先看那个奇怪的post：
static void post(QUEUE* q) { ?// 上锁 ?uv_mutex_lock(&mutex); ?// 关于QUEUE的分析可见https://www.jianshu.com/p/6373de1e117d ?// 知道是个队列就行了 ?QUEUE_INSERT_TAIL(&wq, q); ?if (idle_threads > 0) ???uv_cond_signal(&cond); ?// 解锁 ?uv_mutex_unlock(&mutex);}由于异步涉及到事件轮询，所以代码实质上要稍微复杂一点，但是总体来说并不需要关心那么多。
这里有一个空闲线程的判断，不管，直接看那个处理方法：
void uv_cond_signal(uv_cond_t* cond) { ?if (HAVE_CONDVAR_API()) ???uv_cond_condvar_signal(cond); ?else ???// 初始化一个状态变量防止线程的竞争情况 ???// 反正也是个windowsAPI ???uv_cond_fallback_signal(cond);}static void uv_cond_condvar_signal(uv_cond_t* cond) { ?// windowsAPI ?pWakeConditionVariable(&cond->cond_var);}你会发现，这只是防止线程竞态而需要生成一个状态变量。
其实这个地方已经涉及到libuv中事件轮询的控制了，每次loop会从handle中取一个req，然后执行work，然后通知node完成，可以执行回调函数done了。
暂时不需要知道那么多，在uv__work_submit方法中，对应的赋值是这4个参数：
uv__work_submit(loop, &req->work_req, uv__fs_work, uv__fs_done);
其中第三个参数就是刚才同步获取文件信息的方法，而第四个就是在获取完毕会回调函数的调用：
static void uv__fs_done(struct uv__work* w, int status) { ?uv_fs_t* req; ?req = container_of(w, uv_fs_t, work_req); ?uv__req_unregister(req->loop, req); ?if (status == UV_ECANCELED) { ???assert(req->result == 0); ???req->result = UV_ECANCELED; ?} ?// 执行回调 ?req->cb(req);}异步调用因为在回调函数带了结果，所以返回值不能跟同步一样，最后的处理有些许不一样：
template <typename Func, typename... Args>inline FSReqBase* AsyncDestCall(/*很多参数*/) { ?// ... ?if (err < 0) { ???// ... ?} else { ???req_wrap->SetReturnValue(args); ?} ?// 返回另外的值 ?return req_wrap;}void FSReqWrap::SetReturnValue(const FunctionCallbackInfo<Value>& args) { ?// 设成undefined ?args.GetReturnValue().SetUndefined();}简单讲，fs.statSync返回一个Stat对象，而fs.stat返回undefined。这个可以很简单的测试得到结果，我这里就不贴图了，已经够长了。
深入出不来nodejs源码-从fs.stat方法来看node架构
原文地址：https://www.cnblogs.com/QH-Jimmy/p/9395985.html