Node.js path.format 字段优先级：已经把 ext 改成 md，为什么生成的文件名仍是 txt
工具先用path.parse拆开文件路径，把ext从.txt改成.md，再调用path.format拼回去，却发现扩展名完全没变。这不是对象展开没有写入新字段，而是拆解结果同时保存了完整文件名base和分开的name、ext。重新组装时，存在优先级更高的完整信息，低优先级字段修改就不会影响最终路径。
本文在Linux、Node.js v24.19.0中使用固定样本实跑。官方文档核验于2026年10月3日；在线文档显示的补丁版本可能不同于这里记录的实际解释器。程序不访问真实业务数据，也不连接远程服务。
AI模型生成的原创概念图：完整文件名与目录字段位于优先层，分解字段作为另一种组装入口；用于解释程序模型，不是软件截图、测试截图或实拍照片，精确行为以程序和实际输出为准。
完整程序与实际输出
将下面程序保存为tech14.mjs，执行node tech14.mjs。预期出现的异常已在例子里处理；退出码为零才表示本次演示正常完成。
import path from 'node:path';
import assert from 'node:assert/strict';
const p = path.posix;
const original = '/reports/draft.txt';
const parsed = p.parse(original);
const onlyExt = p.format({ ...parsed, ext: '.md' });
const { base, ...withoutBase } = parsed;
const fixed = p.format({ ...withoutBase, ext: '.md' });
console.log('ext_only=', onlyExt);
console.log('without_base=', fixed);
console.log('base_first=', p.format({ dir: '/reports', base: 'final.csv', name: 'draft', ext: '.txt' }));
console.log('dir_first=', p.format({ root: '/ignored', dir: '/reports', base: 'a.txt' }));
console.log('dot_added=', p.format({ dir: '/reports', name: 'a', ext: 'json' }));
console.log('windows=', path.win32.format({ dir: 'C:\\reports', name: 'a', ext: '.txt' }));
assert.equal(onlyExt, original);
assert.equal(fixed, '/reports/draft.md');本次实际标准输出：
ext_only= /reports/draft.txt without_base= /reports/draft.md base_first= /reports/final.csv dir_first= /reports/a.txt dot_added= /reports/a.json windows= C:\reports\a.txt
为什么只改ext没有效果
parse把/reports/draft.txt拆成多个部分，其中base是draft.txt，name是draft，ext是.txt。对象展开后再写ext，确实把ext字段改为.md；然而base仍然是draft.txt。第一行输出ext_only保留原路径，正好说明format选用了base，并没有根据修改时间判断哪个字段“更新”。
程序随后用解构取走base，将剩余属性放进withoutBase，再设置ext。第二行于是变为/reports/draft.md。这种写法保留原parsed对象，便于前后比较。若项目偏好直接修改，也可删除base后再组装，但应注意对象是否还被其他逻辑共享，避免为了改一次后缀破坏其他调用者期待的解析结果。
先确定完整形式还是分解形式
base_first示例同时给出final.csv、draft和.txt，结果选择final.csv。实际配置设计最好让调用者二选一：要么提供完整base，要么提供name加ext。若允许两种形式共存，就应明确记录优先级，并在不一致时给出提示，而不是让用户误以为每个字段都会参与拼接。
dir_first展示另一组优先级：提供/reports目录以后，root里写的/ignored不再决定结果。root不是自动加在dir之前的额外路径段。把解析对象看成“几块字符串全部相加”很容易出错，它更像包含完整路径部分与分解部分的结构化描述，format负责按规则选取适用组合。
平台规则要明确，不应随运行机器漂移
示例大部分调用明确使用path.posix，让斜杠规则不依赖当前操作系统。最后一行使用path.win32，即使在Linux运行，也能按照Windows风格生成反斜杠路径。这只是字符串处理，并没有访问C盘或创建任何目录。迁移脚本处理另一平台的路径时，显式选择对应实现可以减少隐藏假设。
dot_added一行验证本次Node.js版本在ext缺少开头点号时补上点号。官方文档记录这是较新版本的行为，旧环境不能只凭当前示例推断兼容性。为长期脚本保留显式点号通常更清楚，并在运行环境升级时验证同一批路径样本；文档的当前版本和实际部署版本要分别记录。
重组路径不等于安全地操作文件
format没有确认路径存在，也不会替你检查访问权限、目标文件内容或是否位于允许目录内。示例里的/reports只是虚构字符串，不需要读者真的建立该目录。如果下一步要写文件，仍需独立执行路径边界校验、冲突检查和必要授权，不能因为路径由官方库生成，就认定它自动符合业务安全规则。
回归样本建议包括普通文件、无扩展名、点开头名称、多段扩展名、根目录和显式Windows路径。验收时写清楚业务所说的“换扩展名”是改最后一段还是整个后缀组合；例如归档文件有多段后缀，技术上的ext未必等于业务定义的文件类型。先明确完整文件名策略，再组合字段，能让改名逻辑保持可解释。
验证记录与参考资料
本次完整程序退出码为0，标准错误为空。本例验证给定版本的路径字符串重组规则，没有访问真实文件；平台差异与文件访问安全需要单独检查。
