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”理念最典型的体现：
立即学习“Java免费学习笔记（深入）”；
-
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，或者干脆换语言。
