eaio (Electron All in One)
开发者自荐
一个通过将磁盘上所有Electron应用中相同文件硬链接到统一位置来减少磁盘占用的解决方案，就像pnpm 一样。
还在苦恼大前端趋势下，硬盘中 Electron 应用越来越多吗？本工具可以将 Electron 应用硬链接到其所在磁盘分区根目录的.electron仓库中，从而实现一份文件多应用使用，大大减少磁盘占用。（最终效果取决于：同一磁盘分区中，同一 Electron 版本和架构的应用有多少）
本工具支持自动识别应用入口、自动判断 Electron 版本和架构、自动判断是否应该被硬链接。
具体效果可通过WizTree查看。
WankkoRee/eaio - latest release (github.com)
好奇如果软件被升级，会发生什么？
这个这个，牛逼
取决于软件升级是覆盖文件还是直接改动文件，如果改动文件则会导致.electron仓库中的文件也被更改，进而影响其他同个硬链接来源的应用；如果覆盖的话则会使得这个应用中原来的硬链接失效一部分。
可以在升级完成后，通过eaio check 应用目录检查硬链接有效情况，有可硬链接的提示则eaio link 应用目录一下即可；通过eaio status检查.electron仓库中的文件是否被更改，有更改可通过eaio download 盘符 版本 架构进行修复，修复后，那个升级完成的应用会发生版本回退（待解决，打算加个unlink操作可以取消指定应用的硬链接，这样子先unlink再download就不会影响这个应用，然后重新link就行）。
后续应该会更加傻瓜化一点，现在相对来说过于极客了。
看着好牛B，才发帖讨论了 有没有一种可能，让Chromium内核的应用精简一下，调用系统中已经存在的内核？ - 讨论分享 - 小众软件官方论坛 (appinn.net)，紧接着就有方案了，有空了试试。不知道理论上存不存在稍微提高点启动速度？
启动速度应该是没区别的，毕竟还是同一个版本的electron
我看了下，无论是PE，ELF，还是MACH-O，都可以搜到Electron版本。一个更高效的搜索模式是%s/%s Chrome/%s Electron/，这个字符串用于v8输出调试信息，目前看来是固定的。
另外Electron有一个中文镜像，路径格式与主仓库完全一致，包括sha256的checksum文件，比起代理我觉得可以切换镜像比较优先。。
我依然觉得这套东西需要开发者支持。
先说几个题外话，首先应用更新功能对于硬链接而言很不利：pnpm能够采取硬链接方案的基础在于，它是一个包管理工具，基础库的调用方不会基础库本身的内容，但electron应用显然不是；其次硬链接存在上限，win下是1024次，linux下是65535次，mac下倒是很大方，INT32_MAX，单一的硬链接方案实践上其实很足够，但从理论上就不是很美好。
所以我个人觉得，方案不是问题，最大的问题在于如何说服或者说吸引开发者把自己的应用加入到这个应用商店(其实对开发者来说是0成本)，如果只是简单的弄一个启动方案，势必要做许多复杂的工作。理想中这应该是一个项目发布平台，或是项目结构约定。
不瞒你说，之前你告诉我二进制文件里有版本信息后，我也写了个方案，代码就不发了，一个配置文件就能说明我的思路：
{"appName":"",
"appVersion":"",
"appPath":"",
"appStartupArguments":"",
"targetArchitecture":"",
"targetOperationSystem":"",
"electronVersion":"",
"electronChecksum":"",
"electronMirror":"",
"updateMirror":""}
不过实在没啥信心。
其实说实话，最好的解决方案肯定是 Electron 项目核心开发者以官方的身份去搞跨版本适配或者整个Electron Runtime Environment，但很明显官方没这个心思，跨版本做的也不行，运行时环境也遥遥无期，只能凑合写个理论上好使的东西了。
那个format字符串我倒是看见了，但以个人开发经验来说，在一个已经打包好的Electron中，Chrome版本应该是固定的，这个Chrome/%s显得没有必要，除非啥时候支持侧载Chromium了可能会用上。所以如果我是开发者的话，指不定哪天觉得这个format没必要就给删了 
。
关于下载来源的方案，后续会加上的，确实需要考虑非专业用户的上网习惯。
下载了，但不会用[苦闷]，也有不少如上面回贴说到的升级了会不会 失效这类疑问
最近会出个带界面的，然后会完善一下教程说明，以及目标应用更新了该怎么办的Q&A。
很棒的想法 尝试着用了下 似乎得自己去指定electron应用的路径。配合CEF dector使用一个一个找 易用性不算太好…
期待。。
个人感觉electron应用的问题不是硬盘，而是进程
新版本发布：Release v0.2.0 · WankkoRee/eaio (github.com)
此版本(v0.2.0)对链接仓库的命名发生了改动，由.electron改为.eaio，防止与 Electron 官方潜在的资源命名冲突。
烦请各位用户手动重命名各磁盘分区下的链接仓库文件夹。
--Verbose/-V选项./eaio命令使用。eaio命令全局可用。
我也非常同意进程才是大问题。通常硬盘不够可以直接加，或者手动删掉点不需要的东西。但进程消耗的是 CPU 和内存，升级起来更加费事又花钱。
但 Electron 不仅消耗内存，同时也在消耗硬盘，这是它天生的缺陷。如果这个工具未来能继续优化下去，可能 Electron 的最大缺陷之一会就这样被曲线解决了？
总之我先点个
观望一下，期待 1.0 版本！
这是个不错的应用。虽然我不打算用，因为我不差硬盘空间，但思路真的非常好
我也通常不会选择electron应用，除了vscode，原因是性能差
符号链接 吧
不是 symlink 哦，是 hardlink ，本来是想用 symlink 的，奈何 Electron 不支持。
读完了帮助，现在成功的找的了两个程序，链接之后也没有出现什么问题。
现在有两点比较困惑大佬有空帮忙解答一下哈：
除此之外，建议也有一些：
关于文件问题：文件仍然存在就是预期情况，因为硬链接目的就是让已有的文件变成一个一模一样的替身（所以也就是说不需要删除，也不能删除），而其特性就是几乎看不出这个文件被链接过。至于硬盘空间，可以尝试在链接前后分别观察：右键硬盘-属性-已用空间的数值，应当会变少。
关于 CEF：Electron 是众多 CEF 方案的其中一种实现，而CefDetector/CefDetectorX的扫描功能并不是只扫描 Electron ，其他诸如 libcef 、 NW.js 、 MiniBlink 等方案也是能被扫出来的，所以在扫描结果中只是一部分是 Electron 应用，本工具自然也是只有这一部分能正常识别。
关于记录：链接记录这个在后续版本有计划会加上，但是还没想好怎么存。
关于分享：后续能自定义链接版本后，应该会在 GitHub 的讨论区开个各应用对各版本兼容性的分享板块。脚本或者流程的话其实个人感觉没有必要，因为实际上链接这个关键步骤只有一步。