file.isdictionary 不是合法 api，javascript 的 file 接口不提供路径判断能力，调用会报 typeerror；node.js 应用 fs.stat() 判断目录，浏览器需用 showdirectorypicker() + entry.kind。
File.isDictionary 不是标准 JavaScript、Node.js 或主流平台（如 Deno、Bun）中的合法 API，它根本不存在。
为什么 File.isDictionary 会报错或返回 undefined
这个写法常见于对 API 的误记或混淆。JavaScript 中的 File 接口（来自 File API，用于浏览器端文件上传场景）只提供 name、size、type、lastModified 等属性，**不包含任何路径判断能力**，更没有 isDictionary 这个方法 —— 它既不是规范定义的，也不是任何运行时实现的。
- 在浏览器中调用
file.isDictionary会直接报TypeError: file.isDictionary is not a function - 在 Node.js 中，
File类型甚至默认不可用（需手动引入globalThis.File才能模拟，但仍无该方法） - 有人可能把它和 Swift 的
FileManager.isDictionary(_:)或旧版 Objective-C 的isDirectory混淆了
真正能判断目录的替代方案（Node.js）
Node.js 中判断路径是否为有效目录，应使用 fs.stat() 或其 promise 版 fs.promises.stat()，检查返回对象的 isDirectory() 方法：
import { stat } from 'fs/promises';
try {
const stats = await stat('/path/to/test');
if (stats.isDirectory()) {
console.log('这是一个目录');
}
} catch (err) {
if (err.code === 'ENOENT') {
console.log('路径不存在');
} else {
console.log('其他错误：', err.code);
}
}
- 不要用
fs.exists()或fs.existsSync()—— 它们无法区分文件和目录，且已弃用 - 避免仅靠路径末尾是否有
/判断 ——/tmp和/tmp/在语义上等价，但路径字符串本身不反映真实类型 -
stat()是唯一可靠方式：它读取文件系统元数据，返回包含isDirectory()、isFile()等方法的对象
浏览器中无法判断目录的底层限制
浏览器环境出于安全沙箱限制，**不允许 JavaScript 主动探测任意本地路径的类型或存在性**。即使用户通过 <input type="file" webkitdirectory> 选择了目录，你拿到的也是一组 File 对象（每个代表一个文件），而不是一个可遍历的目录句柄 —— 除非使用 showDirectoryPicker()（需要 HTTPS + 用户显式授权）：
try {
const dir = await showDirectoryPicker();
// dir 是 FileSystemDirectoryHandle，可 enumerate()
for await (const entry of dir.values()) {
console.log(entry.name, entry.kind); // "kind" 可能是 'file' 或 'directory'
}
} catch (err) {
console.error('用户拒绝或不支持', err);
}
-
showDirectoryPicker()返回的是FileSystemDirectoryHandle，不是File，也没有isDictionary -
entry.kind === 'directory'是判断子项是否为目录的正确方式，不是靠名字或后缀 - 该 API 尚未在所有浏览器中默认启用（如 Safari 仍不支持）
真正的目录判断永远依赖运行时提供的具体能力：Node.js 靠 fs.stat，现代浏览器靠 showDirectoryPicker + entry.kind。把 File.isDictionary 当真，大概率是因为查文档时点错了链接，或者把不同语言的 API 记串了。
