你观察到的这个行为确实和直觉有点不一样，但它不是Bug，而是Node.js path模块为了贴合文件系统规范、保障生态稳定而特意设计的。先再明确下你提到的实际和预期行为：

实际行为 #

• path.basename("/var/") === "var"
• path.parse("/var/") 返回 {root: "/", dir: "/", base: "var", name: "var", ext: ""}

你的预期 #

• path.basename("/var/") === ""
• path.parse("/var/") 返回 {root: "/", dir: "/var/", base: "", name: "", ext: ""}

下面来说说这个设计背后的几个核心原因：

• 对齐POSIX文件系统规范
  在类Unix系统遵循的POSIX标准里，路径末尾的斜杠是被忽略的——/var/和/var指向的是同一个目录。Node.js的path模块（默认在类Unix系统使用path.posix实现）严格遵循这个规范，自动忽略末尾的路径分隔符，把带末尾斜杠的路径当作不带斜杠的版本处理，确保和系统底层API的行为一致。

• 避免空路径段的混乱
  如果把末尾斜杠后的空字符串视为合法的basename，会引发很多不必要的问题：比如遍历目录时会出现空的路径条目，很多文件系统操作（像fs.readdir）本身也不会返回空文件名的结果。保持basename为最后一个非空的路径段，能让路径处理逻辑更简洁，减少边缘场景下的错误。

• 保障向后兼容性与生态稳定
  你说得非常对——如果修改这个行为，会导致大量依赖path模块的Node.js库直接崩溃。这个行为从Node.js的早期版本就存在，整个Node.js生态已经基于这个逻辑构建了无数工具、框架和模块。为了不破坏现有代码的正常运行，这个设计一直被保留下来。

• 贴合真实文件系统的操作逻辑
  在实际使用中，你输入cd /var/和cd /var的效果完全一致，系统不会把末尾的斜杠当作一个独立的“空元素”。Node.js的path模块就是为了映射这种真实的文件系统行为，让开发者的代码和日常的系统操作逻辑保持统一。

如果你确实需要区分带末尾斜杠和不带斜杠的路径，比如要获取你预期的空basename，可以自己做个简单的封装：

const path = require('path');

function getCustomBasename(pathStr) {
  const sep = path.sep;
  // 排除根路径"/"的特殊情况
  if (pathStr !== sep && pathStr.endsWith(sep)) {
    return '';
  }
  return path.basename(pathStr);
}

内容的提问来源于stack exchange，提问作者ConsciousCode