前言

这两天看完了“鸿蒙 PC 三方库和命令行工具迁移实战”相关直播和配套课件，最大的感受是：以前我总觉得命令行移植是一件很玄的事情，好像只要遇到交叉编译、sysroot、triplet、签名、HNP 这些词，就会马上进入一种“能不能跑全靠运气”的状态。看完这场直播之后，我对这件事的理解终于从“跟着命令敲”变成了“知道每一步为什么要这么做”。

直播里用 pngquant 这种 PNG 压缩工具做案例，我觉得选得很好。它不是一个大到吓人的项目，但也不是单文件 hello world。它有依赖，有 configure，有 libpng、zlib，还有可选的 lcms2；它既能体现 C/C++ 三方库移植的核心问题，又不会一下子被复杂业务逻辑淹没。对第一次理解鸿蒙 PC 命令行工具移植的人来说，这个案例刚好卡在一个很舒服的位置。

可以在AtomGit视频号的直播回放中观看：https://blog.csdn.net/gao_dou/article/details/161391902?spm=1011.2124.3001.6209

真正让我有启发的点是：命令行移植不是单纯“编译出一个二进制”，而是要把工具链、依赖、签名、运行验证和交付路径都串起来。

这篇文章不是把直播课件原样搬一遍，而是按照我自己的理解重新整理一遍：为什么鸿蒙 PC 需要命令行工具移植、环境要怎么选、传统交叉编译、Lycium、vcpkg-ohos 这几条路分别适合什么情况，以及一个工具从源码到真机运行，中间到底要过哪些关。

参考资料放在前面：

• 鸿蒙 PC 开发者社区
• OpenHarmony 官网
• OpenHarmonyPCDeveloper 组织
• build_in_harmonyos 仓库
• Qt 官方 vcpkg 适配 HarmonyOS 博文
• 直播课件参考一：鸿蒙 PC 三方库移植实战
• 直播 PPT 参考二：鸿蒙 PC 三方库和命令行工具迁移实战

一、我以前对命令行移植的误解

以前看到“移植命令行工具”这几个字，我第一反应就是找源码、找编译命令、改一堆参数，然后祈祷 make 能过。这个理解其实很粗糙。直播里反复强调的一点是，鸿蒙 PC 上的命令行移植至少包含三层事情。

第一层是编译。也就是让源码用鸿蒙目标平台的工具链编译出来，而不是误用宿主机的 GCC 或系统库。第二层是依赖。很多工具看上去只有一个可执行文件，实际背后依赖 zlib、libpng、openssl、curl、ncurses 等库；依赖没处理好，编译阶段或者运行阶段都会出问题。第三层是交付和运行。鸿蒙 PC 真机上不仅要能找到动态库，还涉及 ELF 签名、运行目录、HNP/HAP 这类分发规范。

这也是我觉得直播最有价值的地方：它没有只讲“怎么把 pngquant 编出来”，而是把环境搭建、三种路线、签名、验证和提交全部放到一个完整链路里。听完以后再看命令行移植，就不再是一堆散乱命令，而是一条可以复盘、可以沉淀、可以交给别人继续做的流程。

二、为什么案例选 pngquant 很合适

pngquant 是一个 PNG 图片压缩工具，使用场景很直观：输入一张 PNG 图片，输出压缩后的图片。它的验证方式也很直观，运行 pngquant --version 能看到版本，压缩图片后能比较文件大小，也能肉眼看图片质量有没有明显损失。

但它又不是一个过于简单的项目。pngquant 自身是 C 项目，构建方式不是标准 CMake，而是自写 configure；它依赖 libpng，libpng 又依赖 zlib；如果启用颜色管理，还会涉及 lcms2。这样一个项目非常适合拿来讲“真实三方库移植”，因为它刚好会遇到依赖路径、pkg-config、交叉编译检测、SSE 关闭、动态库签名这些典型问题。

维度	pngquant 的特点	对移植学习的价值
语言	C	能直接观察编译器、链接器、sysroot 的影响
构建系统	自写 configure	能看到 configure 误判目标平台时怎么处理
依赖	libpng、zlib、可选 lcms2	能练习依赖链和 pkg-config 路径
功能验证	压缩 PNG 图片	结果容易验证，不是只看命令是否退出
平台问题	SSE、签名、动态库路径	能覆盖鸿蒙 PC 移植的常见坑

所以，pngquant 不是为了演示“最简单能跑”，而是为了演示“一类真实命令行工具应该怎么移植”。这点我觉得很重要，因为真正有价值的学习不是记住某一个项目的命令，而是知道下一次换成 curl、tree、ffmpeg 或别的库时，应该从哪里下手。

三、环境选择：不要一开始就把自己困在本机上

直播里给了几种环境选择：Windows 宿主、WSL、云服务器、鸿蒙 PC 真机、Docker 鸿蒙容器。看完以后我最大的判断是，开发阶段最好先选一个自己能稳定控制的 Linux 类环境，比如 WSL 或云服务器；真机更适合做最终验证；Docker 容器可以作为低成本替代验证环境。

3.1 WSL 或 Linux 云机适合做主要编译环境

如果是在 Windows 电脑上开发，WSL 是一个非常自然的选择。CMake、make、git、pkg-config、ninja、automake 这些工具在 Linux 环境下资料最多，脚本兼容性也更好。直播里也提到，很多编译脚本建议放到 WSL 或 Linux 执行，少踩路径分隔符和 shell 差异的坑。

sudo apt update
sudo apt install -y python3 python3-pip git cmake ninja-build make pkg-config automake libtool
sudo update-alternatives --install /usr/bin/python python /usr/bin/python3 1

这段命令做的是基础编译环境准备。python3 和 python3-pip 常用于构建脚本、工具链脚本或自动化框架；git 用来拉源码和补丁；cmake、ninja-build、make 覆盖常见构建系统；pkg-config 用来定位依赖库的头文件和链接参数；automake、libtool 则经常出现在传统 C/C++ 项目里。最后一行把 python 指向 python3，是为了兼容一些老脚本里直接调用 python 的情况。

3.2 SDK 路径要先确认，不要等 configure 报错再猜

鸿蒙交叉编译离不开 SDK，尤其是 native 工具链和 sysroot。如果 SDK 解压不完整，或者环境变量指错目录，后面遇到的错误会非常绕。

export OHOS_SDK_ROOT=/root/ohos-sdk/linux
ls $OHOS_SDK_ROOT/native/build/cmake/ohos.toolchain.cmake
ls $OHOS_SDK_ROOT/native/llvm/bin/clang
ls $OHOS_SDK_ROOT/native/sysroot

这里检查的是三个关键位置。ohos.toolchain.cmake 说明 CMake 交叉编译入口存在；native/llvm/bin/clang 说明鸿蒙目标工具链存在；native/sysroot 说明目标系统的头文件和库目录存在。很多“C compiler cannot create executables”这类错误，最后追下来其实不是源码问题，而是工具链或 sysroot 路径不对。

3.3 真机验证不是可选项

能在 Linux 编译出来，不等于能在鸿蒙 PC 上运行。鸿蒙真机上还会遇到签名、动态库路径、权限和运行目录等问题。直播里提到的一个重点是，可执行文件和动态库都可能需要签名，这一点如果没提前知道，很容易卡在“明明文件在，为什么运行不了”。

hdc file send ./pngquant /data/local/tmp/
hdc shell
cd /data/local/tmp
chmod +x pngquant
./pngquant --version

这一组命令是最小真机验证链路。先通过 hdc file send 把编译好的产物推到设备，再进入 shell，到目标目录后加执行权限并运行版本命令。这里的意义不是只看版本号，而是确认三个事实：文件能被设备识别，执行权限没有问题，运行时没有立即因为平台或依赖问题退出。

四、路线一：直接交叉编译，最能理解底层逻辑

直接交叉编译是最原始也最能帮助理解本质的方式。它适合依赖很少的小项目，也适合教学演示。因为你需要自己明确告诉项目：目标平台是谁，编译器在哪里，sysroot 在哪里，链接器用什么，额外宏定义是什么。

下面这组环境变量就是理解鸿蒙命令行移植的基础。

export OHOS_SDK="/root/ohos-sdk/linux"
export COMPILER_TOOLCHAIN="$OHOS_SDK/native/llvm/bin"
export SYSROOT="$OHOS_SDK/native/sysroot"
export TARGET="aarch64-linux-ohos"

export CC="$COMPILER_TOOLCHAIN/clang"
export CXX="$COMPILER_TOOLCHAIN/clang++"
export AR="$COMPILER_TOOLCHAIN/llvm-ar"
export LD="$COMPILER_TOOLCHAIN/ld.lld"
export NM="$COMPILER_TOOLCHAIN/llvm-nm"
export RANLIB="$COMPILER_TOOLCHAIN/llvm-ranlib"
export STRIP="$COMPILER_TOOLCHAIN/llvm-strip"

这段环境变量把“宿主机编译”切换成了“面向鸿蒙目标平台的交叉编译”。OHOS_SDK 是 SDK 根路径，COMPILER_TOOLCHAIN 指向 LLVM 工具链，SYSROOT 指向目标系统的头文件和库，TARGET 表示目标三元组。下面的 CC、CXX、AR、LD 等变量则把传统构建系统里常用的工具名全部换成鸿蒙 SDK 里的 LLVM 工具。这样 configure 或 make 在调用编译器时，就不会误用宿主机的 GCC。

对于 configure 项目，核心是把 target、sysroot、cflags 和 ldflags 讲清楚。

./configure \
  --host=aarch64-unknown-linux-musl \
  --with-sysroot="$SYSROOT" \
  CC="$CC --target=$TARGET --sysroot=$SYSROOT" \
  CXX="$CXX --target=$TARGET --sysroot=$SYSROOT" \
  CFLAGS="-fPIC -D__OHOS__ -D__MUSL__=1" \
  LDFLAGS="--target=$TARGET --sysroot=$SYSROOT -fuse-ld=lld"

这段命令的重点是让 configure 不再按宿主机环境做判断。--host 告诉构建系统目标环境接近 aarch64 musl；--with-sysroot 把依赖搜索范围指向鸿蒙 sysroot；CC 和 CXX 不只是传 clang 路径，还附加了 --target 和 --sysroot；CFLAGS 里加 -fPIC 适配动态库和位置无关代码，-D__OHOS__、-D__MUSL__=1 用来让源码里的平台分支能识别当前环境；LDFLAGS 则指定目标、sysroot 和 lld 链接器。

直接交叉编译的优点是透明，哪里错了基本都能追到底。缺点也很明显：依赖一多，脚本就会变复杂。FFmpeg 这种大型项目就会遇到非常多开关，比如关闭 Vulkan、关闭 libdrm、关闭 ffplay、处理共享库、处理 pkg-config 路径等。它适合用来建立理解，但不一定适合长期大规模维护。

五、路线二：Lycium / lycium_plusplus，更贴近鸿蒙生态

Lycium 或 lycium_plusplus 的价值，在于它把三方库移植里的很多固定动作抽象成了配方。直播里把 HPKBUILD 类比成一种类似 Arch Linux PKGBUILD 的脚本，这个比喻很容易理解：你不再每次手写完整编译流程，而是为某个三方库写一份“它怎么准备、怎么构建、怎么安装、依赖谁”的说明。

对 pngquant 来说，Lycium 方案的关键点主要是依赖链、pkg-config 路径和 SSE。

git clone https://atomgit.com/OpenHarmonyPCDeveloper/lycium_plusplus.git
cd lycium_plusplus
./build.sh zlib libpng lcms2
./build.sh pngquant
find lycium/usr -name "pngquant"

这组命令体现的是 Lycium 的构建方式。先克隆框架，再进入仓库，先构建 pngquant 依赖的 zlib、libpng、lcms2，最后构建 pngquant 本身。find 用来确认产物位置。和直接交叉编译相比，这里用户不再每次手动配置完整工具链参数，而是把参数交给框架，把项目差异写进 HPKBUILD。

HPKBUILD 的核心思想可以简化成下面这样。

pkgname="pngquant"
pkgver="2.18.0"
depends=("libpng" "zlib" "lcms2")
makedepends=("git")

build() {
    export PKG_CONFIG_LIBDIR="${pkgconfigpath}"

    ./configure "$@" \
        --with-libpng="${pngroot}" \
        --with-lcms2="${lcms2root}" \
        --disable-sse \
        --extra-cflags="${extra_cflags}" \
        --extra-ldflags="${extra_ldflags}"

    make -j$(nproc) V=1
}

package() {
    make DESTDIR="${pkgdir}" install
}

这段 HPKBUILD 里有几个点特别关键。depends 写的是三方库依赖，框架会据此处理依赖构建顺序；makedepends 写的是构建过程需要的命令，比如 git。PKG_CONFIG_LIBDIR 必须 export，因为 configure 需要通过 pkg-config 找到交叉编译后的依赖库，而不是宿主机 /usr/lib 里的库。"$@" 用来承接框架传入的安装前缀和目标参数。--disable-sse 对 ARM 目标非常重要，因为 SSE 是 x86 相关优化，交叉编译时如果误检，会导致后续编译或运行出现问题。package 阶段使用 DESTDIR，方便框架把产物收集到统一目录。

我对 Lycium 的理解是：它适合做鸿蒙生态里的“规范化移植”。如果目标是给社区贡献三方库、沉淀可复现脚本、形成可以审查的构建配方，Lycium 这种方式比自己散写 shell 脚本更合适。

六、路线三：vcpkg-ohos，适合已经熟悉 CMake 生态的人

vcpkg-ohos 这条路线让我印象也很深。Qt 团队在官方博文里提到，他们为了 HarmonyOS 构建第三方库，对 vcpkg 做了适配。对于 CMake 工程、Qt 相关工程，或者本来就熟悉 vcpkg 的开发者来说，这条路的吸引力很明显：通过 triplet 指定目标平台，然后用 vcpkg install 安装库。

export VCPKG_ROOT=~/vcpkg
export OHOS_SDK_ROOT=/root/ohos-sdk/linux

$VCPKG_ROOT/vcpkg install pngquant:arm64-ohos
$VCPKG_ROOT/vcpkg install 'pngquant[core]:arm64-ohos'
find $VCPKG_ROOT/installed -name "pngquant"

这里的重点是 arm64-ohos 这个 triplet。它告诉 vcpkg 当前目标是鸿蒙 ARM64 平台。第一条安装完整 pngquant，第二条使用 feature 裁剪，只安装 core，去掉一些可选能力。find 用来确认产物安装到了 vcpkg 的 installed 目录下。和 Lycium 相比，vcpkg 的使用体验更接近通用 C/C++ 包管理；和直接交叉编译相比，它把依赖下载、构建顺序、CMake 集成做了更多封装。

如果是自己的 CMake 工程想使用 vcpkg 里的库，可以这样接入。

cmake -S . -B build \
  -DCMAKE_TOOLCHAIN_FILE=$VCPKG_ROOT/scripts/buildsystems/vcpkg.cmake \
  -DVCPKG_TARGET_TRIPLET=arm64-ohos

这段命令的含义是让 CMake 使用 vcpkg 的工具链文件，并且指定目标 triplet 为 arm64-ohos。这样 CMake 在 find_package 时就会去 vcpkg 为鸿蒙目标构建出来的目录里找库，而不是去宿主机系统路径里找。对 CMake 工程来说，这一点非常重要，否则很容易出现“编译通过了，但链接的是宿主机库”的假成功。

在 CMakeLists.txt 里可以继续写正常的包查找和链接逻辑。

find_package(PNG CONFIG REQUIRED)
target_link_libraries(myapp PRIVATE PNG::PNG)

这两行看起来很普通，但它们背后的前提是 vcpkg triplet 和 toolchain 已经配置正确。find_package(PNG CONFIG REQUIRED) 会寻找 libpng 的 CMake 配置，target_link_libraries 则把 PNG 库链接到目标程序里。只要工具链指向正确，这套写法就能保持跨平台工程的整洁，不必在业务工程里到处写鸿蒙专用路径。

vcpkg-ohos 的缺点是 fork 还处在生态过渡阶段，遇到 GitHub 下载慢、portfile 不完整、OpenSSL 汇编选项、zip 缺失、SDK 路径识别失败等问题时，仍然需要开发者懂一些底层知识。但它的方向很清晰：让鸿蒙三方库移植尽量进入已有 C/C++ 包管理生态。

七、签名：能编译出来，不代表能在真机上跑

直播里我觉得最容易被初学者忽略的地方就是签名。我们平时在 Linux 上编译一个命令行工具，chmod +x 后基本就能跑；但鸿蒙 PC 真机有安全策略，可执行文件和动态库都可能需要签名。

$OHOS_SDK/toolchains/lib/binary-sign-tool sign \
  -inFile pngquant \
  -outFile pngquant \
  -selfSign "1"

chmod +x pngquant

这段命令用 SDK 里的 binary-sign-tool 对可执行文件进行自签名。-inFile 是输入文件，-outFile 是输出文件；这里输入输出写成同一个文件，表示原地覆盖签名。-selfSign "1" 表示使用自签名方式。签名后还要用 chmod +x 确保执行权限存在。很多运行时报 Permission denied 或者无声退出的问题，都可能和签名有关。

如果工具依赖动态库，库也要处理。

$OHOS_SDK/toolchains/lib/binary-sign-tool sign \
  -inFile libpng16.so \
  -outFile libpng16.so \
  -selfSign "1"

$OHOS_SDK/toolchains/lib/binary-sign-tool sign \
  -inFile libz.so \
  -outFile libz.so \
  -selfSign "1"

这两段命令分别对 libpng16.so 和 libz.so 签名。这里最重要的不是命令本身，而是意识：不要只签可执行文件。如果可执行文件已经签了，但它运行时加载的 .so 没签，仍然可能失败。验证时也要同时关注 LD_LIBRARY_PATH、当前工作目录、rpath 和依赖库是否都在设备上。

八、验证：我现在会按四步检查

看完直播后，我对“验证成功”的标准也变严格了。以前可能看到编译没报错就觉得成功了，现在会至少按四步走。

第一步，看产物架构。

$OHOS_SDK_ROOT/native/llvm/bin/llvm-readelf -h ./pngquant

这条命令用 LLVM 的 readelf 查看 ELF 头信息。它能确认产物是不是目标架构，比如 AArch64，而不是误编成宿主机 x86_64。这个检查应该尽早做，因为如果架构错了，后面推真机、签名、设置库路径都没有意义。

第二步，看动态库依赖。

$OHOS_SDK_ROOT/native/llvm/bin/llvm-readelf -d ./pngquant

这里查看的是动态段信息，重点关注 NEEDED 条目，也就是运行时需要加载哪些 .so。如果能提前知道依赖了 libpng16.so、libz.so 或其他库，就可以在推送真机时一起带上，并且提前安排签名和 LD_LIBRARY_PATH。

第三步，推送到设备并设置库路径。

hdc file send ./pngquant /data/local/tmp/
hdc file send ./libpng16.so /data/local/tmp/
hdc file send ./libz.so /data/local/tmp/

hdc shell
cd /data/local/tmp
export LD_LIBRARY_PATH=/data/local/tmp
./pngquant --version

这组命令是完整的真机最小验证。先推送可执行文件和动态库，再进入设备 shell，把当前目录切到 /data/local/tmp，设置 LD_LIBRARY_PATH 让运行时能找到本地动态库，最后执行版本命令。这里如果失败，就可以根据错误信息判断是文件没权限、库没找到、架构不对、没签名，还是程序自身适配问题。

第四步，做真实功能测试。

./pngquant --quality=60-80 sample.png --output=compressed.png
ls -lh sample.png compressed.png

版本号能输出只能证明程序启动了，不能证明功能真的可用。用 pngquant 压缩一张样图，再通过 ls -lh 对比压缩前后文件大小，才更接近真实验收。实际提交社区或团队时，最好再补上日志、截图或测试说明，说明压缩结果、图片质量和运行环境。

九、几种方案怎么选

直播里列了多种路径，我整理成自己更容易记住的判断方式。

路线	我理解的核心	适合场景	主要风险
直接交叉编译	手动控制工具链和 flags	小项目、教学、排查底层问题	依赖一多脚本难维护
Lycium / lycium_plusplus	用 HPKBUILD 沉淀移植配方	鸿蒙生态三方库贡献、规范化构建	需要理解框架约定
vcpkg-ohos	用 triplet 和 port 管理依赖	CMake、Qt、通用 C/C++ 包管理场景	fork 适配期，port 可能要修
build 脚手架	dependency.json + build.sh	团队统一构建和 HNP 交付	需要维护组织内规范
build_in_harmonyos	自动化框架 + 经验库	批量迁移、持续沉淀错误模式	仍需人工核对和干净构建

我的结论是：第一次学习时，应该先理解直接交叉编译；真正做生态贡献时，可以优先看 Lycium；如果项目本身就在 CMake/vcpkg 生态里，可以研究 vcpkg-ohos；如果是团队长期批量迁移，就应该把脚手架和自动化框架也纳入考虑。

十、AI 可以帮忙，但不能替代验证

直播里提到 AI 辅助排错，我很认同。现在把一段 configure 报错、链接错误、portfile 片段发给 AI，让它帮忙分析原因，确实能节省很多时间。但 AI 的价值更像“加速定位”，不是“替代验收”。

我自己会把问题尽量按下面的信息格式整理给 AI：

1. 当前目标平台：arm64-ohos
2. 使用路线：Lycium / vcpkg-ohos / 直接交叉编译
3. OHOS_SDK_ROOT 路径：/root/ohos-sdk/linux
4. 失败阶段：configure / make / link / run
5. 完整错误日志：从命令开始到错误结束
6. 当前脚本片段：configure flags 或 HPKBUILD / portfile

这段不是命令，而是提问模板。它的作用是避免只给 AI 一句“编译失败了怎么办”。交叉编译问题通常高度依赖环境变量、目标架构、工具链路径和完整报错。如果只贴最后一行 error，很可能得到泛泛回答；把上下文补全以后，AI 才更容易判断是 sysroot、pkg-config、host triplet、链接器，还是目标平台宏的问题。

但最终还是要回到本地验证。尤其要检查这几件事：是否误链到宿主机 /usr/lib；PKG_CONFIG_LIBDIR 是否指向目标依赖；DESTDIR 和安装前缀是否正确；ELF 是否签名；动态库是否和可执行文件一起带到设备上；真机是否跑过真实命令。

十一、这场直播让我真正记住的几个点

第一，命令行移植的目标不是“make 成功”，而是“可复现地构建、可解释地交付、可验证地运行”。如果只是本地临时编出来一个文件，但没人知道 SDK 版本、依赖版本、补丁内容和签名方式，这个结果很难沉淀。

第二，依赖路径比源码改动更容易出问题。很多时候源码没错，是 pkg-config 找到了宿主机库，或者 configure 用宿主机能力做了检测。交叉编译最怕“看起来成功”，实际混入了错误环境。

第三，鸿蒙 PC 的运行验证必须把签名和库加载路径算进去。可执行文件、动态库、LD_LIBRARY_PATH、rpath、HNP/HAP 规范，这些都不是编译之后才随便补一下的小事，而是交付链路的一部分。

第四，社区生态需要的是可复用经验。一个人把一个库编过了，只是个人经验；把 HPKBUILD、portfile、patch、日志、验证说明和提交记录整理好，才是生态贡献。

十二、我会怎么开始自己的第一次移植

如果让我现在从零开始移植一个简单命令行工具，我会按下面这个顺序走。

1. 先确认项目语言、构建系统和依赖，不急着编译。
2. 准备 WSL 或 Linux 云机，安装基础构建工具。
3. 下载并确认 OHOS SDK，检查 ohos.toolchain.cmake、clang 和 sysroot。
4. 如果项目很小，先用直接交叉编译跑通理解。
5. 如果要提交社区，整理成 Lycium HPKBUILD 或 vcpkg port。
6. 编译后用 readelf 检查架构和依赖。
7. 对可执行文件和动态库签名。
8. 推到真机或容器里运行版本命令。
9. 做真实功能测试。
10. 把补丁、脚本、日志、验证结果整理进提交说明。

这个流程看起来比“敲一个 make”麻烦，但它更可靠。尤其是面向鸿蒙 PC 生态建设时，真正重要的不是某一次刚好成功，而是下一次换人、换机器、换 SDK 后仍然能复现。

总结

这场直播让我最大的收获，是终于把“命令行移植”拆成了几个可以理解的部分：环境、工具链、依赖、构建系统、签名、验证和交付。以前看到 configure 报错，我可能只会到处搜错误信息；现在会先问自己：目标三元组对不对，sysroot 对不对，pkg-config 找的是不是目标库，动态库有没有签名，真机运行环境有没有准备好。

pngquant 只是一个案例，但它把很多核心问题都串起来了。通过这个案例，我能更清楚地理解为什么鸿蒙 PC 生态需要三方库移植，也能理解为什么社区要同时提供 Lycium、vcpkg-ohos、build 脚手架和 build_in_harmonyos 这类工具。它们不是互相替代，而是在不同场景下解决同一个目标：让更多 C/C++ 工具和库，以可复现、可维护、可验证的方式进入鸿蒙 PC。

如果只用一句话总结这次学习，那就是：

能编译只是开始，能签名运行、能验证功能、能沉淀脚本和经验，才算真正完成一次命令行工具移植。

---

相关资源

• 鸿蒙 PC 开发者社区
• OpenHarmony 官网
• OpenHarmonyPCDeveloper 组织
• build_in_harmonyos 仓库
• Qt 官方：Building libraries for HarmonyOS with vcpkg
• 参考直播教案：鸿蒙 PC 三方库移植实战
• 参考直播 PPT：鸿蒙 PC 三方库和命令行工具迁移实战

版权说明

本文为观看直播和阅读公开课件后的学习复盘与实践理解整理，参考资料来自 CSDN 博主「特立独行的猫a」发布的鸿蒙 PC 三方库移植直播教案与直播 PPT。原始资料遵循 CC 4.0 BY-SA 协议，转载请保留原始链接与协议说明。