写路径处理代码这些年，我踩过的最大坑几乎都和字符串拼接有关。明明用 Node.js 写得好好的服务，换一台服务器、换个启动目录，路径就全乱了。后来把path.resolve彻底用透，才真正理解什么叫“高效路径处理”。这篇文章不聊虚的，直接从path.resolve的原理、典型场景、完整实操到故障排查，一次性讲清楚。无论你是刚接触 Node.js 的初学者，还是已经写了好几年服务端代码的老手，这些内容都能直接用得上。
1. path.resolve 到底是什么，为什么路径问题这么烦人
1.1 路径处理的三大历史包袱
做 Web 开发或者写 Node.js 脚本时，路径几乎是绕不开的一环。但路径问题之所以烦人，是因为它有历史包袱。先说第一点：不同操作系统的路径分隔符不一样。Windows 用的是反斜杠\，Linux 和 macOS 用的是正斜杠/。如果你在代码里写'dir/sub/file.txt'，在 Windows 上虽然很多 API 也能识别，但一旦涉及到与某些原生工具交互、写配置文件、或者把路径作为参数传给其他程序，反斜杠和正斜杠混用就会出幺蛾子。
第二点，相对路径的“参照点”不稳定。你在哪个目录下运行node app.js，决定了process.cwd()是什么。而你的模块文件在哪，又是另一个概念。很多新手会把这两个搞混，导致同样的代码，在项目根目录跑没问题，换到src目录跑就报找不到文件。
第三点，路径里可能包含.和..这种层级符号。.env、./src/index.js、../config，手动展开这些不是不行，但很容易出错。处理这些符号需要一套稳定的规则，而path.resolve就是 Node.js 提供的标准化方案。
一句话理解：path.resolve就是把传入的路径片段按规则解析成一个绝对路径，同时自动处理分隔符、.和..，消除操作系统差异。这是它与其它路径 API 最本质的区别。
1.2 从右到左的解析规则
path.resolve核心规则并不复杂，但很多人第一眼看到会懵。先看一个官方例子：
// 假设当前工作目录是 /home/user/project const path = require('path'); path.resolve('/foo/bar', './baz'); // 返回: '/foo/bar/baz' path.resolve('/foo/bar', '/tmp/file/'); // 返回: '/tmp/file' path.resolve('wwwroot', 'static_files/png/', '../gif/image.gif'); // 如果当前目录是 /home/user/project // 返回: '/home/user/project/wwwroot/static_files/gif/image.gif'看起来是不是有点反直觉？核心规则是：从右往左逐段处理，每遇到一个路径片段，就拼到当前路径后面；一旦遇到一个绝对路径，就直接用它作为新的起点，忽略它左边的所有片段。
用第一个例子解释：从右往左，先拿./baz拼，再拿/foo/bar拼，因为/foo/bar是绝对路径，所以前面的（其实没有了）全部作废，最终返回/foo/bar/baz。
第二个例子更容易理解：从右往左，先是/tmp/file/，它是绝对路径，直接确定为结果，左边/foo/bar被丢弃。
第三个例子是真正体现“解析”的场景：依次处理/home/user/project→ 拼接wwwroot→ 拼接static_files/png→ 拼../gif/image.gif，其中../会把png这一层抵消掉，于是最终落到static_files/gif/image.gif。
有一个判断技巧：只要从右往左发现了第一个绝对路径参数，解析就立刻结束。如果没有绝对路径参数，就自动用process.cwd()作为最左侧的默认起点。
1.3 和几个兄弟方法的区别
要真正用好path.resolve，一定得区分它和path.join、path.normalize、path.dirname、path.relative的定位。
| 方法 | 返回值 | 核心作用 | 是否强制绝对路径 |
|---|---|---|---|
path.join(...args) | 规范化后的路径（不一定是绝对路径） | 把多个片段拼接成一个完整路径，处理分隔符和..、. | 否 |
path.resolve(...args) | 绝对路径 | 从右往左解析，以首个绝对路径或cwd为锚点 | 是 |
path.normalize(p) | 规范化后的路径 | 清理路径中的冗余层级和错误分隔符 | 否 |
path.dirname(p) | 路径的目录部分 | 返回路径中最后一级的上层路径 | 否 |
path.relative(from, to) | 相对路径 | 计算从from到to的相对关系 | 否 |
最容易混淆的就是path.join和path.resolve：
path.join('/foo', 'bar'); // '/foo/bar' path.resolve('/foo', 'bar'); // '/foo/bar' path.join('foo', 'bar'); // 'foo/bar'（相对路径） path.resolve('foo', 'bar'); // '/home/user/project/foo/bar'（绝对路径，自动补 cwd） path.join('/foo', '/bar'); // '/foo/bar'（简单拼接） path.resolve('/foo', '/bar'); // '/bar'（因为 /bar 是绝对路径，左侧被丢弃）一句话总结应用场景：如果你要拼出一个绝对路径，用resolve；如果只是把几个片段合法地拼接在一起，不关心是否是绝对路径，用join。绝大多数“高效路径处理”需求，目标都是得到一个稳定可靠的绝对路径，所以path.resolve才是主角。
2. 真正用得上的五个场景，直接照抄
2.1 基于__dirname拼接模板或静态资源
CommonJS 环境下每个模块都有__dirname，它表示当前这个文件所在的目录，是绝对路径。用它作为起点来定位同目录下的资源，永远安全：
const path = require('path'); // 假设文件位于 /app/src/utils/filePath.js const dataRoot = path.resolve(__dirname, '../../data'); const templatePath = path.resolve(__dirname, '../views/index.html'); const uploadDir = path.resolve(__dirname, '../../uploads');这里的关键在于，__dirname不会随启动目录变化而变化。不管你在哪个目录运行node src/index.js，这个表达式都能稳定定位到正确位置。我见过很多项目在入口文件里写const basePath = './uploads'，结果一旦使用pm2或systemd以不同工作目录启动，上传文件就找不到了。换成path.resolve(__dirname, ...)之后，这种问题再也没有出现过。
2.2 动态定位配置文件与环境变量
实际项目中，配置文件的存放位置五花八门。有的放在项目根目录.config/，有的放在src/config/，还有的需要从外部传入。用path.resolve可以很好地统一处理：
const path = require('path'); function resolveConfig(relativePath) { // 先尝试从当前工作目录找，再回退到项目 src/config 目录 const fromCwd = path.resolve(process.cwd(), relativePath); const fromSrc = path.resolve(__dirname, '../config', relativePath); const fs = require('fs'); if (fs.existsSync(fromCwd)) return fromCwd; return fromSrc; } const configFile = resolveConfig('app.yaml'); console.log('加载配置文件:', configFile);这里体现了process.cwd()和__dirname的搭配：运行时优先看当前工作目录，找不到再回归到模块所在目录。这种设计适用于那些既支持全局使用、又支持项目内嵌套使用的命令行工具。
2.3process.cwd()与__dirname的经典误区
太多人在这上面栽过跟头。直接看对比：
// 项目结构： // /app/ // index.js // lib/util.js // 在 /app 目录下运行：node index.js console.log(process.cwd()); // '/app' console.log(__dirname); // '/app' // 在 /app/lib 目录下运行：node lib/index.js // 或：node ./lib/index.js console.log(process.cwd()); // '/app'（取决于你从哪里启动） console.log(__dirname); // '/app/lib'process.cwd()是启动进程时的当前工作目录，它只取决于你在终端里敲命令的位置。__dirname是当前模块所在的目录，它是一个编译期常量，只和文件位置有关。如果代码中用process.cwd()去定位与模块同级的文件，一旦更换启动目录，路径立即失效。而path.resolve(__dirname + ...)则完全不受启动位置影响。
可以按照这个经验来决策：处理用户传入的文件路径、临时文件、或者需要暴露给用户的绝对路径时，用process.cwd()作为基准；处理模块自身依赖的资源文件时，用__dirname作为基准，再交给path.resolve。
2.4 模拟多层相对路径的解析顺序
有时候路径片段很多，手算容易出错。我的习惯是先在草稿里手动走一遍path.resolve的解析流程，再结合代码验证。比如：
const p = path.resolve( '/data', 'app', '../logs', './error', '../../backup', 'final.log' );手动模拟过程：
- 先确定隐含的
cwd，但由于/data是绝对路径，实际用/data作为起始。 - 从左到右实际处理顺序是：
/data→ 拼接app得/data/app→ 拼接../logs会把app抵消，得到/data/logs→ 拼接./error得到/data/logs/error→ 拼接../../backup会把logs/error两级抵消，得到/data/backup→ 拼接final.log，最终得到/data/backup/final.log。
用代码验证会发现结果和手算一致。这种“手动模拟 + 代码验证”的习惯非常有用，尤其是当你的路径配置来自多个常量组合时，能提前发现多余的..或者错误层级。
2.5 在模块化项目中统一路径入口
项目一复杂，到处散落的相对路径会让人崩溃。比较稳妥的做法是建立一个paths.js，集中导出所有关键路径，避免在业务代码里到处写魔数一样的相对路径。后面我会在实操部分给出完整代码示例。
3. 实操示例：从零搭建一个整洁的路径处理层
3.1 环境准备与 Node.js 版本说明
path模块是 Node.js 的核心模块，不需要额外安装依赖，只要你的程序能跑，就一定能用。但我还是要结合最近大家下载安装 Node.js 时的一些热搜词提个醒：如果你用的是老版本，比如 Node.js 16 之前的，那语法上基本没问题；但如果你想用 ESM 生态里那些新特性，比如import.meta.url、path.resolve配合URL转换，建议至少使用 Node.js 18 或 LTS 版本，比如 Node.js 18.20.4 或者更新的 22.x LTS。
推荐的做法是安装官方 LTS 版本，因为 LTS 版本的模块路径解析行为和语法稳定，避免生产环境出现莫名其妙的兼容问题。在 CentOS 7.9 或类似服务器上部署 Node.js 应用时，记得用 root 权限或具有目录写权限的用户操作，把node和npm加入PATH，之后所有脚本都能直接调用。以下示例不依赖任何第三方模块，所以在任何 Node.js 14+ 版本里都能跑，但后面的 ESM 部分我会标注版本要求。
3.2 创建paths.js统一出口
假设项目结构如下：
my-app/ ├── src/ │ ├── index.js │ ├── paths.js │ └── modules/ │ └── upload.js ├── public/ │ ├── css/ │ └── images/ ├── data/ │ ├── uploads/ │ └── logs/ └── package.json在src/paths.js中，我用path.resolve将所有关键目录汇总：
// src/paths.js const path = require('path'); const fs = require('fs'); // 此文件位于 src/paths.js const srcDir = __dirname; // /app/src const projectRoot = path.resolve(srcDir, '..'); // /app const publicDir = path.resolve(projectRoot, 'public'); const cssDir = path.resolve(publicDir, 'css'); const imageDir = path.resolve(publicDir, 'images'); const dataDir = path.resolve(projectRoot, 'data'); const uploadDir = path.resolve(dataDir, 'uploads'); const logDir = path.resolve(dataDir, 'logs'); function ensureDirSync(dir) { fs.mkdirSync(dir, { recursive: true }); } // 初始化目录 ensureDirSync(uploadDir); ensureDirSync(logDir); module.exports = { srcDir, projectRoot, publicDir, cssDir, imageDir, dataDir, uploadDir, logDir, ensureDirSync };这里有几个细节值得说明。第一，ensureDirSync使用了fs.mkdirSync(dir, { recursive: true })，配合path.resolve得到的绝对路径，可以确保在上传文件前目录一定存在。第二，所有导出路径都是绝对路径，业务模块引入时不需要再自己算一层相对关系。第三，集中管理后，如果目录结构调整，只需要改paths.js，业务代码完全不用动。
3.3 在业务模块中使用：静态文件和上传下载
看看实际怎么用。先写一个静态资源服务：
// src/index.js const http = require('http'); const fs = require('fs'); const path = require('path'); const { publicDir, uploadDir, projectRoot } = require('./paths'); const mimeMap = { '.html': 'text/html; charset=utf-8', '.css': 'text/css; charset=utf-8', '.js': 'application/javascript', '.png': 'image/png', '.jpg': 'image/jpeg', '.gif': 'image/gif', }; function safeResolve(baseDir, relativePath) { const absolutePath = path.resolve(baseDir, relativePath); // 关键安全校验：防止用户通过 ../ 跳出目标目录 if (!absolutePath.startsWith(path.resolve(baseDir))) { return null; } return absolutePath; } const server = http.createServer((req, res) => { const urlPath = decodeURIComponent(req.url.split('?')[0]); if (urlPath === '/') { const indexPath = path.resolve(publicDir, 'index.html'); fs.readFile(indexPath, (err, data) => { if (err) { res.writeHead(404); return res.end('Not Found'); } res.writeHead(200, { 'Content-Type': 'text/html; charset=utf-8' }); res.end(data); }); return; } if (urlPath.startsWith('/uploads/')) { const relativeFile = urlPath.replace(/^\/uploads\//, ''); const filePath = safeResolve(uploadDir, relativeFile); if (!filePath) { res.writeHead(403); return res.end('Forbidden'); } fs.readFile(filePath, (err, data) => { if (err) { res.writeHead(404); return res.end('Not Found'); } res.writeHead(200); res.end(data); }); return; } // 其他静态文件 const filePath = safeResolve(publicDir, urlPath); if (!filePath || !fs.existsSync(filePath)) { res.writeHead(404); return res.end('Not Found'); } const ext = path.extname(filePath); res.writeHead(200, { 'Content-Type': mimeMap[ext] || 'application/octet-stream' }); fs.createReadStream(filePath).pipe(res); }); server.listen(3000, () => { console.log('服务已启动，项目根目录：', projectRoot); console.log('静态目录：', publicDir); console.log('上传目录：', uploadDir); });这个示例中最有价值的不是静态服务本身，而是safeResolve函数。用户传入的urlPath可能是../../etc/passwd这种恶意路径。如果直接fs.readFile(path.resolve(uploadDir, relativeFile))，攻击者就能读取上传目录之外的敏感文件。通过path.resolve拿到绝对路径后，用startsWith校验前缀，确保最终路径一定在目标目录内，这是生产环境必须做的安全兜底。
3.4 用path.resolve处理上传文件的保存名
实际项目中还有一个细节：保存上传文件时，文件名不能直接用用户提供的名字，否则会引入../等危险字符，或者覆盖关键文件。一个稳妥的做法是生成随机文件名，再用path.resolve拼出完整路径：
// src/modules/upload.js const path = require('path'); const crypto = require('crypto'); const { uploadDir, ensureDirSync } = require('../paths'); function generateSaveName(originalName) { const ext = path.extname(originalName); // 保留扩展名 const base = crypto.randomBytes(16).toString('hex'); return `${base}${ext}`; } function resolveUploadPath(fileName) { ensureDirSync(uploadDir); return path.resolve(uploadDir, fileName); // fileName 是我们自己生成的，安全 } module.exports = { generateSaveName, resolveUploadPath, };这里使用crypto.randomBytes(16).toString('hex')生成 32 位十六进制随机字符串，避免文件名冲突。同时因为文件名是合法字符串，不存在../，可以放心交给path.resolve处理。如果业务上需要保留用户原始文件名，也应该先做白名单校验，过滤掉所有非字母数字和连字符、下划线、点以外的字符，再做路径拼接。
4. 常见问题与排查技巧，全是我踩过的坑
4.1path.resolve和path.join混用造成的绝对路径丢失
最典型的错误是：
const base = path.resolve(__dirname, '../public'); const file = path.join(base, '../secret.txt');这段代码的结果是/app/public/../secret.txt，它依然是 absolute，但语义上已经不再是base下，而是跑到了public的上级。如果你本来想限制在public目录内，这就是一个安全漏洞。正确做法是统一用path.resolve做最终的规整和校验：
const base = path.resolve(__dirname, '../public'); const file = path.resolve(base, '../secret.txt'); // 同样会向上跳出，需要校验 if (!file.startsWith(base + path.sep)) { throw new Error('非法路径'); }混用不是不行，而是心里要清楚：join只负责拼接，resolve负责最终解析。特别是涉及用户输入的动态路径时，最终落地的路径必须经过一次path.resolve和前缀校验，不要跳步骤。
4.2 启动方式不同导致process.cwd()不一致
假设你用 systemd 管理服务，WorkingDirectory设置错了，或者你在Cron里调用 Node 脚本时没有切目录，那么process.cwd()就可能变成/或者$HOME。这时候如果你依赖cwd去拼接相对路径，就会得到完全错误的结果。
排查技巧很简单：在程序最开头打印一行诊断信息：
console.log('cwd:', process.cwd()); console.log('__dirname:', __dirname); console.log('入口文件:', process.argv[1]);通过对比这三个值，立刻能看出路径错乱的根源。用path.resolve(process.cwd(), 'data')和path.resolve(__dirname, '../data')的结果可能完全不同。我的经验是：模块内部资源一律用__dirname基准；只有用户显式传入的路径才用cwd基准。
4.3 Windows 下的盘符与UNC路径
在 Windows 上，path.resolve('C:\\foo', 'bar')会得到C:\foo\bar。但这里有个容易踩的坑：如果传入的路径以/开头，Node 在 Windows 上会解析为当前盘的根目录，比如path.resolve('C:\\projects\\app', '/data')会得到C:\\data，而不是/data。这在跨平台代码里非常坑。
更少见的是 UNC 路径，例如\\server\share\folder，path.resolve对它的处理与本地盘符略有差异。好在 Web 应用通常跑在 Linux 服务器上，如果你必须在 Windows 开发机上保证和生产一致，建议在代码中始终使用path.resolve，并避免在参数里混用/开头或盘符开头的绝对路径，让相对路径片段成为主导，这样跨平台结果会更稳定。
下面这张表是跨平台时可能会遇到的现象：
| 代码 | Linux 上结果 | Windows 上结果（可能） | 说明 |
|---|---|---|---|
path.resolve('/data', 'x') | /data/x | C:\data\x | /会被解析为当前盘根目录 |
path.resolve('C:\\data', '../x') | /project/C:\data/../x（乱） | C:\x | 尽量避免在非 Windows 上使用盘符风格 |
path.resolve('dir', '/x') | /x | C:\x | 绝对路径片段会丢弃左侧 |
path.resolve('dir', 'sub') | /cwd/dir/sub | C:\cwd\dir\sub | 相对路径最终以绝对路径输出 |
跨平台兼容的核心不是靠resolve一劳永逸，而是项目里约定统一用相对路径片段描述目录层级，避免在参数中混入盘符或绝对路径根标记。
4.4 动态拼接路径时忘了安全校验
不少漏洞都出在“用户可控的内容被直接拼进文件路径”。比如：
const file = path.resolve(uploadDir, req.params.fileName); // 危险用户传req.params.fileName = '../../../../etc/passwd时，path.resolve会规整出一个完全合法的绝对路径，指向系统文件。所以前面示例中才写了safeResolve函数。这里的本质是：path.resolve负责的是把路径解析干净，它不负责判断“干净之后是否合法”。安全性要由业务代码自己控制。
推荐的做法是：
- 先解析出最终绝对路径；
- 再判断这个绝对路径是否以
允许的根目录 + path.sep开头； - 不满足则直接拒绝。
也可以用path.relative(allowRoot, finalPath)的返回值来判断，如果返回结果以..开头或本身是绝对路径，说明越界了。两种方式都可以，我更推荐startsWith方案，语义简单，测试也容易写。
4.5 分隔符混用和..没有正常抵消
path.resolve会自动把反斜杠和正斜杠统一处理。但有一个场景要小心：如果你收到一个来自外部接口的路径字符串，它里面既有\又有/，比如'..\\data//file.txt'，直接传进path.resolve完全没有问题，它会按操作系统规则统一。真正的问题是你不解析它，而是直接拼接字符串。
举一个典型反面案例：
// 错误做法 const badPath = `${__dirname}/../data/${fileName}`; // 正确做法 const goodPath = path.resolve(__dirname, '../data', fileName);直接拼接的代码在 Windows 上可能得到C:\app\../data/file，在 Linux 上解析逻辑又不一样，而且一旦fileName里有..或特殊空格，各种隐藏 bug 都会冒出来。规范的做法永远是让path.resolve来兜底。
5. 性能与编码习惯：高效不只是“跑得快”
5.1path.resolve真的有性能开销吗？
很多人一听到“高效”就以为要追求极致性能。其实path.resolve是纯字符串处理函数，没有 I/O 操作，性能开销极其微小。在普通机器上一次调用大约是微秒级别，写一万次也才几毫秒。所以完全不用为了几微秒去手写字符串拼接，那样反而更容易出错。
不过有一种做法值得优化：如果你在热路径（比如每个 HTTP 请求处理函数里）反复调用path.resolve(__dirname, '../public')，并且参数完全不变，那么可以将解析结果提升为模块级常量，避免重复计算。毕竟虽然开销微小，重复几万次也会积累成可见的 CPU 时间。但也有一个例外：如果动态传入的用户路径，那就无法缓存，只能每次解析。
5.2 用常量与工厂函数管理路径
我在大型项目里总结出了一个模式：模块级常量 + 工厂函数。
- 不变的基础路径，比如
projectRoot、uploadDir，在模块加载时就计算好、导出去。 - 动态路径，比如根据用户名生成个人目录，则写一个函数：
function getUserDir(userId) { return path.resolve(uploadDir, 'users', String(userId)); }这样既保证了常量的性能，又提供了动态生成的灵活性。切不要让每个模块都自己去“猜”路径，所有路径来源统一从paths.js获取，后续维护时你会感谢自己。
5.3 和fs.realpath搭配，处理符号链接
path.resolve处理的是逻辑路径，但它不会解析软链接或符号链接。比如/app/data可能是一个指向/mnt/data的符号链接，path.resolve('/app/data', 'x')只会得到/app/data/x，而不是/mnt/data/x。
如果确实需要拿到真实路径，尤其是在权限校验场景下，可以用fs.realpathSync：
const fs = require('fs'); const path = require('path'); const logicalPath = path.resolve(process.cwd(), 'data'); let realPath = logicalPath; try { realPath = fs.realpathSync(logicalPath); } catch (e) { // 目录不存在时 realpathSync 会抛错，按需处理 }这里有个先后顺序：先让path.resolve保证参数是合法绝对路径，再让fs.realpath去查真实物理路径。如果直接拿相对路径去realpath，又会出现和cwd绑定导致的不稳定问题。
5.4 ESM 模式下用import.meta.url替代__dirname
到了 Node.js 官方 ESM 时代，没有__dirname了。但别慌，path.resolve依然可用，只是获取“当前文件目录”的方式变了。标准解法是利用fileURLToPath：
import { fileURLToPath } from 'url'; import path from 'node:path'; const __filename = fileURLToPath(import.meta.url); const __dirname = path.dirname(__filename); const configPath = path.resolve(__dirname, '../config'); console.log(configPath);如果你用的是path.resolve配合 URL 对象，也可以这么写：
import { pathToFileURL } from 'url'; // 把绝对路径转成 file:// URL const urlPath = pathToFileURL(path.resolve(__dirname, '../logo.png'));但大多数场景下，直接用fileURLToPath转换后得到的路径字符串传给path.resolve最省事。这里建议固定用node:前缀引入核心模块，比如import path from 'node:path'，既语义清晰，也避免和第三方库重名混淆。
6. 最后再分享几个实用小技巧
6.1 使用path.parse和path.format拆解路径
如果你的需求不只是拼接，还要分析路径的各个部分，path.resolve通常要配合path.parse使用：
const path = require('path'); const fullPath = path.resolve(__dirname, 'public', 'images', 'logo.png'); const parts = path.parse(fullPath); console.log(parts.root); // '/' console.log(parts.dir); // '/app/public/images' console.log(parts.base); // 'logo.png' console.log(parts.ext); // '.png' console.log(parts.name); // 'logo'path.resolve负责产出完整的绝对路径，parse负责拆解，format负责把各部分重新拼回路径。这个组合在做日志分析、扩展名处理、目录结构遍历时非常高效。
6.2 用path.relative计算两个目录间的相对指引
有时候你拿到了两个绝对路径，想得到从 A 到 B 的相对路径，比如生成下载链接或者展示给用户的友好路径：
const fromDir = path.resolve(__dirname, '../data'); const toDir = path.resolve(__dirname, '../../shared/assets'); const rel = path.relative(fromDir, toDir); console.log(rel); // '../shared/assets'这种场景虽然主要是path.relative的事，但参数最好都先经过path.resolve处理，避免相对路径之间的相对关系含糊不清。
6.3 路径常量集中命名建议
最后说一点命名习惯。我建议路径常量使用统一后缀Dir或Path，比如uploadDir、logDir、configPath，不要交叉混用。让代码阅读者一眼看出这是一个目录还是一个具体文件。同时尽量不在业务代码里直接写path.resolve的复杂片段，而是收拢到paths.js或专门的path-utils里。这样后续要迁移目录结构、做权限控制或者统一处理 Windows 兼容时，改动范围可以限制在一个文件内。
我实际维护过的一个老项目，早期所有模块都各自处理路径，结果项目从 Linux 部署迁移到 Windows 开发机时，几十处正则替换差点崩溃。后来花了一个下午把所有路径逻辑统一收敛到paths.js之后，改动只用了十分钟。这就是用path.resolve做路径处理最大的价值：它不是让你多写几行代码，而是帮你把最容易出错的逻辑集中起来，交给一套标准化的规则去管理。所以从现在开始，只要遇到路径拼接，先想想能不能交给path.resolve，自己只保留业务语义和安全校验，剩下的脏活累活都交给它。
