Linux 平台的软件分发不像 Windows 或 macOS 那样有单一的“标准包格式”，而是同时存在多种打包体系。在实际的 Electron 项目中，你通常需要为不同的 Linux 发行版生成对应的安装包，最常见的三种格式是 deb（Debian / Ubuntu 系）、rpm（Red Hat / Fedora 系）和 AppImage（通用便携格式）。electron-builder 对这三种格式都有非常完善的支持，只需在配置文件中指定目标，就能从同一套代码中一次性构建出来。
1.3.3.1 基础配置：一次性支持三种格式
在 package.json 的 build 字段（或独立的 electron-builder.yml）中，你可以这样写：
{
"build": {
"appId": "com.example.myapp",
"productName": "MyApp",
"directories": {
"output": "dist"
},
"linux": {
"target": [
"deb",
"rpm",
"AppImage"
],
"category": "Utility",
"icon": "assets/icons"
}
}
}target数组指定了需要生成的包格式，electron-builder 会自动调用相应的工具链来构建。category是一个自由桌面规范（FreeDesktop）要求的分类，用于在应用菜单中正确归类，常见的值有Utility、Development、Office、Graphics等。icon目录需要包含符合 Linux 标准的 PNG 或 SVG 图标，通常放在build/icons下并命名为icon.png，builder 会自动进行尺寸转换。
运行构建命令：
npx electron-builder --linux构建完成后，你会在 dist 目录下看到类似 myapp_1.0.0_amd64.deb、myapp-1.0.0.x86_64.rpm 和 MyApp-1.0.0.AppImage 的文件。
1.3.3.2 deb 包的细节配置
deb 包用于 Debian、Ubuntu、Linux Mint 及其衍生版本。electron-builder 生成的 deb 包默认包含了依赖声明，并且支持设置维护者、包描述等信息。你可以在 linux 配置下进一步细化设置：
"linux": {
"target": "deb",
"maintainer": "dev@example.com",
"executableName": "my-app",
"synopsis": "A short description",
"description": "A long description that can contain multiple sentences and paragraphs."
}maintainer：包的维护者信息（邮箱格式），会写入包的元数据。executableName：安装后二进制文件的名称，也是用户在终端输入的命令名（须符合 Linux 文件名规范，通常使用小写和短横线）。synopsis/description：包管理器的简短和详细描述（dpkg -I显示的内容）。
如果你想在安装时创建桌面快捷方式或 MIME 类型关联，可以使用 extraResources、fileAssociations 等通用字段配置，这些对所有 Linux 包格式都生效。
1.3.3.3 rpm 包的细节配置
rpm 包适用于 Fedora、CentOS、RHEL、openSUSE 等。其基础配置与 deb 类似，但有少量特有的字段：
"linux": {
"target": "rpm",
"rpm": {
"summary": "Short summary",
"description": "Long description",
"packager": "Your Name <dev@example.com>",
"depends": [
"libsecret-1.so.0"
]
}
}summary/description：rpm 包的摘要和详细描述，对应rpm -qi的输出。packager：打包者信息，可以用“姓名 <邮箱>”的格式。depends：手动添加额外的依赖包。electron-builder 通常会自动检测需要的库（如 libgtk-3、libnotify 等），但某些情况下你可能需要显式声明（例如，使用了需要依赖密钥环的原生模块时添加libsecret-1.so.0）。
1.3.3.4 AppImage 的配置
AppImage 是一种“一次编译，到处运行”的格式，它不依赖系统的包管理器，用户只需下载一个文件、赋予执行权限即可运行。它的配置最简单，因为大部分内容都内嵌进了单一的二进制：
"linux": {
"target": "AppImage"
}默认生成的 AppImage 没有桌面集成（如自动添加到应用菜单）。如果需要这些功能，通常是在运行时由 AppImage 内部的工具在首次启动时完成（electron-builder 已经内置了相应的处理）。你可以通过 appImage 字段指定一些选项，比如指定架构：
"linux": {
"target": {
"target": "AppImage",
"arch": ["x64", "arm64"]
}
}需要注意的是，AppImage 不会自动检查或安装依赖库，因此要求目标系统的 glibc 版本必须兼容。为了提升兼容性，electron-builder 默认会在较老的 Ubuntu 基础镜像上进行构建（可在 CI 中通过 Docker 环境保证），以确保生成的 AppImage 能运行在大多数主流发行版上。
1.3.3.5 图标与桌面文件
无论是哪种包格式，你都需要提供一个符合 Linux 标准的桌面入口文件（.desktop 文件）。electron-builder 会根据你的应用信息自动生成此文件，但如果你希望自定义，可以放在 build 目录下并指定 desktop 字段：
"linux": {
"desktop": {
"Name": "My Application",
"Comment": "A sample app",
"Categories": "Utility;Development;",
"StartupWMClass": "my-app"
}
}StartupWMClass很重要，它用于将应用窗口与桌面条目正确关联，避免在任务栏或启动器里出现重复图标。它的值通常就是executableName或productName（去掉空格）。如果不确定，可以先构建一次，然后运行xprop WM_CLASS并点击你的应用窗口来查看实际值。
1.3.3.6 实际开发建议
- 在 CI 中构建 Linux 包：由于 Linux 构建可能依赖特定的系统库（如
rpmbuild、fakeroot），最稳定的方式是通过 GitHub Actions 等 CI 服务，使用 Ubuntu 或 CentOS 的 Docker 容器来进行构建。这样既能避免本地环境差异，也方便同时输出三种格式。 - 测试兼容性：deb 和 rpm 包安装后，务必在干净的虚拟机或 Docker 中验证依赖是否正确，AppImage 则在多种发行版上测试运行情况。常见的问题是缺少
libnotify或libdbus等库，如果无法通过自动依赖检测加入，就手动添加到depends中。 - 自动更新：通过
electron-updater也能为 Linux 的这三种包格式提供增量更新，但实际服务器后端的配置需要匹配对应格式和架构，这在商业分发中是一个重要考量。
通过以上配置，你的 Electron 应用就能完整覆盖 Linux 三大主流发行体系，让用户以他们习惯的方式安装和卸载。这套配置一经设定，后续每次发布只需运行一条命令，即可得到所有目标包，真正做到一套代码多端交付。