某个同事说，现有的Electron内置浏览器在F12的性能测试里，发现JS文件无法定位，或者定位错误，问我怎么办。
看了下，在MacOS中是没问题的，只有Windows下莫名其妙有。但我就这点儿能耐，又能怎么办？
只能升级Electron试试呗。于是，将electron的依赖包从v31升级到最新稳定版本v32。
开始以为挺顺利，没想到看到项目的网络里报错了：
控制台也是提示本地资源文件加载失败：
这就有点儿让人懵逼了。
我下意识以为是浏览器改变了什么安全策略，但追踪后发现浏览器中直接加载的file:///是没问题的，只是WebAssembly（wasm）加载的有毛病。
为什么有的资源会用
wasm加载呢？原因是这些资源进行了加密，用wasm进行解密，可以有效增加外界破解难度。
再看了下，Electron v31用的126的Chromium内核，v32用的是128的内核（在这里看Chromium内核版本）。
但其实在浏览器里是无法直接加载本地文件的，这个功能只有Electron或Tauri这种App才能做到，所以一时无法确定是浏览器的锅，还是Electron的锅。
走投无路之际，我问了下GPT：
GPT说的这句看着是有道理的：
在新版本的 Electron 中，可能对
file://或其他自定义URL scheme的支持做了一些修改。例如，WebAssembly加载本地文件可能涉及到资源路径的解析，而 Electron 132 版本可能对非标准的 URL scheme 进行了更严格的验证，导致无法正确识别file://。
下面第三条其实我开始Google搜索见到过，确实可以拦截到file:///的文件请求：
但给的示例是用的interceptFileProtocol，导致所有file请求都报错了：
protocol.interceptFileProtocol('file', (req, callback) => {
const url = req.url.substr(8)
callback(decodeURI(url))
})
现在修改成registerFileProtocol，试上一下：
protocol.registerFileProtocol('file', (request, callback) => {
const filePath = request.url.replace(/^file:\/\//, '')
callback({ path: filePath })
})
居然好了！
由于这个API已经被提示不推荐使用：
所以又找了下替代方案，这样看起来优雅多了：
protocol.handle('file', (req) => {
return net.fetch(req.url, { bypassCustomProtocolHandlers: true })
})
问题解决了，但回到我们开始的问题，到底是Chromium的锅，还是Electron的锅呢？
我还是不确定。去掉这段代码，尝试将Electron降到v32的第一个版本32.0.0，仍然是报错；降到v31的最后一个版本31.6.0，是没问题的。
看Electron v32的发版日志里，破坏性变更仅有移除上传文件File的不标准的path：
而看Chromium v127 的发版日志 和 v128 的发版日志也没看出个所以然来，有安全层面的更新，不清楚是否有关。希望有大佬解答下。
搞客户端开发有时候不得不升级依赖，但一升级又可能有这样那样的问题，无奈。
