拖文件进 Electron 窗口，鸿蒙 PC 上 file.path 是个幽灵：看着有值，fs 一读就 ENOENT

上周我把雷达鸭桌面端的图片拖拽预览重写了一遍。Windows 上跑得好好的发到鸿蒙 PC 测试机上一拖直接炸。报错就一行ENOENT: no such file or directory, open 。我当时盯着 console 看了十分钟一度以为是打包时漏了asar解压配置又去翻extraResources折腾半天发现根儿上就不是那回事。你猜怎么着path 打印出来是空字符串。先上那段让我栽跟头的代码// renderer.js —— Windows/macOS 上能跑鸿蒙 PC 上直接 ENOENTconstdropZonedocument.getElementById(drop)dropZone.addEventListener(drop,(e){e.preventDefault()constfilee.dataTransfer.files[0]// Windows 上 file.path 是 C:\\Users\\me\\a.png// 鸿蒙 PC 上 file.path 是 空字符串或者干脆 undefinedwindow.electronAPI.readImage(file.path)})主进程那边老老实实按路径去读// main.js —— 收到路径去读文件constfsrequire(fs)constpathrequire(path)ipcMain.handle(read-image,(_e,p){constbuffs.readFileSync(p)// 鸿蒙 PC 上 p → Error: ENOENTreturn{size:buf.length,ext:path.extname(p)}})问题就出在file.path上。Chromium 的沙箱策略下拖进来的File对象里path字段本来就不是所有平台都填。Windows 和 macOS 的 Electron historically 会把这个字段填上真实路径所以你一直用、fs一直读从来没出过事自然也就没人会去怀疑它。鸿蒙 PC 这版 electron-mus 守得更死path直接给你留空。于是readFileSync()原地升天。我承认我一开始写得很蠢——第一反应居然是去查是不是contextIsolation把File给 strip 了白白浪费半小时。后来干脆把整个File对象console.log出来看才发现name、size、type都在path那一项就是个空串。这其实是个很明确的信号系统压根没打算告诉你文件在磁盘上的位置。第一个坑webUtils.getPathForFile 也不是万能药网上搜出来的标准答案基本都是这个// renderer.js —— 用 webUtils 拿真实路径const{webUtils}require(electron)dropZone.addEventListener(drop,(e){e.preventDefault()constfilee.dataTransfer.files[0]constrealPathwebUtils.getPathForFile(file)// 比 file.path 靠谱window.electronAPI.readImage(realPath)})webUtils.getPathForFile确实是官方给的、专门为这种沙箱里拿不到路径场景准备的 APIElectron 20 就有。它确实能吐出比file.path更像样一点的路径。但我得泼盆冷水在鸿蒙 PC 上它返回的路径往往指向一个沙箱挂载点类似/mnt/sandbox/...或者 content 样式的 URI主进程的fs照样读不到。等于你以为拿到了钥匙结果是把打不开那扇门的钥匙。说白了就是换了个姿势继续 ENOENT。真正稳的冷门写法根本不要路径等一下这里我漏说一个前提——绝大多数人包括一周前的我潜意识里觉得读文件总得有个路径吧。其实根本不需要。File对象本身就是字节的载体你直接在渲染进程把字节读出来跨进程传给主进程全程不碰path沙箱跟你半毛钱关系没有// renderer.js —— 不要路径直接在渲染进程读字节dropZone.addEventListener(drop,async(e){e.preventDefault()constfilee.dataTransfer.files[0]// arrayBuffer 在任何平台都能拿到真实内容不依赖 file.pathconstabawaitfile.arrayBuffer()constmetaawaitwindow.electronAPI.handleDropped(ab,file.name,file.type)renderPreview(meta)})主进程收到的是ArrayBuffer包成Buffer直接用// main.js —— 拿到 ArrayBuffer包成 Buffer 处理constcryptorequire(crypto)ipcMain.handle(handle-dropped,async(_e,ab,name,type){constbufBuffer.from(ab)// 跨进程传过来的是 ArrayBufferconsthashcrypto.createHash(sha256).update(buf).digest(hex).slice(0,12)return{name,type,size:buf.length,hash,preview:buf.slice(0,64)}})如果你开了contextIsolation现在基本都开渲染进程里不能直接require(electron)用 preload 把能力暴露出去就行// preload.jsconst{contextBridge,ipcRenderer,webUtils}require(electron)contextBridge.exposeInMainWorld(electronAPI,{handleDropped:(ab,name,type)ipcRenderer.invoke(handle-dropped,ab,name,type),getRealPath:(file)webUtils.getPathForFile(file)})这里有个细节不少人会懵跨进程传过去的ArrayBuffer还是ArrayBuffer吗是的。Electron 的 IPC 走的是结构化克隆ArrayBuffer 能原样传过去不需要你手动base64序列化。我之前还傻乎乎地转成 base64 字符串再发白白多烧一倍内存还多做一遍编解码纯属脱裤子放屁。我实测下来arrayBuffer()这写法在三端Windows / macOS / 鸿蒙 PC行为完全一致因为读字节走的是File接口本身跟操作系统给不给你路径毫无关系。说实话我当初嫌它啰嗦——毕竟fs.readFileSync(file.path)一行就完事了——但架不住它稳。如果让我重来新项目里我一律不在渲染进程要路径。顺带一句如果拖进来的是几百 MB 的视频一次性arrayBuffer()会占双倍内存File 自己一份、读出来的 ArrayBuffer 又一份。那种场景我一般在渲染进程用slice分块读、带个进度条不过那是另一个话题今天不展开了。同一个下午撞上的第二个幽灵drop 根本不触发写完上面这套我以为万事大吉结果在鸿蒙 PC 上又遇到一件邪门事拖文件进去drop事件压根不响鼠标都变成禁止图标了。查了一圈才反应过来这是个比file.path还冷门的坑。drop能不能触发前提是你在dragover上也调用了preventDefault()。Windows 上我那版代码恰好在别处顺手拦了默认行为所以一直没暴露鸿蒙 PC 这版我从零写的漏了这行于是系统默认把拖拽当成不接受drop永远到不了你监听的地方。// renderer.js —— 漏掉 dragover 的 preventDefault鸿蒙 PC 上 drop 永远不触发constdropZonedocument.getElementById(drop)// 必须拦否则鸿蒙 PC 上系统会接管拖拽drop 事件收不到dropZone.addEventListener(dragover,(e)e.preventDefault())dropZone.addEventListener(drop,async(e){e.preventDefault()constfilee.dataTransfer.files[0]constabawaitfile.arrayBuffer()window.electronAPI.handleDropped(ab,file.name,file.type)})这行dragover的preventDefault()看着不起眼我敢说一半以上的人第一次在 Linux 系桌面上接拖拽都会栽。鸿蒙 PC 基于 OpenHarmony 的桌面环境对这个默认行为更较真漏了就直接不给你机会。三种写法我全试过给你个痛快对比写法鸿蒙 PC 能否读主进程 fs 可用我的评价file.pathfs.readFileSync拿不到空串路径都空了谈何读取趁早别用纯属埋雷webUtils.getPathForFilefs拿到沙箱路径沙箱挂载点读不到能拿路径但读不了半残file.arrayBuffer()传字节直接读字节不需要路径三端通吃我现在就靠它我特别讨厌那种看起来对、跑起来不对的代码file.path就是典型。它在本机测一百次都对一上鸿蒙测试机就给你表演原地爆炸还偏挑你最容易放松警惕的地方下手。那什么时候才真的需要路径也不是说webUtils.getPathForFile没用。当你要把这个文件交给一个外部程序处理——比如拖段视频进来决定调ffmpeg转码——那种情况你总得给 ffmpeg 一个路径。这时候就老老实实用getRealPath只是在鸿蒙 PC 上得额外走一层原生桥去把沙箱里的文件拷到应用自己的目录再拿那个拷出来的路径喂给外部进程。属于另一个坑了今天先不展开。我个人现在的原则很简单能在渲染进程用arrayBuffer解决的事绝不去主进程按路径读。少一个平台差异少一个半夜被测试机叫起来的理由。这次踩完之后我顺手把之前两个老项目里的file.path全改了心里踏实不少。你项目里要是也有拖拽上传不妨去翻翻有没有file.path这种写法趁早换成字节流。你踩过这坑吗顺带一提雷达鸭的鸿蒙桌面端现在拖拽上传就是按这套arrayBuffer写法跑的目前没再翻过车。老三10 年软件开发经验软件设计师人工智能应用工程师。平时主要折腾鸿蒙应用开发ArkTS 北向和 Web 前端也爱鼓捣 AI 自动化。鸿蒙 / AI 方向的踩坑会不定期发在 CSDN。本文遵循 MIT 协议转载请注明出处。