第一章： 思想转变与 Node.js 初探

在本章中，我们将循序渐进，完成从前端到后端的关键一跃：

1. 首先，我们将探讨 “为什么选择 Node.js”，理解其在现代后端开发中的生态位。
2. 接着，我们将深入对比 Node.js 与浏览器的核心差异，这是思维转变的基石。
3. 然后，我们将动手 搭建一个专业的开发环境，并掌握版本管理工具。
4. 之后，我们将编写并运行第一个脚本，并接触 REPL 这个强大的调试工具。
5. 最后，我们将初步揭开 Node.js 事件循环 的神秘面纱，理解其高性能的根源。

1.1. 从浏览器到服务器：一场思维的迁徙

痛点背景: 作为一名前端专家，我们非常擅长在浏览器这个“沙盒”中构建复杂的用户界面。但我们也深刻体会到它的局限性：无法直接操作文件、无法持久化存储数据（localStorage 是临时的）、无法自由地访问网络资源（受同源策略限制）、代码生命周期随用户关闭标签页而结束。当我们渴望掌控完整的应用数据流，去创造 API 而非仅仅消费 API 时，我们就必须寻找一个能突破这些限制的环境。

解决方案: Node.js 正是那个让我们熟悉的 JavaScript 语言得以突破浏览器束缚，进入服务器领域的关键。它是一个基于 Chrome V8 引擎的 JavaScript 运行时环境 (Runtime Environment)，允许我们使用 JavaScript 来编写后端服务，直接与操作系统交互，从而获得读写文件、操作数据库、创建网络服务等完整的后端能力。

1
2
3
4
5
6
7
8

// hello-node.js
// 这是一个在 Node.js 环境中运行的简单脚本

// 1. Node.js 可以直接访问全局的 `process` 对象，获取环境信息
const nodeVersion = process.version;

// 2. 它可以使用 `console.log`，就像在浏览器中一样
console.log(`你好，世界！你正在使用 Node.js 版本: ${nodeVersion}`);

1
2
$ node hello-node.js
你好，世界！你正在使用 Node.js 版本: v20.11.1

这看似简单的一步，标志着我们已经从前端开发者，迈出了成为“架构思维觉醒者”的第一步。我们的代码不再仅仅响应用户的点击，而是可以作为服务的源头，24 小时不间断地运行。

1.2. 核心差异对比：不止是 window 的缺席

痛点背景: 初次接触 Node.js 时，最常见的困惑是：“这不还是 JavaScript 吗？有什么不同？” 如果我们带着纯粹的前端思维来编写 Node.js 代码，很快就会遇到各种问题。比如尝试访问 document 对象，或者不理解为什么一个简单的文件读取就需要回调函数。

解决方案: 我们必须从根源上建立一个新的心智模型，清晰地认识到 Node.js 环境与浏览器环境的本质区别。这不仅仅是 API 的增减，更是运行环境、使命和能力的根本不同。

1.3. 环境搭建：工欲善其事，必先利其器

痛点背景: 直接从官网下载安装 Node.js 固然可以，但在真实的项目开发中，我们经常需要同时维护多个项目，而这些项目可能依赖于不同版本的 Node.js。如果全局只安装一个版本，切换项目时可能会导致依赖冲突或运行错误，严重影响开发效率。

解决方案: 使用 NVM (Node Version Manager) 是 2025 年管理 Node.js 版本的最佳实践。它允许我们在同一台机器上安装和切换多个 Node.js 版本，为每个项目创建隔离且稳定的运行环境。

1
2

# 使用 curl
curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.7/install.sh | bash

1
2
3
4
5

# 安装最新的 LTS 版本
nvm install --lts

# 切换使用该版本
nvm use --lts

1
2

node -v
npm -v

<div class="runbox-container" data-runbox-label="执行结果" data-runbox-output="console" data-runbox-collapsed="true">
    <div class="runbox-result collapsed">
        <div class="runbox-result-content">
            <pre class="runbox-output runbox-console"><code>&lt;!--code5--&gt;</code></pre>
        </div>
    </div>
</div>

1
2
3
4
5
6
7
8

# 查看可安装的版本列表
nvm list available

# 安装最新的 LTS 版本
nvm install lts

# 切换使用该版本
nvm use [version_number] # 将 [version_number] 替换为刚安装的版本号

1
2

node -v
npm -v

1.4. 第一个脚本与 REPL

痛点背景: 学习一门新语言或平台时，我们希望能有一个快速反馈的工具，用于测试小段代码、验证 API 的用法，而不必每次都创建一个完整的 .js 文件再运行。

解决方案: Node.js 提供了两种方式来满足这一需求：直接运行脚本文件，以及使用交互式环境 REPL。

1.4.1. 运行脚本文件

这是最常见的执行方式，我们在 1.1 小节已经见过。它适用于执行完整的、成体系的程序。

1. 创建一个文件 app.js。
2. 在文件中编写 JavaScript 代码。
3. 在终端中使用 node 命令执行它：node app.js。

1.4.2. 使用 REPL 交互式环境

启动方式: 在终端里直接输入 node 并回车。

1
2
3
4

$ node
Welcome to Node.js v20.11.1.
Type ".help" for more information.
>

现在，我们可以像在浏览器的 Console 里一样输入代码：

1
2
3
4
5
6

> const os = require('os'); // Node.js 中引入模块的方式
> console.log(`你的电脑用户名是: ${os.userInfo().username}`);
你的电脑用户名是: prorise
> 10 + 20 * 5
110
> .exit // 输入 .exit 或按两次 Ctrl+C 退出 REPL

1.5. 事件循环 (Event Loop) 初识

痛点背景: 前端开发者对事件循环并不陌生，它协调着 UI 渲染、用户交互和异步任务（如 setTimeout, Promise）。然而，如果将这个模型直接套用到后端，会很难理解 Node.js 为何能用单线程处理成千上万的并发连接而不会被阻塞。

解决方案: 我们需要理解 Node.js 事件循环的核心使命与浏览器的不同。Node.js 的事件循环是其 “单线程、非阻塞 I/O” 模型的心脏。它的设计目标是：尽可能地将耗时的 I/O 操作（如读文件、查数据库、网络请求）委托给操作系统，而主线程则可以继续接收和处理其他请求，从而实现高并发。

让我们通过一个对比来建立初步认知：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

// a-sync-io.js
const fs = require('fs');

console.log('1. 开始读取文件...');
// 这是一个异步的、非阻塞的操作
fs.readFile('./hello-node.js', 'utf8', (err, data) => {
  // 当文件读取完成后，这个回调函数才会被放入事件循环的队列中等待执行
  if (err) {
    console.error('读取文件出错:', err);
    return;
  }
  console.log('3. 文件读取完成！');
});

// 主线程不会等待文件读取完成，而是立即执行下一行代码
console.log('2. 主线程继续执行其他任务...');

1
2
3
1. 开始读取文件...
2. 主线程继续执行其他任务...
3. 文件读取完成！

🤔 思考一下
如果我们将 fs.readFile 换成同步版本的 fs.readFileSync，输出的顺序会变成怎样？为什么说在服务器中滥用同步 I/O 操作是极其危险的？

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

// sync-io.js
const fs = require("fs");

console.log("1. 开始读取文件...");
// 这是一个同步的、阻塞的操作
try {
  fs.readFileSync("./hello-node.js", "utf8");
  console.log("3. 文件读取完成！");
} catch (err) {
  console.error("读取文件出错:", err);
}

// 主线程会等待文件读取完成后，才执行下一行代码
console.log("2. 主线程继续执行其他任务...");

1.6. 本章核心速查总结

1.7. 高频面试题与陷阱