直接目录下放好各种dll——这种其实不会太大，几M就很大了。
现在真正大的是chrome内核（400M，压缩后还要80M）或python环境，.net库就不说了。
压缩包的，就是自己带dll了，还不用安装折腾，已经不错了。不会太大。
漏了：delphi写的exe，那真的是一个exe，除非使用到特别的dll，就再加上它们。
无所谓，就那点鸡毛蒜皮的空间占用。就算是半G吧，现在固态好点的0.5/G，这半G就是0.25元。按照西部山区省份最低工资标准18元时薪，1分钟就是0.3元，但凡这空间占用能为你节省一分钟的处理时间，就是妥妥的血赚。
时间就是金钱，我的朋友。
即使是你说的 假单文件exe，也没有浪费你的时间啊。
至于空间，很多旧电脑没条件升级，能省空间还是很必要的。
没必要，Chromium的跨版本兼容性并不好，Electron的尽头就是成为下一个JRE，开发者除了要使用各种奇技淫巧作为workaround的同时，还会对其本身做出魔改。我倒是乐于见到他们把这类作品尽可能上云，不然本地同时跑十几个Chromium，笔记本续航会比较捉急。
如果你一定要这么做，那创建链接应该可以吧。
上面大家说了挺多的开发者角度的方案，其实作为用户来说，硬链接应该是一个比较好的方案，在分区根目录存放以大版本号区分的各个版本的Electron，然后将其链接到需要对应版本的应用中。
关于软硬链接：我不确定Windows下的软连接是否能被Electron当成正常文件使用，所以为了以防万一，用硬链接肯定是没问题的，只不过硬链接相对来说没那么优雅。
关于分区根目录：这个其实是硬链接的原理所造成的必要条件，一个文件镜像两份，那么这个文件的数据必须要在同一个分区才行，你不能在一个分区创建硬链接去引用另一个分区的文件。
关于大版本号区分：一般在版本迭代时，对api进行删、改的变动只会出现在大版本更新中，所以只要确认给应用链接上的大版本是一样的，应该就没啥问题。
灵感来自pnpm。
electron可以指定app路径:
electron [options] [app-path]
app路径在应用的resources文件夹下，app的各种依赖之类都是在这里，我们运行app，只不过是运行了一个改了名字和图标的electron，这不是难点。
比较麻烦的问题有两个：
- 很难判断目标app的electron版本。不是所有的app都主动提供electron版本信息，也不是所有的app都会保留
package.json文件中的devDependencies字段，如果没有的话，只能放弃或者一个一个版本测试。 - 部分程序，会有一个自身的二进制组件，放在主目录或者其他地方，比较典型的就是更新组件了，这也给整合增加了难度。
所以本质上这个不是用户能解决的东西，需要electron官方的支持，以及应用提供方的配合。
.net了解一下，就是后面每个版本几百mb
Electron应该改为：
- 主要框架的exe、dll固定（400M），
- 具体扩展功能由个别的dll实现（几M）
这样，一个系统里的不同Electron应用，大头是可以共享的，只有几M是每个应用自己编译的
主要还是兼容性问题，electron没有向后兼容，打包依赖可以保证在不同的机器上都是可以运行的，至于空间占用大部分人都可以忍受或者不在乎。
linux采用了依赖的方式处理程序，结果就是依赖地狱恶心到爆，本质还是因为不存在一个理想的永远保证兼容的依赖结构，最终还是要区别指定不同的版本。
就和各类编程语言的虚拟开发环境一样，隔离解决了复杂性，只是牺牲了一点点磁盘空间。在减少开发复杂性和一点点无关紧要的用户使用体验上权衡，在目前的条件下还是选择前者。程序开发的现状就是大小不同的作坊，没有也不可能有统一的标准，社区有社区的约定，但很多时候都保留了最初开发者的某些个人趣味。
2 个赞
怕存在篡改问题，比如公共库被篡改了，造成问题很难排查
对现在这个时代的应用，一个游戏动辄二三十个G，装个实用的软件百十来M还算可以忍受。
很多内核不是通用的，而是魔改的。
尤其是钉钉、QQ（新版）、微信等使用的内核。
关于如何确认 electron 版本，可以查找一些特征字符，如从v0.30.0开始一直到现在都有的Chrome/[0-9.]+ Electron/[0-9.]+。
关于目标应用自己打包了一些二进制组件这个问题，在硬链接方案下不存在问题，但直接通过命令行去指定resources路径的话，确实会有问题，所以我更推荐硬链接方案。
尝试着实现了一下比较简陋的硬链接方案，后续完善后会开源在 WankkoRee/electron-all-in-one (github.com)，欢迎 star。
在WizTree中可以看到目标应用文件夹CaptfEncoder和仓库文件夹.electron在磁盘空间分配上，只占用了一份的大小，成功瘦身。
此方法因为会将应用入口的exe程序也链接到electron.exe，所以会造成应用图标丢失，这种情况不可避免（毕竟占大头的文件就是这个应用入口），后续可能会考虑将图标提取到应用目录，以供修改快捷方式图标。
竟然没有pre-view版本？ 
甚至我比你自己还先star（doge
Windows用硬链接实在是有点不太优雅…
记得我看到过一个人用硬链接结果递归删除时候把整个C盘都删了的，一直不敢用.
我觉得可以试试能不能做成把已有electron应用的文件提取出来放到一起存储之后用一个界面或者命令行参数去启动对应应用的形式.
你说的那个可怜人在这里
鞭尸（doge
看了下，那位老哥是用的软链接（或者叫符号链接symlink），与硬链接hardlink不一样。
比如说这个是创建软链接后的结果：
显示图标是类似于快捷方式，但是类型依旧是文件夹，其存在依赖于源文件夹，如果删除了源文件夹则这个文件夹也会失效（断链），和快捷方式的工作方式差不多。
而创建硬链接则几乎没啥办法能直观地看出文件是否被硬链接，只有文件系统中的stat会存这个文件被硬链接到了多少个地方。
具体一点（其中小写字母a为磁盘数据，可以被文件系统中的文件指向；大写字母A、B为具象化到文件系统中的文件，可以指向磁盘数据）：
- 软链接是这样：
a->A->B，表示将A作为源文件创建个软链接到B，如果A删了，那么就变成了a->?->B，所以B会变得不可用。 - 硬链接是这样：
a->A,a->B，表示将B指向到A指向的磁盘数据，如果A删了，那么就变成了a->B，并不会影响B的使用。但是如果对A或者B改动其内容，则另一个B或者A也会被改动，因为实际上是同一个磁盘数据。 - 复制文件是这样：
a->A,b->B，其中a和b是内容相同的两份磁盘数据，如果A删了，那么就变成了a->B，也不会影响B的使用。而如果对A或者B改动其内容，不会影响另一个B或者A，因为a和b并没有实质上的联系。
而在软链接和硬链接下，因为实际上磁盘中都只存在一份磁盘数据，所以并不会占用多份磁盘空间。
为啥不用软链接：测试过，软链接的electron.exe在运行时，会把运行目录直接拉回electron.exe本体所在的目录，所以会出问题。
为啥不用命令行：可能会存在需要额外调用一些可执行程序的情况，如经典的update.exe，可能会出现找错目录的情况。
为啥不合并应用：各个应用的 electron 版本不一样，这玩意跨版本兼容性感人，而且和上面的原因有重合，可能会需要引用一些额外的dll或其他东西，容易出现无法找到的情况。
再补充一下，硬链接因为需要多个文件都直接指向磁盘数据，所以无法跨磁盘/跨分区创建，但是软链接更像是快捷方式，所以是可以跨磁盘/跨分区的，那位老哥也是因为软链接能跨盘，所以才用软链接去挪移不同分区中的数据。
版本兼容问题估计没办法了不是软连接硬连接能解决的。
但是你这么做的话一个应用卸载时候不会把别的也都删了吗…
误删的话并不会，因为误删只会存在于软链接的情况（因为可以获取到明确的源文件指向），而硬链接则不会有这个问题，因为我自己都没法知道这个文件还在哪有硬链接 
。
硬链接的删除方案是基于磁盘驱动程序的，当磁盘驱动发现一个文件被删除时，会去把这个文件的磁盘数据的引用次数-1，如果归零了就相当于这片位置已经不存在数据了，但是如果有硬链接，那么引用次数必然>=2，所以-1之后还是>=1，并不会出现数据块被当成空的情况。