Node.js 的价值之一，在于它不只是“能跑 JavaScript”，而是能直接和操作系统打交道。路径、文件、命令行参数、环境变量、退出状态，这些在浏览器世界里要么不存在、要么几乎碰不到的东西，在 Node.js 里反而都是日常能力。
这一篇我们会把几个最常见也最重要的基础能力串起来：process、path、fs 和 url。目标不是把 API 手册通读一遍，而是先建立一套清楚的系统交互心智，这样你后面写脚本、写服务、写工具时，才不会把路径、文件和运行环境搅成一团。
process 为什么是 Node.js 的关键入口？
如果说浏览器世界里最有代表性的对象之一是 window，那么在 Node.js 里，最值得尽早建立熟悉感的全局入口往往就是 process。
原因很简单：只要问题和“当前程序自己”有关，很多时候最后都会回到 process 上。比如：
- 这个程序是怎么被启动的？
- 启动时带了哪些参数？
- 当前运行环境是什么？
- 现在在哪个目录下执行？
- 退出时应该返回什么状态？
这些都不是业务逻辑，但它们会决定 Node 程序在真实世界里怎么和外部环境协作。
process.argv：程序是如何被调用的
命令行参数是脚本和 CLI 工具的基础输入方式。你在终端里传给程序的那些额外参数，最终都会体现在 process.argv 中。
这意味着，只要你写的是需要接收外部输入的 Node 程序，比如：
- 批处理脚本；
- 构建脚本；
- 发布命令；
- 内部工具；
那么理解 process.argv 的结构和使用方式，就是第一步。
更重要的是，它会让你意识到一件事：Node 程序不是总靠函数调用传参的，很多时候它的输入本来就来自外部执行环境。
环境变量和当前工作目录
Node.js 程序运行时，除了命令行参数，还会受到环境变量和当前工作目录的影响。
环境变量经常用来承载：
- 端口号；
- 数据库连接信息；
- 第三方密钥；
- 功能开关；
- 环境标识。
而当前工作目录则经常决定：
- 相对路径是从哪里开始解析；
- 某些配置文件默认去哪里找；
- 程序执行时的上下文边界是什么。
很多初学者会把“当前文件所在目录”和“当前执行目录”混为一谈，但这两者并不相同。你可以把它们先理解成：
- 文件目录更偏模块自身的位置；
- 工作目录更偏程序是从哪里被启动的。
后面一旦你开始写工具脚本、批处理和服务启动逻辑，这个区别会非常重要。
退出码和进程状态
Node 程序最终不是只给人看输出，它还会把“我到底是成功还是失败”传递给外部系统，比如终端、CI、脚本编排器或操作系统。这就是退出码的重要性。
从工程视角看，一个命令是否执行成功，不只是看它打印了什么，更要看它以什么状态退出。也正因为如此，Node 工具和服务在失败路径上通常不应该“悄悄吞掉问题”，而应该尽量明确地暴露失败状态。
路径处理为什么不能靠字符串拼接？
Node.js 项目里，路径问题几乎是最常见的基础问题之一。很多人一开始会下意识地用字符串去拼路径，比如写成 dir + '/' + file，在简单场景下看起来也能用。但只要你稍微接触跨平台环境、嵌套目录或绝对路径，这种做法就会很快暴露问题。
所以，Node.js 才会专门提供 path 模块。
path.join 和 path.resolve 的思维差异
很多初学者第一次接触 path 模块时，最容易混淆的就是 join 和 resolve。它们都能“拼路径”，但心智并不一样。
你可以先这么理解：
path.join()更偏“把若干路径片段安全拼起来”；path.resolve()更偏“从当前基准出发，最终算出一个绝对路径”。
这个区别不是为了语义洁癖，而是会直接影响你最终得到的结果。如果你不知道自己要的是“相对组合结果”还是“绝对定位结果”，路径问题就很容易一会儿能跑、一会儿失效。
当前工作目录和当前文件目录不要混淆
路径处理里最常见的一个坑，就是把“当前执行目录”误当成“当前代码文件所在目录”。这两者在某些简单场景下可能碰巧一样，但本质上不是同一个东西。
举个很典型的例子：
- 你在项目根目录执行一个脚本；
- 这个脚本实际位于更深一层的子目录；
- 这时程序的当前工作目录和脚本文件目录就已经不是一回事了。
所以，在处理配置文件、模板文件、静态资源或脚本相对路径时，你必须先想清楚：你的基准到底应该是谁。
这个认知后面会反复出现，尤其是在 CLI、构建脚本和服务端资源读取场景里。
跨平台差异为什么值得提前注意
Node.js 生态天然强调跨平台，这意味着你的程序很可能既要在 macOS 或 Linux 上运行，也要在 Windows 上运行。路径分隔符、绝对路径形式和系统默认行为都可能不同。
也正因为如此，路径问题不应该靠“我机器上刚好能跑”来判断。只要你的代码里直接手写某种操作系统特定路径形式，它后面就很容易埋下兼容性问题。
这也是 path 模块真正的价值所在：它不是让你少写几个字符，而是帮你把路径处理从“手工猜”变成“交给运行时规则”。
fs：文件系统操作的最小心智
Node.js 和浏览器最显著的差异之一，就是它可以直接访问文件系统。这一能力看起来很强大，但也意味着你要开始认真面对真实的文件世界：编码、权限、路径、同步与异步、错误处理，这些都不再能被忽略。
文件操作不是只有“读”和“写”
很多初学者第一次接触 fs，往往只记住两个动作：
- 读取文件；
- 写入文件。
但真实项目里的文件系统操作往往还包括：
- 判断文件或目录是否存在；
- 创建目录；
- 遍历目录；
- 读取元信息；
- 追加内容；
- 删除或移动文件；
- 处理异常和权限问题。
也就是说，文件系统不是“某个 API”，而是一整类需要认真对待的外部资源。
同步与异步怎么选
Node.js 的文件系统 API 一般都会同时提供同步和异步两种思路。这时候很多人会陷入一个误区：要么觉得异步一定比同步高级，要么觉得同步写起来简单就无脑全用。
更稳妥的判断方式应该是看场景：
- 脚本启动阶段、一次性工具、小规模本地任务，使用同步方式有时完全合理；
- 服务端请求链路、高并发 I/O、持续运行程序，更应优先考虑异步方式，避免阻塞主线程。
这里没有绝对教条，关键是你要知道：文件系统操作本身是外部 I/O，它会花时间，也会失败，因此不能把它当成普通内存里的变量读写。
文件操作一定会失败，这不是例外
和内存中的对象不同，文件系统天然处在不稳定的外部环境里。一个读取动作可能失败的原因非常多，比如：
- 路径不存在；
- 没有权限；
- 文件编码和预期不一致；
- 当前工作目录不对；
- 文件内容损坏。
所以，一个成熟的 Node 程序在处理文件系统时，通常都会默认考虑失败路径，而不是把失败当作罕见情况。这个意识后面会直接影响你写脚本和服务时的稳定性。
URL、文件路径和模块路径为什么不能混用？
很多 Node 初学者会把“路径”当作一个统称，觉得字符串里长得像地址的东西都差不多。但实际上，在 Node.js 里，至少有三类概念需要明确分开：
- 文件路径；
- URL；
- 模块导入路径。
它们有交集，但不是一回事。
文件路径解决的是本地资源定位
文件路径描述的是本机文件系统里的位置。它关心的是目录结构、分隔符、绝对路径与相对路径，以及当前操作系统的路径规则。
URL 解决的是资源地址表达
URL 的职责则完全不同。它更关注协议、主机、路径片段和查询参数，适合表达网络资源地址，也适合在某些场景下作为统一资源标识。
在现代 Node.js 里，URL 也经常会和本地文件定位发生联系，比如某些 ESM 场景下会从 import.meta.url 出发再转换为文件路径。但这正说明它们不是同一个东西，而是需要被明确转换。
模块路径又是第三层语义
模块导入路径看起来也像路径，但它还额外受模块系统规则影响。比如：
- 是按包名导入还是按相对路径导入；
- 当前是
CommonJS还是ESM； - 包的
exports有没有限制可访问入口。
所以，你不能把模块路径、文件路径和 URL 都当成普通字符串随手混用。很多 Node 项目里的路径 bug，本质上就是这三层语义没有分清。
总结
这一篇我们先把 Node.js 和操作系统交互时最基础的四块能力串了起来：process 让你理解当前程序自己，path 让你正确地处理路径，fs 让你和文件系统打交道，而 url 则提醒你资源地址和本地路径不是同一个概念。
真正重要的不是把每个 API 都记下来，而是建立这样一个系统层心智：Node.js 程序并不是悬浮在空中的 JavaScript，它始终运行在一个真实的操作系统环境里，受到路径、进程、文件和外部输入的共同影响。
下一篇我们会继续往前走，把“数据到底以什么形式在 Node.js 中流动”这个问题讲清楚，进入 Buffer、编码、标准输入输出和命令行程序的基础世界。