resources/app 为何能覆盖 app.asar

一个真实的补丁场景

给「不可能片场」的发布工具打补丁时，我遇到过一个反直觉的现象：改了 app.asar 里的 main.js，重启后改动不生效；把 app.asar 解包成 resources/app/ 目录、改里面的 main.js，重启后改动立刻生效，而且会盖过 asar 里的原版。

这不是玄学，是 Electron 的加载优先级决定的。

asar 是什么

Electron 为了规避 Windows 下「路径太长 / 文件太多」的问题，把渲染进程和资源打进一个 app.asar 归档文件。默认情况下，应用从 app.asar 读代码。

resources/
├── app.asar          # 打包后的主归档（只读、压缩）
└── app.asar.unpacked # 少数必须解包的大文件

关键优先级：resources/app 优先

Electron 在定位应用代码时，会先看 resources/app/ 这个目录 是否存在。如果存在，就直接用目录里的文件，不再读 app.asar。

优先级大致是：

resources/app/  (解包目录)  >  app.asar  (归档)

这就是为什么「解包后改目录」能覆盖「改 asar」------目录里的文件被先找到，asar 里的同名文件被跳过。

这带来的工程后果

对需要热修的场景，这个机制是好事：不用重新打包，把补丁丢进 resources/app/ 就能生效。但代价是脆弱性：

1. 应用一升级 / 重装，resources/app/ 会被新包覆盖，补丁丢失；
2. 多个补丁散在目录里，升级后容易「补丁还在但路径已变」而失效。

所以给生产工具打这类补丁时，我的习惯是：补丁文件旁边留一份 *.bak-before-xxx 原始备份，并在运维手册里写清「升级后必须重打」，而不是指望它能永久存活。

小结

resources/app 覆盖 app.asar 不是 bug，是 Electron 故意保留的目录优先加载策略。理解它，热修就简单；忽视它，升级就是一次无声的回滚。