Node.js 是基于 V8 引擎的 JavaScript 运行时，通过 libuv 实现异步 I/O，可直接监听端口处理真实 TCP 请求；无浏览器环境，使用 CommonJS 模块系统；依赖事件循环实现非阻塞，需规避同步操作与未捕获异步错误。
JavaScript 服务器端运行不是“可能不可能”的问题，而是早就在生产环境大规模落地了——核心就是 Node.js。它不是模拟、不是转译，是直接用 V8 引擎执行 JS 代码，跑在操作系统原生进程里。
为什么 Node.js 能当服务器？
Node.js 不是语言，是运行时（runtime）：它把 Chrome 的 V8 引擎 + 一套异步 I/O 的 C++ 绑定（libuv）打包在一起，让 JS 能调用文件读写、网络监听、进程管理这些系统能力。
关键点：
-
require('http')或require('express')启动的 HTTP 服务，和 Python 的Flask、Go 的net/http一样，监听真实端口，接收真实 TCP 请求 - 没有浏览器环境，所以
window、document这些全局变量不存在；但有global、process、__dirname等服务端专属对象 - 模块系统用的是
CommonJS（module.exports/require），ESM（import/export）需加"type": "module"或用.mjs后缀
npm start 背后发生了什么？
所谓“启动服务器”，本质就是执行一个 JS 文件，里面调用了 server.listen() 并保持进程不退出。常见错误不是代码写错，而是没理解进程生命周期：
立即学习“Java免费学习笔记（深入）”；
- 如果脚本执行完就退出（比如没调
listen，或listen失败没catch），服务根本不会起来 -
npm start默认执行package.json里"scripts": {"start": "node index.js"}—— 它只是个快捷命令，不是魔法 - 本地开发常用
npx nodemon index.js，它只是监听文件变化后自动重启node进程，底层仍是Node.js
HTTP 请求进来时，JS 怎么不卡住？
靠事件循环（Event Loop）和非阻塞 I/O。比如 fs.readFile() 不会等硬盘返回才继续执行，而是注册回调，把控制权交还给主线程。这带来两个现实影响：
- 同步操作（
fs.readFileSync、JSON.parse大文件、死循环）会阻塞整个服务，所有请求排队等待——线上必须避免 - 数据库、Redis、HTTP 调用都要走异步 API（
mysql2而非mysql，axios而非fetch在旧版本 Node 中需 polyfill） - 错误不能只靠
try/catch：网络超时、连接拒绝、DNS 失败这些异步错误得靠.catch()、on('error')或process.on('uncaughtException')
真正麻烦的从来不是“怎么跑起来”，而是进程崩溃后自动恢复、日志分级、内存泄漏排查、CPU 飙高时如何定位——这些和语言无关，但新手常误以为装个 Express 就等于搞定了服务器。
