企业官网建设流程全解析

LocalSend AppImage 制作完全指南：跨发行版兼容这样落地

【免费下载链接】localsendAn open-source cross-platform alternative to AirDrop项目地址: https://gitcode.com/GitHub_Trending/lo/localsend

LocalSend 是一个走局域网的文件传输工具，不经过任何云端。但它在 Linux 上的分发一直很头疼：同一份程序，在 Ubuntu 上正常，换到 Fedora 托盘图标消失，在老系统上又缺库。本文围绕 LocalSend AppImage 的制作过程，拆解它如何通过“锁定基础源 + 精准打包依赖”实现跨发行版兼容，你可以直接照着复现，也可以把思路搬到自己项目里。

一句话说清它是什么：AppImage 就是"可执行文件 + 它跑起来所需的那几套库"被压进一个文件。对 LocalSend 而言，意味着把一个LocalSend-x.x.x-x86_64.AppImage丢给同事，chmod +x之后双击就能用，不用先问对方装的是什么发行版、缺不缺依赖。

动手之前，先拍板三个决策点

很多人一上来就抄配置，但真正影响成败的是下面三个选择。

决策一：到底要不要做 AppImage

LocalSend 的官方渠道里，Linux 其实同时提供了 DEB、TAR、Flatpak、Snap、AUR 和 AppImage。它把 AppImage 当成"兜底通用档"——仓库渠道管更新，AppImage 管覆盖长尾系统，两条腿走路。

决策二：基础源锁定哪个发行版

这是整个配方里最关键的取舍。官方配方（support/build/appimage/AppImageBuilder_x86_64.yml）把 apt 源全部锁在 Ubuntu jammy（22.04 LTS），并且带上了 jammy-security 安全源。

• 选新版源（如 noble）：库新、工具链舒服，但基准抬高，老机器可能载不动，等于主动缩小兼容面；
• 选过老的源：新工具链的依赖装不上，构建本身就会卡住；
• 选 jammy LTS：够老以兼容大多数机器，够新以满足 Flutter 构建期依赖，而且 LTS 的安全源维护周期长，配方几年不用动。

一句话：基础源不是选"最好的"，是选"维护窗口最长、兼容面最大"的。

决策三：依赖怎么取舍

配方的 include 列表只有两个包：

• libayatana-appindicator3-1—— 系统托盘库。LocalSend 是常驻托盘应用，缺了它应用还能跑，但托盘入口直接消失，等于残废；
• librsvg2-common—— SVG 图标渲染，界面图标显示需要它。

而 exclude 列表则反向操作：砍掉adwaita-icon-theme，再砍usr/share/man和各包的 README / changelog / NEWS / TODO 文档。

取舍哲学就是"只带必然缺失的，不带锦上添花的"。判断方法很简单：ldd跑一遍产物，把"系统大概率没有"的库加进 include，把"纯文档类"内容加进 exclude。

LocalSend AppImage 制作：四步出产物

官方构建脚本在support/scripts/compile_linux_appimage.sh，配方分 x86_64 和 arm_64 两份（support/build/appimage/AppImageBuilder_arm_64.yml），两份内容几乎一样，只差arch字段和依赖包的架构后缀。

第 1 步：准备构建机

# Flutter 构建依赖 + 托盘库开发包 + AppImage 挂载所需的 fuse sudo apt install curl clang cmake libgtk-3-dev ninja-build libayatana-appindicator3-dev libfuse2 # 另需从发布页获取 appimage-builder v1.1.0 并赋予执行权限

第 2 步：克隆仓库并编译出 Linux 可执行文件

git clone https://gitcode.com/GitHub_Trending/lo/localsend cd localsend git submodule update --init # 拉取仓库内自带的 Flutter SDK ./submodules/flutter/bin/flutter pub get ./submodules/flutter/bin/flutter build linux # 产物在 build/linux/x64/release/bundle/

第 3 步：组装 AppDir，跑配方

mkdir AppDir cp -r build/linux/x64/release/bundle/* AppDir # 把编译产物放进 AppDir cp support/build/appimage/AppImageBuilder_x86_64.yml AppImageBuilder.yml appimage-builder # 自动读取同目录配方，生成 AppImage

第 4 步：验证

chmod +x LocalSend-*-x86_64.AppImage ./LocalSend-*-x86_64.AppImage # 托盘里出现 LocalSend 即成功

配方里每个配置块各管一件事：

• app_info：产物的"身份卡"。exec: localsend_app指定入口可执行文件，exec_args: $@保证命令行参数原样透传给应用，version写进元数据；
• apt：定义"依赖基线"。sources 是锁定 jammy 的那一长串，include/exclude 就是决策三里说的取舍；
• runtime.env：把/usr/local/share/等路径前置进XDG_DATA_DIRS，让应用在自己的沙箱里也能找到图标和桌面元数据；
• files.exclude：裁剪文档类文件，控制最终体积；
• AppImage：声明目标架构，update-information: guess是更新探测方式。

有个容易漏的细节：配方里的version目前是写死的（当前为 1.18.2），你切新版本自己出包时，记得手动同步这个字段，否则产物元数据是错的。

踩坑清单：遇到 X，这样做

• 报mksquashfs不存在→ 配方顶部那行which mksquashfs || apt install squashfs-tools就是干这个的，本地构建前自己也装一份；
• chmod +x后执行报"cannot execute"或找不到文件→ 构建机/目标机没装libfuse2，AppImage 挂载靠它；
• 托盘图标不显示→ 检查 include 里有没有libayatana-appindicator3-1，架构后缀（amd64/arm64）别拼错；
• 想在 x86 机器上顺手出 arm_64 包→ 两份配方不能互替，需要 arm64 构建机或 CI 环境；
• 想在 CI 里跑配方中的 test 容器验证→ 官方配方把 test 块整段注释掉了，原因是容器化测试环境在 CI 里不稳定，跨发行版验证靠真机更靠谱；
• 最小化系统上文件选择框打不开→ 文件对话框依赖宿主系统的 xdg-desktop-portal，它不在 include 清单里（属于"宿主应该有的"那类），Gnome 下需xdg-desktop-portal-gtk，KDE 下需xdg-desktop-portal-kde。

效果与验证：实际跑起来是什么状态

• ✅体积：单个文件数十 MB，包含 Flutter 运行时、GTK 相关依赖和那两三个显式声明的库，换来的是零安装、零 root；
• ✅启动体验：双击（或./执行）秒进托盘，无需任何系统级配置，卸载就是删文件；
• ✅架构覆盖：x86_64 与 arm_64 各有一份产物，树莓派和 ARM 服务器也能用；
• 兼容面：基础源锁 jammy 意味着"发行版越老越吃香"——Debian 11、Ubuntu 20.04+、Fedora 这类主流系统都是安全区；越新的系统（自带更新版库）通常也向下兼容。真正的验证方式不是猜，而是丢两三台不同发行版的真机（或虚拟机）跑一遍"发现设备 → 互传文件"的完整流程。

按你的身份给两条建议

如果你是终端用户：直接拿现成的 AppImage 即可。老系统上执行失败时先补libfuse2；另外 AppImage 本身没有自动更新，建议定期从官方发布页拉新版，或者干脆走 Flatpak / 发行版仓库，让系统替你管更新。

如果你是集成开发者：拿support/build/appimage/下这两份 yml 当模板。给自己的 Flutter 应用做 AppImage 时，照本流程走一遍，唯一要改的就是app_info、include 列表（先ldd找出缺失库再逐个加）和 version 字段——把"依赖基线"和"最小包含"这两个思路保住，坑会少一大半。

回到开头那个场景：同事的 Ubuntu、你的 Fedora、还有一台不知道装了啥的老 Linux，现在它们只需要同一个文件。这就是 AppImage 给 LocalSend 带来的东西——不是更炫的功能，而是"少一个解释，多一台能跑的机器"。

【免费下载链接】localsendAn open-source cross-platform alternative to AirDrop项目地址: https://gitcode.com/GitHub_Trending/lo/localsend