浏览器里跑着的文件 JavaScript，拿不到用户硬盘上文件的实际真实路径。这不是文件 bug，是实际设计。

我最早意识到这件事，文件是实际帮朋友做一个批量图片压缩的小工具。他想要的文件是：拖一堆图进去，压缩完直接覆盖原文件。实际听起来很合理对吧？文件但浏览器给的 File 对象里，file.path 永远是实际 undefined，file.fullPath 也是文件空。你能拿到的实际只有 file.name，比如 IMG_0231.jpg，文件至于它在 C:\Users\xxx\Pictures\ 还是实际 D:\备份\，浏览器一个字都不告诉你。文件

这事儿的根源在安全模型。想象一下，如果网页能读到 /Users/你的名字/Documents/工资表.xlsx 这种路径，那相当于把你的目录结构、用户名、甚至公司内网共享盘命名习惯全暴露了。更狠的是，恶意脚本可以靠路径拼接去猜其他文件的位置。所以从很早开始，浏览器就只给一个「伪路径」——C:\fakepath\IMG_0231.jpg。那个 fakepath 就是明摆着告诉你：别想了。

那有没有绕过去的路子？

有，但基本都出不了浏览器这个圈。

比如用 <input type="file" webkitdirectory> 让用户选一个文件夹。这时候 file.webkitRelativePath 会返回类似 myfolder/sub/img.jpg 的相对路径。注意，是相对于你选的那个文件夹，不是磁盘根目录。你依然不知道 myfolder 躺在哪个盘里。

再比如 Electron。这玩意儿把 Chromium 和 Node.js 捆在一起，Node 的 fs 模块能直接读 file.path。但代价是你得打包一个几百兆的桌面应用，而且用户得信任你安装它。网页？没门。

还有个偏方：用 FileReader 读文件内容，算个哈希，然后去本地数据库里比对。但这是「猜」路径，不是「获取」路径。文件稍微改一个字节，哈希就变了，你得重新猜。实际项目里没人这么干。

我踩过的一个坑

之前做一个内部用的 Markdown 编辑器，想实现「保存时自动更新同目录下的图片引用路径」。我天真地以为 showSaveFilePicker 能给我文件的真实位置。结果它只返回一个 FileSystemFileHandle，handle.name 还是只有文件名。你要读内容？可以。你要知道它在哪个文件夹？不行。除非用户主动再选一次那个文件夹，你才能通过 handle.getParent() 拿到父目录的 handle——但依然不是绝对路径，只是一个可以操作的目录句柄。

说白了，浏览器给你的是一把「钥匙」，而不是「地图」。你能开门，但不知道门牌号。

那实际开发里怎么办？

别跟这个限制硬刚。需要真实路径的场景，通常只有两种出路：要么走 Electron / Tauri 这类桌面壳，要么让用户手动输入或粘贴路径。后者听起来很蠢，但很多专业工具就是这么干的——比如某些批量重命名软件，会让你先选一个「工作目录」，然后所有操作都基于这个目录的相对路径来做。

还有一个思路：用 File System Access API 的 showDirectoryPicker() 让用户授权一个目录，然后你在这个目录里遍历、读写。路径？你不需要知道。你只需要知道「在这个目录下面有个 output/ 文件夹」，然后往里写就行了。这其实更符合 Web 的思维方式——操作句柄，而不是操作路径字符串。

我现在的习惯是：只要产品需求里出现「获取文件真实路径」这七个字，先问一句——你是要做桌面应用，还是网页？如果是网页，直接砍掉这个需求，换成「让用户选择输出目录」或者「打包成 zip 下载」。省下来的时间够你喝三杯咖啡。

浏览器不是操作系统。它给你的抽象层，有时候确实碍事，但更多时候是在帮你挡掉一堆你根本不想处理的烂摊子。