浏览器里的 JavaScript 很少要求你直接面对二进制数据、标准输入输出和进程退出状态，但在 Node.js 里，这些能力都是日常基本功。你写文件处理脚本、实现上传下载、封装命令行工具、与其他程序通过管道协作，最后都会落到 Buffer、编码、stdin / stdout / stderr 以及退出码这些概念上。
这一篇我们会先把“数据究竟以什么形式在 Node.js 里流动”这件事讲清楚。理解这一层以后，后面的流、网络和 CLI 工具才不会显得抽象。
为什么 Node.js 需要 Buffer？
在浏览器里，我们更多接触的是字符串、对象、数组这样的高层数据；但在 Node.js 中，很多数据源并不是天然的文本，而是一连串字节。比如：
- 读取文件时，文件内容本质上是字节流；
- 收到网络请求时，数据最初也是字节；
- 处理图片、压缩包、音视频片段时，更不可能直接当字符串处理。
这就是 Buffer 存在的原因。你可以把它理解成 Node.js 中用于表示原始二进制数据的一种基础结构。它不是“更底层的字符串”，而是一个专门面向字节处理的容器。
真正重要的不是背 API，而是先建立一个认知：文本只是字节的一种解释方式。同一串字节，如果按不同编码规则解释，得到的文本就可能完全不同；如果它本来就不是文本，而是图片、音频或压缩数据，那你根本不应该先把它转成字符串。
文本、字节和编码到底是什么关系？
很多 Node.js 里的“乱码”问题，表面上看像字符串问题，实际上根因都是编码边界没分清。
你可以先把关系理解成这样：
- 字节是底层存储单位；
- 文本是人类可读的字符序列；
- 编码是“如何把字符映射成字节、再把字节还原成字符”的规则。
只要这三层混在一起，问题就会层出不穷。比如：
- 你以为读到的是字符串，实际上读到的是
Buffer； - 你把一段 UTF-8 内容按别的方式解码，结果出现乱码；
- 你以字符数估长度，结果网络协议或文件格式要求的是字节长度。
所以，在 Node.js 中处理输入输出时，一个非常重要的意识是：先问清楚当前手里的东西到底是字节，还是已经被解释过的文本。如果这个前提没搞清楚，后面再写多少逻辑都容易出偏差。
stdin、stdout 和 stderr 为什么这么重要？
一旦你开始写脚本或 CLI，就会发现 Node.js 程序并不总是通过函数调用和页面点击来接收输入。很多时候，它是作为一个终端命令运行的，这时程序和外部世界最基础的交互方式就是标准输入输出。
这三者可以先这样理解：
stdin：程序从外部接收输入的通道；stdout：程序输出正常结果的通道；stderr：程序输出错误信息和异常诊断的通道。
这套机制之所以重要，是因为它让 Node 程序可以像真正的命令行工具一样参与更大的系统协作。比如一个脚本的输出，可以直接被另一个命令接收；正常结果和错误信息也能被分流处理。
因此，当你写 Node 工具时，不要只把 console.log 当作“打印看看”。更成熟的理解应该是：你的程序正在通过标准输出协议和外部环境协作。
命令行参数与退出码为什么属于输入输出的一部分？
很多人会把命令行参数和退出码看成两块单独知识点，但从程序交互的角度看，它们其实就是输入输出模型的一部分。
命令行参数决定了程序“收到什么指令”，而退出码决定了程序“以什么结果告诉外部自己执行成功还是失败”。这意味着：
- 你的 Node 脚本不只是读文件、算结果；
- 它还需要有清晰的入口参数约定；
- 以及明确的结束状态表达。
这对脚本、发布工具、检查命令和自动化任务尤其重要。一个命令是否成功，通常不该让调用方去猜测输出文本，而应该通过退出码明确表达。
总结
这一篇我们把 Node.js 基础阶段最后一块拼图补上了：Buffer 让你理解字节与文本的差异，编码让你知道字符串为什么会出错，标准输入输出让你看到程序如何和终端协作，而命令行参数与退出码则把这种协作补成了闭环。
理解了这一层以后，你就已经不再只是“在 Node 里写 JavaScript”，而是开始把它当成一个真正能处理数据、接收输入并和外部系统协作的运行时。
下一篇开始，专题会正式进入 Node.js 最关键的核心机制，从异步编程模型和事件循环开始。