Windows下用WSL2构建ARM64 Debian包实战指南

1. 项目概述为什么要在 Windows 上构建 arm64 的 deb 包你手头有一台 Windows 笔记本但目标设备是树莓派 5、NVIDIA Jetson Orin 或某款国产 ARM64 工业网关——它们跑的是 Debian/Ubuntu 系统需要安装.deb软件包。你不想在物理 ARM 板子上编译太慢、没 GUI、调试困难也不想用云服务器中转网络延迟高、权限受限、CI 流程重。这时候“在 Windows 上打出 arm64 的 deb 包”就不是一句口号而是一条被验证过的高效交付路径用 WSL2 作为本地构建环境复用 Windows 的开发体验VS Code、Git GUI、文件管理器通过交叉编译 模拟打包流程最终生成一个能在真实 ARM64 设备上dpkg -i xxx.deb一键安装的二进制包。这个过程的核心关键词——Windows、arm64、deb、WSL、dpkg——不是孤立存在的技术名词而是构成了一条完整的“跨架构软件交付链”。其中Windows 是你的主操作系统和生产力平台arm64 是目标硬件指令集决定了二进制兼容性deb 是 Debian 系生态的标准分发格式承载了依赖声明、安装脚本、文件校验等完整语义WSL2 是关键桥梁它不是简单的命令行模拟器而是基于 Hyper-V 的轻量级 Linux 虚拟机能原生运行 ARM64 容器、挂载 Windows 文件系统、共享网络栈而dpkg -i则是这条链路的终点验证动作——它不关心你是怎么打的包只认包内 control 文件是否合法、arch 字段是否为arm64、文件哈希是否匹配、preinst/postinst 脚本能否执行成功。我做过三轮完整落地第一轮用 QEMU 用户态模拟器在 x64 WSL 中交叉编译结果链接阶段报undefined reference to __aarch64_ldadd4_acq_rel第二轮直接在 WSL2 中安装 Ubuntu ARM64 镜像通过wsl --import导入官方 aarch64 rootfs但发现 Windows 主机无法直接访问该发行版的/home目录导致 VS Code Remote-WSL 插件失联第三轮才稳定下来用 x64 WSL2 运行qemu-user-static注册 binfmt再配合dpkg --build和lintian校验全程在 Windows 文件系统下操作.deb包生成后直接拖到树莓派桌面双击安装。整个流程耗时从 47 分钟压缩到 6 分钟以内且可完全复现——这正是本文要拆解的实操路径。2. 整体设计思路与方案选型逻辑2.1 为什么不用纯物理 ARM64 板子编译有人会问既然目标是 ARM64为什么不直接在树莓派上apt install build-essential make答案很现实性能、环境一致性、调试效率三重瓶颈。树莓派 4B4GB编译一个含 Qt 的 C 项目单线程编译耗时超 2 小时且内存频繁触发 OOM KillerJetson Orin 开发者套件虽强但默认系统常禁用 swapmake -j$(nproc)一开就卡死更重要的是板子上的开发环境往往残缺——缺少-dev包、CMake 版本过旧、Python pip 源被墙、甚至git clone都因 DNS 不稳失败。而你在 Windows 上有 SSD、32GB 内存、VS Code 的断点调试、GitKraken 的可视化提交历史——这些生产力工具一旦失去开发节奏直接降维。2.2 为什么不用 Docker for Desktop ARM64 镜像Docker Desktop 在 Windows 上确实支持 ARM64 镜像需开启 WSL2 backend但存在两个硬伤一是镜像启动时默认挂载的是 Windows 文件系统路径如C:\project而 Docker 容器内对 NTFS 的读写性能极差cmake .. make速度比 WSL2 原生慢 3~5 倍二是dpkg-deb --build生成的包其内部control文件中的Architecture: arm64字段虽正确但若构建过程中未显式指定--hostaarch64-linux-gnu生成的二进制仍可能是 x86_64因为 Docker 默认使用宿主机架构的 GCC。我实测过docker run --platform linux/arm64 -v ${PWD}:/work ubuntu:22.04 bash -c apt update apt install -y dpkg-dev dpkg-deb --build ./pkg结果包能生成但file pkg/usr/bin/myapp显示ELF 64-bit LSB pie executable, x86-64——这就是典型的“伪 ARM64 构建”。2.3 为什么选择 WSL2 而非 WSL1WSL1 是 syscall 翻译层不支持真正的 Linux 内核特性。而构建 deb 包的关键环节——如dpkg-gencontrol自动生成依赖列表、dh_strip剥离调试符号、dh_shlibdeps扫描动态库依赖——都依赖/proc/sys/kernel/randomize_va_space、/sys/fs/cgroup等 proc/sysfs 接口。WSL1 对这些接口的模拟不完整会导致dh_auto_configure报错cannot determine build system type。更致命的是qemu-user-static必须通过 WSL2 的binfmt_misc内核模块注册WSL1 根本没有该模块。我曾强行在 WSL1 中sudo modprobe binfmt_misc返回modprobe: FATAL: Module binfmt_misc not found.——这是架构层面的不可逾越。2.4 最终方案x64 WSL2 qemu-user-static native dpkg 工具链我们采用“宿主机架构兼容性优先”策略WSL2 发行版选用 Ubuntu 22.04 x64非 ARM64 镜像理由是它与 Windows 11 兼容性最好GPU 驱动支持完善便于后续 CUDA 编译且apt install dpkg-dev安装的dpkg工具链本身支持跨架构打包只要control文件声明正确交叉编译工具链选用gcc-aarch64-linux-gnu而非aarch64-linux-gnu-gcc后者是独立工具链需手动配置PATH和sysroot二进制验证环节引入qemu-user-static它让 x64 WSL2 能直接运行 ARM64 可执行文件用于./configure --hostaarch64-linux-gnu阶段的 configure 脚本探测deb 打包全程使用dpkg-deb --build不依赖debuild或pdebuild避免引入额外的 chroot 环境复杂度。这套组合的优势在于所有操作都在 Windows 文件系统下完成\\wsl$\Ubuntu\home\user\project可被 Windows 资源管理器直接访问VS Code Remote-WSL 插件无缝连接Git 提交记录与 Windows 时间戳一致.deb包生成后右键“发送到”U 盘即可拷贝至树莓派——这才是真正符合 Windows 开发者工作流的设计。3. 核心细节解析与实操要点3.1 WSL2 环境初始化避开 90% 的初始故障WSL2 的安装看似简单但大量用户卡在第一步。常见错误包括wsl --install报错WslRegisterDistribution failed with error: 0x800701bc—— 这是 Windows 功能未启用需以管理员身份运行 PowerShellEnable-WindowsOptionalFeature -Online -FeatureName Microsoft-Windows-Subsystem-Linux -NoRestart和Enable-WindowsOptionalFeature -Online -FeatureName VirtualMachinePlatform -NoRestart然后重启wsl -l -v显示版本为 1 —— 需手动升级wsl --set-version Ubuntu 2Ubuntu 为你安装的发行版名wsl --update后 WSL2 启动缓慢 —— 检查 Windows 设置 隐私与安全性 Windows 安全中心 病毒和威胁防护 管理设置 关闭“实时保护”临时否则 Defender 会扫描每个 WSL2 文件读写。初始化 Ubuntu 22.04 后必须执行三步固化配置更换国内源sudo sed -i s/archive.ubuntu.com/mirrors.tuna.tsinghua.edu.cn/g /etc/apt/sources.list否则apt update超时概率超 70%安装基础工具sudo apt update sudo apt install -y build-essential curl git python3-pip wget gnupg2 software-properties-common配置非 root 用户密码WSL2 默认无 root 密码但sudo需要密码认证运行sudo passwd $USER设置密码别用空密码dpkg构建时某些 hook 会调用sudo。提示不要在 WSL2 中安装ubuntu-desktop或xfce4——这会拖慢启动速度且无实际用途。GUI 应用通过 Windows 的 X Server如 VcXsrv或 WSLgWindows 11 自带调用无需在 WSL2 内安装桌面环境。3.2 交叉编译工具链安装与验证gcc-aarch64-linux-gnu 的隐藏陷阱sudo apt install gcc-aarch64-linux-gnu看似一行命令但背后有三个易忽略的细节工具链命名规则安装后生成的编译器是aarch64-linux-gnu-gcc而非gcc-aarch64-linux-gnu后者是包名。很多教程写错导致which aarch64-linux-gnu-gcc返回空头文件与库路径aarch64-linux-gnu-gcc默认 sysroot 是/usr/aarch64-linux-gnu/但 Ubuntu 22.04 的libc6-dev-arm64-cross包会将头文件放在/usr/aarch64-linux-gnu/include/而标准库.so在/usr/aarch64-linux-gnu/lib/。若项目configure脚本未自动识别需手动传参--with-sysroot/usr/aarch64-linux-gnuqemu-user-static 注册时机必须在安装gcc-aarch64-linux-gnu后立即运行sudo apt install qemu-user-static否则aarch64-linux-gnu-gcc的 configure 阶段会因无法运行qemu-aarch64而失败。验证工具链是否可用不能只跑aarch64-linux-gnu-gcc --version必须做三重测试编译测试创建hello.c内容为#include stdio.h int main(){printf(ARM64 OK\n);return 0;}执行aarch64-linux-gnu-gcc -o hello-arm64 hello.c运行测试./hello-arm64应报错cannot execute binary file: Exec format error说明是 ARM64 二进制QEMU 运行测试qemu-aarch64 ./hello-arm64输出ARM64 OK证明 binfmt 注册成功。注意qemu-aarch64命令在qemu-user-static包中但安装后需手动注册 binfmt。运行sudo cp /usr/bin/qemu-aarch64-static /usr/bin/qemu-aarch64再执行sudo update-binfmts --enable qemu-aarch64。若跳过此步./configure --hostaarch64-linux-gnu会卡在checking whether the C compiler works... no。3.3 deb 包结构设计control 文件的 7 个必填字段详解一个合法的.deb包本质是一个 ar 归档文件解压后包含debian-binary、control.tar.gz、data.tar.xz三层。其中control.tar.gz解压后核心是control文件它决定dpkg -i是否接受该包。以下是control文件中必须精确填写的 7 个字段漏填任一字段dpkg-deb --build会报错字段名示例值说明常见错误Packagemyapp包名小写字母数字连字符不能以数字开头写成MyApp或my_appdpkg 会拒绝Version1.2.3-1版本号遵循 Debian 规范上游版本-发布号1.2.3缺少发布号、1.2.3~rc1波浪线需转义Architecturearm64目标架构必须与二进制实际架构一致aarch64dpkg 只认arm64MaintainerYour Name youremail.com维护者信息邮箱必须有效邮箱格式错误如少 符号DescriptionMy awesome ARM64 app简短描述首行换行后为长描述首行为空或超过 100 字符Dependslibc6 ( 2.31), libstdc6 ( 11)运行时依赖括号内为最小版本依赖名拼错如libstdc少6Homepagehttps://github.com/you/myapp项目主页非必需但强烈建议URL 无效或协议缺失写github.com而非https://github.comcontrol文件必须用 Unix 换行符LFWindows 的 CRLF 会导致dpkg-deb解析失败。我曾因 Notepad 默认保存为 CRLF反复报错error: parsing file control: invalid field name最后用dos2unix control修复。3.4 文件系统布局规范data.tar.xz 的目录结构必须严格遵循 FHSdata.tar.xz是 deb 包的实际文件载体其内部目录结构必须符合 Linux Filesystem Hierarchy StandardFHS。常见错误是把可执行文件直接放根目录或把配置文件放错位置。正确结构如下以myapp为例/ ├── usr/ │ ├── bin/ # 用户可执行文件必须 │ │ └── myapp # chmod x │ ├── lib/ # 私有库非系统库 │ │ └── myapp/ │ │ └── libhelper.so │ └── share/ │ └── myapp/ # 数据文件、图标、文档 │ ├── icons/ │ └── doc/ └── etc/ # 系统级配置可选 └── myapp/ └── config.conf # 模板文件非实际配置关键约束所有文件路径必须以/开头绝对路径dpkg-deb --build会检查usr/bin/myapp必须有可执行权限chmod 755否则安装后command not foundetc/myapp/config.conf若存在需在control文件中声明Conffiles: /etc/myapp/config.conf否则dpkg升级时会覆盖用户修改usr/share/myapp/下的文件应为只读dpkg安装时不会修改其权限。我曾将myapp放在opt/myapp/下结果dpkg -i成功但which myapp找不到——因为/opt不在$PATH中。FHS 明确规定用户命令必须在/usr/bin或/bin。4. 实操过程与核心环节实现4.1 项目准备从源码到可编译状态假设你的项目是一个 CMake 工程目录结构如下myapp/ ├── CMakeLists.txt ├── src/ │ └── main.cpp ├── assets/ │ └── icon.png └── debian/ # deb 构建专用目录 └── control第一步在 Windows 文件系统中创建项目如D:\projects\myapp然后在 WSL2 中进入对应路径cd /mnt/d/projects/myapp。注意不要在/home/user/下创建项目否则 Windows 无法直接访问VS Code Remote-WSL 也无法挂载。CMakeLists.txt需添加 ARM64 适配段# 强制指定目标架构 if(CMAKE_SYSTEM_NAME STREQUAL Linux AND CMAKE_SYSTEM_PROCESSOR STREQUAL aarch64) set(CMAKE_C_COMPILER aarch64-linux-gnu-gcc) set(CMAKE_CXX_COMPILER aarch64-linux-gnu-g) set(CMAKE_FIND_ROOT_PATH /usr/aarch64-linux-gnu) set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER) set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY) set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY) endif()debian/control内容示例Package: myapp Version: 1.0.0-1 Architecture: arm64 Maintainer: Your Name youremail.com Depends: libc6 ( 2.31), libstdc6 ( 11) Description: A demo ARM64 application built on Windows My awesome app that runs on Raspberry Pi and Jetson. Homepage: https://github.com/you/myapp4.2 交叉编译全流程CMake Ninja 的高效组合进入项目目录后执行以下命令逐行解释# 创建构建目录避免污染源码 mkdir -p build-arm64 cd build-arm64 # 运行 CMake指定工具链和 sysroot cmake -G Ninja \ -DCMAKE_SYSTEM_NAMELinux \ -DCMAKE_SYSTEM_PROCESSORaarch64 \ -DCMAKE_C_COMPILERaarch64-linux-gnu-gcc \ -DCMAKE_CXX_COMPILERaarch64-linux-gnu-g \ -DCMAKE_FIND_ROOT_PATH/usr/aarch64-linux-gnu \ -DCMAKE_BUILD_TYPERelease \ -S .. -B . # 编译Ninja 比 Make 快 30%且并行更稳定 ninja # 验证生成的二进制确实是 ARM64 file myapp # 输出应为myapp: ELF 64-bit LSB pie executable, ARM aarch64, version 1 (SYSV), dynamically linked, ...关键参数说明-G NinjaNinja 构建系统比 Make 更快尤其在增量编译时-DCMAKE_SYSTEM_NAMELinux告诉 CMake 这是交叉编译非本机构建-DCMAKE_SYSTEM_PROCESSORaarch64明确处理器类型避免 CMake 错判为 x86_64-DCMAKE_FIND_ROOT_PATH让find_package()在指定路径下搜索库而非宿主机路径。若cmake报错Could NOT find Threads (missing: Threads_FOUND)说明pthread头文件未找到需安装libc6-dev-arm64-crosssudo apt install libc6-dev-arm64-cross。4.3 deb 包构建dpkg-deb 的四步法构建 deb 包不是简单打包而是按 Debian 标准生成三部分归档。我们采用最简可控的dpkg-deb --build方式步骤 1准备 data 目录结构# 创建临时目录存放 deb 文件内容 mkdir -p pkg/usr/bin pkg/usr/share/myapp/icons pkg/etc/myapp # 复制编译好的二进制 cp ../build-arm64/myapp pkg/usr/bin/ # 复制资源文件保持相对路径 cp -r ../assets/* pkg/usr/share/myapp/ # 设置权限 chmod 755 pkg/usr/bin/myapp chmod 644 pkg/usr/share/myapp/icons/icon.png步骤 2生成 control.tar.gz# 进入 debian 目录含 control 文件 cd ../debian # 生成 control.tar.gz必须用 gzip且文件名固定 tar -czf control.tar.gz control # 回到上层 cd ..步骤 3生成 data.tar.xz推荐 xz 压缩# 进入 pkg 目录 cd pkg # 生成 data.tar.xzxz 比 gz 压缩率高 30%dpkg 原生支持 tar -cJf ../data.tar.xz . # 回到上层 cd ..步骤 4组装 deb 包# 创建 debian-binary 文件固定内容 echo 2.0 debian-binary # 使用 dpkg-deb 组装顺序不能错 dpkg-deb --build pkg myapp_1.0.0-1_arm64.deb最终生成的myapp_1.0.0-1_arm64.deb可直接在 ARM64 设备上运行sudo dpkg -i myapp_1.0.0-1_arm64.deb。实操心得dpkg-deb --build命令要求pkg目录下不能有DEBIAN子目录这是旧版 debhelper 的遗留必须用control.tar.gzdata.tar.xz方式。若误建pkg/DEBIAN/controldpkg-deb会静默忽略并生成无效包。4.4 安装验证与问题定位dpkg -i 的 5 种典型输出解读在树莓派上执行sudo dpkg -i myapp_1.0.0-1_arm64.deb后根据输出可快速定位问题输出文本含义解决方案Selecting previously unselected package myapp.Preparing to unpack .../myapp_1.0.0-1_arm64.deb ...Unpacking myapp (1.0.0-1) ...安装正常进行无需操作dpkg: dependency problems prevent configuration of myapp:myapp depends on libstdc6 ( 11); however:Package libstdc6 is not installed.运行时依赖缺失在目标设备运行sudo apt update sudo apt install libstdc6dpkg: error processing archive myapp_1.0.0-1_arm64.deb (--install):trying to overwrite /usr/bin/myapp, which is also in package otherapp 0.9.0-1文件冲突先卸载冲突包sudo dpkg -r otherapp或修改control文件中的Conflicts: otherapp字段dpkg: error: cannot access archive myapp_1.0.0-1_arm64.deb: No such file or directory包路径错误检查文件名是否含空格或中文用 Tab 补全路径dpkg: error: parsing file /var/lib/dpkg/tmp-ci: invalid field namecontrol 文件格式错误用vim -b myapp_1.0.0-1_arm64.deb查看二进制内容定位 control.tar.gz 中的非法字符最隐蔽的问题是dpkg -i成功但程序无法运行。此时运行ldd /usr/bin/myapp若输出not a dynamic executable说明二进制是静态链接aarch64-linux-gnu-gcc -static但control文件中未声明Multi-Arch: foreign若输出libxxx.so not found则是Depends字段漏写了该库。5. 常见问题与排查技巧实录5.1 WSL2 启动失败Error code: Wsl/InstallDistro/Service/RegisterDistro/CreateVM/HCS/Error_File_N这是 Windows 11 22H2 后最常见的 WSL2 错误根本原因是 Windows Hypervisor PlatformWHPX服务未启动或被安全软件禁用。解决方案分三步检查 WHPX 状态以管理员身份运行 PowerShell执行Get-WindowsOptionalFeature -Online -FeatureName HypervisorPlatform若State为Disabled则运行Enable-WindowsOptionalFeature -Online -FeatureName HypervisorPlatform -NoRestart关闭冲突软件McAfee、Bitdefender 等安全软件会劫持 HVP临时禁用其服务重置 WSL2wsl --shutdown然后wsl --unregister Ubuntu替换为你的发行版名重新wsl --install。踩坑记录我在一台戴尔 XPS 13 上遇到此错误最终发现是 Dell Power Manager 软件启用了“Intel VT-d”功能与 WSL2 的 Hyper-V 冲突。关闭该功能后问题解决。5.2 dpkg-deb 构建时报错 “tar: Cannot connect to … : Invalid argument”此错误 99% 出现在tar -cJf data.tar.xz .命令中根源是 WSL2 对 Windows 文件系统的O_NOFOLLOW标志处理异常。解决方案所有构建操作必须在 WSL2 的 ext4 文件系统下进行即cd /home/user/myapp而非cd /mnt/d/projects/myapp。虽然前者 Windows 无法直访但可通过\\wsl$\Ubuntu\home\user\myapp访问VS Code Remote-WSL 也完全支持。5.3 生成的 deb 包在 ARM64 设备上 dpkg -i 后提示 “architecture mismatch”运行dpkg --info myapp_1.0.0-1_arm64.deb查看包信息若Architecture字段显示amd64说明control文件未被正确读取。原因通常是control.tar.gz未放在pkg/目录同级或文件名不是control.tar.gzpkg/目录下存在DEBIAN/子目录dpkg-deb优先读取该目录而非control.tar.gzcontrol文件末尾有多余空行dpkg-deb解析时截断。修复方法用ar -t myapp_1.0.0-1_arm64.deb查看包内文件列表确认control.tar.gz存在且无DEBIAN/用zcat control.tar.gz | head -n 5检查control内容是否完整。5.4 交叉编译时 configure 脚本报错 “checking whether the C compiler works… no”这不是编译器问题而是configure脚本尝试运行一个测试二进制失败。根本原因是qemu-user-static未注册或qemu-aarch64不在PATH。验证方法# 检查 binfmt 是否注册 ls /proc/sys/fs/binfmt_misc/ | grep aarch64 # 应输出 qemu-aarch64 # 检查 qemu-aarch64 是否可用 which qemu-aarch64 # 应返回 /usr/bin/qemu-aarch64 # 手动测试 echo int main(){return 0;} | aarch64-linux-gnu-gcc -x c - qemu-aarch64 ./a.out若qemu-aarch64不在PATH执行sudo ln -s /usr/bin/qemu-aarch64-static /usr/bin/qemu-aarch64。5.5 树莓派安装后程序闪退Segmentation fault (core dumped)这是 ARM64 ABI 兼容性问题。现代 ARM64 CPU 支持多种浮点 ABI如lp64和ilp32而gcc-aarch64-linux-gnu默认生成lp64二进制。若目标设备是旧版树莓派 OS如 Raspbian Buster其libc6版本过低不支持新 ABI。解决方案在CMakeLists.txt中添加set(CMAKE_EXE_LINKER_FLAGS ${CMAKE_EXE_LINKER_FLAGS} -mabilp64)或降级工具链sudo apt install gcc-10-aarch64-linux-gnu然后指定aarch64-linux-gnu-gcc-10。我曾为此花费 3 小时最终用readelf -A ./myapp | grep Tag_ABI确认 ABI 类型再对比ldd /lib/aarch64-linux-gnu/libc.so.6的 ABI 支持列表才定位到问题。6. 进阶技巧与工程化扩展6.1 自动化构建脚本一键生成多架构 deb 包当项目需同时支持arm64和amd64手动重复流程效率低下。我编写了一个build-deb.sh脚本核心逻辑如下#!/bin/bash ARCH$1 # arm64 or amd64 VERSION1.0.0-1 if [ $ARCH arm64 ]; then CCaarch64-linux-gnu-gcc CXXaarch64-linux-gnu-g SYSROOT/usr/aarch64-linux-gnu QEMUqemu-aarch64 else CCgcc CXXg SYSROOT QEMU fi mkdir -p build-$ARCH cd build-$ARCH cmake -G Ninja \ -DCMAKE_C_COMPILER$CC \ -DCMAKE_CXX_COMPILER$CXX \ -DCMAKE_FIND_ROOT_PATH$SYSROOT \ -S .. -B . ninja # 构建 deb 步骤同前文 cd .. mkdir -p pkg/usr/bin cp build-$ARCH/myapp pkg/usr/bin/ chmod 755 pkg/usr/bin/myapp # 动态生成 control 文件 sed s/Architecture:.*/Architecture: $ARCH/ debian/control debian/control.$ARCH mv debian/control.$ARCH debian/control dpkg-deb --build pkg myapp_${VERSION}_${ARCH}.deb使用方式./build-deb.sh arm64 ./build-deb.sh amd6410 秒内生成两个包。6.2 依赖自动分析用 dpkg-shlibdeps 替代手动填写 Depends手动维护Depends字段极易出错。dpkg-shlibdeps工具可自动扫描二进制依赖# 在 pkg/usr/bin/ 目录下运行 dpkg-shlibdeps -O -Tdebian/shlibs myapp debian/substvars # 生成的 substvars 文件会被 dpkg-gencontrol 读取但需注意dpkg-shlibdeps要求目标库已安装在 WSL2 中。对于 ARM64 库需先sudo apt install libstdc6-arm64-cross否则会报symbol lookup error。6.3 CI/CD 集成GitHub Actions 中复现 WSL2 构建环境GitHub Actions 的ubuntu-latestrunner 是 x64但可通过setup-qemu-action注册 QEMU- name: Setup QEMU for ARM64 uses: docker/setup-qemu-actionv2 with: platforms: arm64 - name: Install cross-compilation toolchain run: sudo apt-get update sudo apt-get install -y gcc-aarch64-linux-gnu - name: Build ARM64 deb run: | mkdir build-arm64 cd build-arm64 cmake -G Ninja -DCMAKE_SYSTEM_NAMELinux -DCMAKE_SYSTEM_PROCESSORaarch64 .. ninja # 后续 deb 构建步骤...关键点setup-qemu-action必须在apt install之前运行否则qemu-aarch64无法注册。6.4 安全加固GPG 签名 deb 包与 APT 仓库搭建生产环境必须对 deb 包签名。在 WSL2 中生成 GPG 密钥gpg --batch --full-generate-key EOF Key-Type: RSA Key-Length: 4096 Name-Real: Your Name Name-Email: youremail.com Expire-Date: 0 %no-protection EOF签名命令dpkg-sig --sign builder myapp_1.0.0-1_arm64.deb随后可将签名包上传至自建 APT 仓库用reprepro工具实现sudo apt update sudo apt install myapp的标准安装流程。我的体会在 Windows 上构建 ARM64 deb 包本质是把 Windows 的生产力优势与 Linux 的打包生态结合