凌晨 2 点，我在鸿蒙 PC 上跑通了 LiteIDE——一个 Go 老兵的私心移植记

欢迎加入开源鸿蒙 PC 社区：https://harmonypc.csdn.net/

这是我适配鸿蒙 PC 的第 8 个开源工具。

也是第一个让我编译过程中翻出一张八年前的旧照片的工具。

---

写在前面：先说一句话

LiteIDE 这个名字，听过的人不多。

它是 visualfc 写的、专给 Go 语言用的轻量级 IDE，GitHub 7.5k stars，最早一版是 2011 年发布的。比 GoLand 早 4 年，比 VS Code 的 Go 插件早 5 年。

Go 语言早期的一批中国开发者，几乎都是用 LiteIDE 上手的——也包括我。

所以我做这个适配不是因为它有多火，是因为它陪我走过一段我自己都快忘了的路。

---

一、为什么是 LiteIDE：从一张 2017 年的截图说起

我适配项目通常都有个"由头"——

工具	由头
DiffPDF	那天客户发新版合同，鸿蒙 PC 应用市场没有 PDF 对比工具
KDiff3	想用纯文本 diff 看一份配置改动
nomacs	翻女儿满月那天拍的一千多张照片
glogg	客户发来 200 MB 服务器日志

LiteIDE 的由头有点不一样。

某个周三晚上我在鸿蒙 PC 上想写个 Go 小工具——把仓库里 4000 多个文件按修改时间分组，做个统计。30 行 Go 代码就能写完的小活。

但我打开鸿蒙 PC 找 IDE 的时候卡住了：

• VS Code 没有鸿蒙版（虽然我不太喜欢用它写 Go）
• GoLand 没有鸿蒙版
• 应用市场搜"Go"出来一堆"围棋"和"出行" App
• 装 vim 的话，配 vim-go + LSP 调通至少要一个晚上

我就坐在那儿翻文件夹，忽然在一个叫 老电脑备份/2017截图/ 的目录里看到一张老截图——

那是 2017 年我第一份正经工作时的桌面。窗口里开着的，是 LiteIDE。我在写公司一个 Go 的 RPC 服务。截图右下角的时间是 23:47。

那是我第一次写 Go 代码的工具。8 年前。

我把那张截图发到当年的部门群里。已经离职的老同事回了一句：“靠，这玩意还有人用？”

那一刻我决定，下一个适配的工具就它了。

---

二、动手前的那点犹豫

说实话，我犹豫过。

LiteIDE 是 qmake 项目——前面 7 个适配的工具全是 CMake。我对 qmake 不熟，最后一次写 .pro 文件还是 2018 年。

而且它是插件架构。我提前用 recon_liteide.sh 扫了一遍，发现：

[recon] 顶层：liteidex.pro → src.pro
[recon] src.pro SUBDIRS：api 3rdparty utils liteapp plugins liteide
[recon] 插件数量：30+ 个（plugins/ 子目录）
[recon] main 入口：src/liteide/main.cpp → cdrv_main(argc, argv)

30 多个插件。每个插件单独编译成 .so。

我之前适配的 IronLog 是 2800 行自研代码，DiffPDF 是几个 cpp 文件。LiteIDE 是 25 万行 C++。

我当时想：要不算了？换个简单的下次再做？

但我又翻回那张 2017 年的截图看了一眼。

算了，做吧。

---

三、第一晚：qmake 让我重新认识"工具链不齐"是什么意思

周五下班我开了瓶啤酒，决定就今晚搞定它。

结果搞到了凌晨 2 点 49 分。

CMake 项目踩过的那些坑，qmake 上一个都没少，还多了 3 个 qmake 独有的：

坑 #1：host qmake 5.15 和 target Qt-OHOS 5.12.12 版本错配

服务器装的系统 qmake 是 Qt 5.15 的，Qt-OHOS 是 5.12.12。

CMake 项目我们可以用 find_package(Qt5 PATHS ...) 强制指定路径。qmake 不行——它读自己自带的 mkspecs，然后去 /usr/include/qt5/ 找头文件，去 /usr/lib64/ 找库。

结果就是：我编译出来的 Makefile 链接的全是服务器上的 x86_64 Qt5 库。点编译，链接器直接报：

ld: /usr/lib64/libQt5Core.so: file format not recognized

——它在用 x86_64 的 Qt 库去链 arm64 的目标，能识别才有鬼了。

凌晨 12 点 14 分，我盯着这个报错喝完了第一瓶啤酒。

坑 #2：1256 个头文件符号链接

折腾到一点钟我才搞明白——Qt-OHOS 的 include 目录结构和标准 Qt 不一样。

标准 Qt（macOS / Linux）的 include 是平的：

include/
  QWidget          ← 直接在这
  QString
  QtCore           ← 这个是目录

Qt-OHOS 的 include 是分模块的，没有最顶层那批无后缀文件：

include/
  QtCore/QString   ← 只有这个
  QtWidgets/QWidget
  （没有顶层的 QWidget）

LiteIDE 源码里 #include <QWidget> 这种写法到处都是。编译器找不到。

解决方案是写个 Python 脚本，把所有子目录里的 Q* 文件全部 symlink 到顶层：

import pathlib
inc = pathlib.Path("/opt/qt-ohos/.../include")
for mod in inc.iterdir():
    if mod.is_dir() and mod.name.startswith("Qt"):
        for f in mod.iterdir():
            if f.is_file() and f.name.startswith("Q") and "." not in f.name:
                (inc / f.name).symlink_to(f)
# 创建了 1256 个符号链接

1256 个。

我跑完这个脚本看到这个数字的时候，是凌晨 1 点 23 分。我又开了一瓶啤酒。

坑 #3：musl libc 没有 utmpx

凌晨 1 点 40 分，编译跑了 80% 的时候挂在一个第三方库 ptyqt 上：

// 3rdparty/ptyqt/core/unixptyprocess.cpp
#if !defined(Q_OS_ANDROID) && !defined(Q_OS_BSD4)
#include <utmpx.h>   // ← OHOS 这里没有
#endif

OHOS 用 musl libc，musl 没有 utmpx。这个是 glibc 才有的"已登录用户记录"接口。

修复很简单：

#if !defined(Q_OS_ANDROID) && !defined(Q_OS_BSD4) && !defined(__MUSL__)

但找到这一行用了 40 分钟——因为编译器报错只说"找不到 utmpx.h"，我以为是哪个 Qt 模块缺了，翻了半小时 .pro 文件。

后来我打开 LiteIDE 源码搜 utmpx，整个项目就一处引用。那一刻我有点想笑。

凌晨 2 点 49 分

26 个 .so 全部编译成功的瞬间，终端最后一行打印的是：

[100%] Linking liteideterminalplugin.so ... done.

我看了眼时间：02:49。

打开手机想发个朋友圈，又把手机放回去了——这种事发出来别人也看不懂。

我就坐在书房，听见客厅墙上那个老挂钟咔嗒咔嗒响。看了那个 02:49 大概一分钟，然后开始写第二天要打的"部署到 MateBook"的脚本。

---

四、第二天：第一次在鸿蒙 PC 上看到那个老朋友

第二天我睡到中午。

起来给自己煮了个泡面，等水烧开的时候把昨晚的 HAP 装进 MateBook Pro。

hdc install 那个小进度条走完。

我点开桌面图标。

LiteIDE 的启动画面跳出来——和 2017 年那张截图里的一模一样。同样的 logo、同样的字体、同样的灰色背景。

我手是抖的。

新建一个 Go 文件，把昨晚那个统计仓库文件的 30 行代码敲进去：

package main

import (
    "fmt"
    "os"
    "path/filepath"
    "time"
)

func main() {
    counts := map[string]int{}
    filepath.Walk(".", func(p string, info os.FileInfo, err error) error {
        if err != nil { return nil }
        key := info.ModTime().Format("2006-01")
        counts[key]++
        return nil
    })
    for k, v := range counts {
        fmt.Printf("%s: %d files\n", k, v)
    }
}

按 F5（这是 LiteIDE 的运行快捷键，我没忘）。

控制台滚出输出：

2024-08: 127 files
2024-09: 89 files
...
2025-12: 410 files
2026-06: 312 files

我端着泡面碗站在书桌前，看了这个输出大概 20 秒。

8 年。

8 年前我在公司用 LiteIDE 写第一个 Go 服务。8 年后我用我自己适配的 LiteIDE 在自己家的鸿蒙 PC 上跑了个统计脚本。中间隔着无数个用 GoLand、用 VS Code、用 vim 的瞬间。

但那个最老的工具，第一次，在国产桌面系统上回来了。

我不知道怎么形容那种感觉。不是技术成就感，不是"我又干完一个项目"。

更像是——把一段自己以为已经丢掉的东西，亲手捡回来了。

---

五、做 LiteIDE 这件事让我想明白一些事

这是我适配的第 8 个工具，但是第一个让我**做完之后反复想"为什么我要做这个"**的工具。

前 7 个工具的逻辑很清楚——我每天用，鸿蒙 PC 上没有，我就做。是一种"私人补丁"的逻辑。

LiteIDE 不是。我现在每天写 Go 用 GoLand，不用 LiteIDE 已经 5 年了。

那我为什么做？

想了几天，我有了答案：

5.1 鸿蒙 PC 需要"工具的代际延续"，不只是"工具的种类齐全"

一个新桌面系统要被开发者接受，不是看它能不能装 VS Code——VS Code 大家都装得上，但那只能让 VS Code 用户来。

真正能让人"愿意搬过来"的，是他过去 10 年用过的那些工具都还在。

我用 LiteIDE 写过 Go 服务、用 KDiff3 改过合同、用 nomacs 翻过孩子照片、用 glogg 看过深夜的崩溃日志——这些不是 10 个工具，是 10 段我过去 15 年的工作和生活。

鸿蒙 PC 如果不能把这些都端过来，它对我来说就是个"漂亮的二号设备"，不是"主力机"。

我做 LiteIDE 的那一刻，我意识到我其实在做的事——是把我自己的 10 年职业生涯，往鸿蒙 PC 上搬一遍。

5.2 鸿蒙 PC 真正缺的是"小众工具的生态位"

App Store 永远不会缺 Microsoft Office、不会缺 Adobe 全家桶。这些是商业公司，鸿蒙 PC 起来之后他们一定会来。

真正缺的是 LiteIDE 这种 7k stars、作者还是义务维护的"小众但忠实"的工具。

这种工具：

• 商业公司不会做（用户太少不挣钱）
• 上游作者一般不会主动适配（适配成本对他来说太高）
• 但它们的用户黏性极强——你看那些到现在还在用 LiteIDE 写 Go 的人，问他换 GoLand？他多半会摆摆手

这种小众但忠实的工具，单个看微不足道，加在一起就是"一个生态有没有人气"的判定标准。

iPhone 不是靠 Adobe Photoshop 起来的，是靠一万个"我在地铁上玩了 5 年"的小游戏起来的。鸿蒙 PC 起来也得靠类似的东西。

5.3 做适配最有价值的部分不是代码

我适配 LiteIDE 那个晚上写的代码——其实真正算"我写的代码"也就改了 5 个 .pro 文件 + 1 个 cpp 的 utmpx 判断。

但搞清楚 qmake 怎么和 ohos-clang 对接、qmake.conf 怎么覆盖、wrapper 脚本怎么写、1256 个符号链接为什么需要、host vs target Qt 版本错配的根本原因——

这些方法论才是这次适配最大的产物。

下一个想适配 qmake 项目的开发者，他不用熬到凌晨 2 点 49 分了。他照着我那篇博客走，3 小时能跑通。

我做 8 个适配，越往后越快。第一个 DiffPDF 用了 17 小时。第八个 LiteIDE 26 个 .so 这么复杂的项目，从源码下载到 HAP 跑起来用了11 小时——其中至少 4 小时是在打字写博客记录每一步。

如果有 100 个开发者都像这样把自己撞过的墙记下来，鸿蒙 PC 的"工具荒"就解决了一大半。

---

六、我对鸿蒙 PC 的期望

写到这里就快聊到尾声了。我把对鸿蒙 PC 的期望分成三档：

短期：希望它别把开发者门槛抬太高

我适配 LiteIDE 那个周末熬到凌晨 2 点 49 分，其中有 1 个半小时是在调签名、改 bundleName、加 UDID。这部分本来可以不浪费的。

希望短期内：

• 签名能简化（个人开发者本机调试免签）
• 工具链能开箱即用（不要让 Linux 开发者还要自己软链 host 工具）
• 文档能把"踩坑"那部分也写进去

中期：希望"我每天用的工具"都能在上面

这是我个人正在用 11 个工具的适配在做的事。希望其他开发者也来做——

不为别的，就为了你自己以后能用得舒服。

你现在 Mac 上 Dock 里有什么？把它搬过来。一个开发者搬 1 个，1000 个开发者就是 1000 个工具。

长期：希望它成为"第三种活下来的桌面操作系统"

Windows 35 年了，macOS 23 年了。这中间无数次有人想做"第三种"——BeOS、OS/2、各种 Linux 桌面发行版——全失败了。

鸿蒙 PC 是过去 20 年里最有可能成功的"第三种"——因为它一上来就有华为这个体量、有国产替代的政策窗口、有从手机生态往 PC 反哺的可能性。

但**“可能"不是"必然”**。它能不能成，取决于像我这种用户愿不愿意陪它走过最难的两三年。

我打算陪它走。所以我把 LiteIDE 搬过来了。下个周末我准备搬第 9 个工具。

---

七、最后一句

如果你也是一个老开发者，你电脑里一定有某个"陪你走过一段路"的工具。

可能是 vim。可能是 Sublime Text。可能是 IntelliJ 的某个老版本。可能是某个只有作者一个人维护的命令行小工具。

如果你愿意花一个周末把它搬到鸿蒙 PC 上——欢迎来 https://harmonypc.csdn.net/ 一起。

不为别的，就为了你以后能在国产的电脑上，继续用那个陪你长大的工具。