17370845950

Node.js是运行JavaScript的服务器端环境，基于V8引擎，提供文件、网络等API；支持console.log（输出到终端）和require（CommonJS模块加载），但无浏览器API；适用于I/O密集型服务、实时应用及前端工具链。

Node.js 不是 JavaScript 的某种“升级版”，而是让 JavaScript 能在浏览器外运行的运行时环境——它用 Chrome 的 V8 引擎执行 JS 代码，并自带一套面向服务端的 API（比如文件读写、网络通信）。

Node.js 能直接运行 console.log 和 require 吗？

能，但行为和浏览器完全不同：

• console.log 输出到终端（不是浏览器控制台），支持颜色、对象展开等终端友好特性
• require 是 CommonJS 模块系统的核心，用于加载本地文件（require('./util')）、内置模块（require('fs')）或 npm 包（require('express')），不支持 ES6 的 import（除非启用 --experimental-modules 或用 .mjs 后缀）
• 没有 window、document、fetch（原生），但可以用 global 查看全局对象，用 node-fetch 或 undici 补上 HTTP 客户端能力

什么场景下该选 Node.js 而不是 Python/Go？

适合 I/O 密集、快速迭代、团队已熟悉 JS 的后端任务：

• REST API / GraphQL 服务（配合 express、fastify）
• 实时应用：聊天室、协作编辑（靠 ws 或 socket.io，事件驱动模型天然匹配）
• 前端构建工具链：Webpack、Vite、ESLint 都基于 Node.js，你每天都在用它，只是没感知
• CLI 工具开发：npm 包本质就是 Node.js 脚本，#!/usr/bin/env node 开头就能当命令行程序跑
• 不适合 CPU 密集型任务（如视频转码、科学计算），长期阻塞会拖垮整个事件循环

为什么 fs.readFile 和 fs.readFileSync 差这么多？

这是 Node.js “非阻塞 I/O”理念最典型的体现：

• fs.readFile 是异步的：立刻返回，读完才触发回调或 resolve Promise，不卡主线程
• fs.readFileSync 是同步的：调用后代码暂停，等文件读完才继续，会阻塞整个进程——只应在启动阶段（如读配置）或脚本工具中谨慎使用
• 错误处理方式不同：readFile 的回调第一个参数是 err；readFileSync 出错直接 throw，必须用 try/catch

const fs = require('fs');

// 推荐：异步，不阻塞
fs.readFile('./config.json', 'utf8', (err, data) => {
  if (err) throw err;
  console.log(JSON.parse(data));
});

// 谨慎：同步，阻塞主线程
try {
  const data = fs.readFileSync('./config.json', 'utf8');
  console.log(JSON.parse(data));
} catch (err) {
  console.error(err);
}

真正容易被忽略的是：Node.js 的单线程 + 事件循环模型，意味着任何长时间运行的 JS 计算（比如 for (let i = 0; i ）都会让所有请求排队等待——这不是 I/O 问题，而是纯 JS 执行占满线程。遇到这类情况，得拆成微任务（setImmediate）、用 Worker Threads，或者干脆换语言。