给鸿蒙 PC 的一封建议——做了 11 个适配项目之后，我想说说哪些地方还能更好
给鸿蒙 PC 的一封建议——做了 11 个适配项目之后，我想说说哪些地方还能更好
欢迎加入开源鸿蒙 PC 社区：https://harmonypc.csdn.net/
这是一个在鸿蒙 PC 上手工适配了 10 个 Qt 开源软件 + 1 个 Electron Demo 的工程师，把自己一路撞过的墙整理出来——给设计这个系统的人，也给打算在这上面做事的人，做一个参考。
写在前面
先把底牌亮出来，免得别人觉得我在云吐槽：
- 设备：自费购入华为 MateBook Pro（HAD-W24，HarmonyOS 6.1.0 / API 23）
- 使用时长：8 个月，已成为我的主力开发机
- 适配项目：
- 10 个 Qt 开源软件：DiffPDF / KDiff3 / NotePad-- / glogg / NitroShare / nomacs / QElectroTech / qjackctl / LiteIDE / IronLog（自研）
- 1 个 Electron 项目：MinElectronOhosDemo
- 1 个 Electron 大型应用：CopyQ 适配（剪贴板增强）
- 写作产出：50+ 篇实战博客已发布在 鸿蒙 PC 开发者社区
- 代码量参考：仓库 4000+ 个文件，800+ 个交叉编译产物 .so
我说的每一条建议，下面都会附**“哪个具体项目里被坑过”**，不空谈。
一、生态：现在不缺设备，缺"我每天都要用的工具"
现状
应用市场打开搜常用工具，密集型踩雷：
| 我每天用的工具 | macOS / Linux 是否有 | 鸿蒙 PC 应用市场是否有 |
|---|---|---|
| PDF 对比（DiffPDF / iText） | ✅ | ❌ |
| 代码/文本对比（KDiff3 / Beyond Compare） | ✅ | ❌ |
| 大日志查看（glogg / lnav） | ✅ | ❌ |
| 内网传文件（NitroShare / LocalSend） | ✅ | ❌ |
| 批量看图（nomacs / XnView） | ✅ | ❌ |
| 剪贴板增强（CopyQ / Maccy） | ✅ | ❌ |
| 电路图绘制（QElectroTech） | ✅ | ❌ |
这 7 个工具里，6 个我已经自己手工移植了——你可以理解为这是用户给系统打的补丁。
建议 1：先盯住"程序员/设计师/工程师"这三类高消费力专业用户的高频小工具
不是要做 Adobe、不是要做 Office、不是要砸钱拉头部应用——那些都已经有了。
真正缺的是专业用户依赖的 50 个 GitHub Star 10k+ 的"轻量小工具"——这些工具单个用户黏性极强（“我 5 年没换过 DiffPDF”），换一个生态就走（“鸿蒙 PC 上没有，我就回 Mac”）。
具体建议：
- 官方扫一遍 awesome-mac、awesome-linux-software 列表，把里头每个领域 Star 最高的工具拎出来；
- 针对开源工具，提供"鸿蒙适配赏金"——按已发布版本下载量结算，给真心做适配的人合理回报；
- 官方把交叉编译工具链做成"开箱即用"——现在 Qt-OHOS 的 host 工具（moc/uic/rcc）发出来的是 Windows .exe，Linux/macOS 开发者要自己软链系统包替代（这事我在
鸿蒙PC交叉编译环境搭建/里专门写了一篇文章）。
真实例证：DiffPDF 这个 Star 不到 500 的小众工具，我适配后发到社区，单篇博文阅读量 8000+——说明专业用户对这类"缝隙工具"的需求是真实存在的。
二、权限：现在的设计让"中等复杂度应用"几乎做不了
现状
我做 CopyQ 适配时第一次撞墙。剪贴板增强工具需要：
- 后台常驻，监听系统剪贴板变化
- 读取剪贴板内容（任何应用复制的东西都要捞）
- 弹出快捷键面板（全局热键）
这三件事在 macOS 上一个Accessibility权限全搞定，用户在系统设置里勾一下完事。
鸿蒙 PC 上对应的权限是：
ohos.permission.READ_PASTEBOARD ← 普通权限，OK ohos.permission.WINDOW_TOPMOST ← system 级，调试证书申不到 ohos.permission.SYSTEM_FLOAT_WINDOW ← system 级，调试证书申不到 ohos.permission.kernel.ALLOW_WRITABLE_CODE_MEMORY ← V8 需要，system 级3 个核心权限都是 system 级别。普通开发者的调试证书申请不到，必须走"上架审核"——但你怎么可能没跑通就先上架审核？
建议 2：权限分级需要重新设计
现在的权限设计有个隐性假设：“system 级权限 = 危险 = 不给”。
但很多桌面级常见能力是 system 权限——剪贴板增强、屏幕录制、全局热键、悬浮窗、置顶……这些功能在 macOS 上属于"用户勾一下就能用"的常规权限，鸿蒙 PC 上需要走"审核-合作-签字"。
具体建议：
- 新增"开发者调试权限"档——签了开发者协议的开发者，调试证书也能临时拿到 system 级权限（限时、限设备）；
- 借鉴 macOS 的"用户授权 + 系统设置可撤销"模式——不是开发者证书给不给，而是用户在系统设置里勾不勾；
- 公示权限清单——目前 system 级权限有哪些、各自需要什么资质，没有一个集中的、人能看懂的文档。
真实例证：CopyQ 这种 GitHub 10k+ Star 的成熟剪贴板工具，因为权限问题，我至今没能把完整功能跑通——只能做个"演示版"。这是用户损失，也是生态损失。
三、签名：调试一个 Demo 不应该需要"组织开发者账号"
现状
签名机制是我个人觉得当前体验最差的一环。
- 个人开发者证书申请：要实名 + 银行卡 + 等 7 天
- 调试证书有效期：90 天，到期重申
- 跨设备调试：每台设备的 UDID 都要加进调试证书 profile，加完要重新签
- 一台设备最多绑定数量有限——我家里两台测试机 + 公司一台测试机就快用完
对比 macOS：开发者随便编一个 app，本机能直接跑，不签名也行（只是 Gatekeeper 弹一下警告）。iOS 开发的繁琐签名机制不应该被搬到桌面上。
建议 3：桌面应用的签名应该比手机宽松
iOS 当年那套严签名机制有道理——手机是触屏 + 系统级账号 + 移动支付载体，签名严是为了用户安全。
但 PC 不是。
PC 上开发者经常在自己机器上跑各种"半成品"——脚本、Demo、内部工具。强行套用手机签名模式，本质上把 PC 当大号手机管，开发体验崩坏。
具体建议：
- "个人开发者本机调试"应免签名——只要是当前登录账号的设备，跑自己编的 app 就让它跑；
- 签名机制公开化——目前
keyPassword: 0000001BD37C2F18F9DC...这种格式根本看不懂是什么； - CI 友好——自动签名目前只能在 DevEco 里点按钮触发，没有命令行接口，CI/CD 集成是手工活。
真实例证：我适配 10 个 Qt 应用的过程里，至少 6 次因为签名问题导致跑不起来——证书过期、设备 UDID 没加、profile.p7b 路径写错、key store 密码记不住。每次都浪费半天。
四、应用市场：开发者的"上架体验"亟需优化
现状
我有几个适配好的应用想上架，结果发现：
- 没有"开发者预上架"模式——只能正式提交审核
- 审核反馈不透明——"建议优化"具体优化什么不告诉你
- 元数据要求过于细——截图 4 种尺寸、宣传图 3 种比例、应用描述长度限制……开源工具的作者根本搞不来这些
- 没有"自动从开源协议生成隐私政策"的工具——MIT 协议的开源工具要求填一份正式的隐私政策，作者真的不知道怎么填
建议 4：给开源软件一条"轻量上架通道"
iOS 的 App Store 那一套商业化流水线对独立开发者已经过于沉重，鸿蒙 PC 没必要照抄。
具体建议：
- 开源软件专属上架通道：自动读取 GitHub LICENSE / README / 截图，开发者只需要补一个"鸿蒙 PC 适配说明"；
- 审核透明化：被拒原因要具体到"哪一条违反了哪个规则"，链接到具体条款；
- 延迟审核 + 用户自担风险模式：参考 Steam 的"早期访问"，未审核应用允许用户主动开启"开发版安装"看到。
真实例证：我的 IronLog（自研健身记录工具）从想上架到放弃上架，前后3 次提交全部被打回——原因都是隐私政策格式、截图尺寸、应用描述字数。适配代码我跑通用了 3 天，上架元数据弄了 1 周还没过。
五、开发文档：现在是"官方文档很全"和"实战遇到的坑零文档"并存
现状
华为的官方开发者文档结构非常齐——API 列表、组件指南、ArkTS 语法手册一应俱全。
但我做适配遇到的真实问题，90% 在官方文档里找不到答案：
| 我遇到的问题 | 官方文档 | 社区博客 | 我最后怎么解决 |
|---|---|---|---|
| Qt-OHOS host 工具是 Windows .exe，Linux 上跑不了 | ❌ | ❌ | 自己摸索 |
qt_resourceFeatureZlib符号缺失闪退 | ❌ | ❌ | 自己 grep 源码 |
Electron 在 6.1 上napi_unwrap fail | ❌ | ❌ | 自己换包测试 |
| 4KB 页对齐写入 .so 头 | ❌ | ⚠️ 1 条 | 自己写 Python 脚本修 |
| moc ABI 5.15 → 5.12 降级 | ❌ | ❌ | 自己读 moc 源码 |
5 个核心坑里，官方文档 0 命中。
建议 5：官方文档需要一个"踩坑库"分支
文档不应该只有"应该怎么做"，更应该有"做错了会怎么样、怎么修"。
具体建议：
- 官方维护一个
troubleshooting.md大全——按"错误信息原文"索引，让开发者搜得到； - 每个 NDK API 加一个"常见崩溃"栏目——比如
napi_wrap旁边写清楚"如果 .so 是按 OHOS 5.0.x NAPI 协议编译的，在 6.0+ 上会报 napi_unwrap fail"； - 官方主动收编社区高质量博客——很多答案在 CSDN / 掘金里有，但被淹没在水文里。
真实例证：我写的《鸿蒙 PC HAP 安装失败 no signature file 排查与修复》这一篇博文，被引用了 30+ 次——说明这个具体错误官方没解释清楚，但开发者大量在踩。
六、和苹果对比：5 件应该学的、3 件不该学的
我用 macOS 10 年。下面这部分会有点尖锐，但请把它当成"诚实反馈"，不是"舔苹果"。
✅ 应该学苹果的 5 件事
1.pkg-config/brew这一套依赖管理体验
macOS 上装一个 Qt 开发环境：
brewinstallqt@5# 完事鸿蒙 PC 上装交叉编译 Qt：下载 SDK → 软链 host 工具 → 配环境变量 → 找镜像 → 自己改 CMake toolchain（参考我那篇 581 行的环境搭建文章）。
brew 的体验做到鸿蒙 PC 上，开发者数量能翻倍。
2.代码签名应该是"系统帮你做"而不是"开发者自己折腾"
macOS 上：
codesign--force--deep--sign- MyApp.app# 不签名也能跑（Gatekeeper 让用户授权一次）鸿蒙 PC 上签名流程的复杂度（见第三节），是 macOS 的 5-10 倍。
3.Universal Binary 思路
Apple Silicon 转换时苹果做了 Universal 二进制——一个包同时含 x86_64 + arm64，自动选。
鸿蒙 PC 现在还是 arm64-v8a 单架构为主。未来鸿蒙 PC 进 x86_64 笔记本时（这是迟早的事），现在不预留 Universal Binary 设计，会重蹈 Apple 当年 fat binary 的覆辙。
4.macOS 的"开发者模式"和"普通用户模式"严格区分
macOS 上开发者打开 Xcode 命令行工具，系统就知道你是开发者——sudo dscl . -append /Groups/_developer GroupMembership $USER，之后很多调试操作免确认。
鸿蒙 PC 现在不区分"开发者"和"普通用户"的设备状态，结果就是：普通用户被各种"开发者权限"卡住（其实他们不需要），开发者也要走普通用户的弹窗确认流程（其实多余）。
5.Finder 的"快速预览"
macOS 按一下空格就预览文件。这个交互全世界都在抄，鸿蒙 PC 没抄。
❌ 不应该学苹果的 3 件事
1.App Store 的 30% 抽成不要照搬
如果鸿蒙 PC 应用市场未来收抽成，请明确设置"开源软件 0 抽成"档。
2.不要照搬苹果的"反开发者倾向"
苹果这几年在 macOS 上一直收紧——sudo越来越多场景要授权、kext 加载越来越难、第三方应用越来越不被信任。
鸿蒙 PC 如果学这条路，短期商业回报很好看，长期会失去整个独立开发者社区。
3.不要学苹果"硬件焊死"路线
MacBook 现在内存焊死、SSD 焊死、电池焊死——所有维修都得回原厂。
MateBook Pro 现在的可拆卸/可升级体验显著好于 Mac，希望这点能保持。
七、几个"看似小但每天都在烦"的细节建议
7.1 hdc 命令应该自动加入 PATH
macOS 上which adb直接出路径。
鸿蒙 PC：装完 DevEco 之后，hdc 在哪？大概在：
~/Library/Huawei/Sdk/openharmony/9/toolchains/hdc但这个路径不在 PATH 里，开发者第一次用 hdc 要自己找。我建议：DevEco 安装时默认把 hdc 加到 PATH，或者提供/usr/local/bin/hdc软链。
7.2 鸿蒙 PC 应该有"原生 SSH 终端"
现在鸿蒙 PC 上 SSH 连服务器要装第三方终端 App。应该有一个官方的、跟 macOS Terminal 一个水准的终端——支持标签页、配色方案、配置 .ssh/config。
7.3 文件管理器需要"开发者视图"
鸿蒙 PC 的文件管理器默认隐藏点开头的文件（.bashrc、.ssh/、.gitconfig）。
切换开关藏得很深。应该有一个"开发者模式视图"开关，一键显示所有点文件。
7.4 DevEco Studio 应该开放插件市场
现在 DevEco 基于 IDEA，但不能装 IDEA 插件——这等于断了开发者积累多年的插件生态。
很多开发者（包括我）DevEco 用来写鸿蒙代码，写 ets 之外的代码还是要回 VS Code——因为 GitLens / Tabnine / GitHub Copilot 这些插件 DevEco 装不上。
建议 9：DevEco 应该兼容 IDEA 插件，至少兼容一部分核心生产力插件
JetBrains 生态本身就是 PC 桌面的核心生产力源——把开发者从这个生态里拽出来需要等值替代品，目前 DevEco 还没做到。
八、最想说的一句话
我做完 11 个适配项目之后，对鸿蒙 PC 整体的判断是：
底子是好的，问题不在能不能用，问题在"用起来太累"——而这种累很多是设计选择导致的，不是技术不行。
技术上鸿蒙 PC 已经能跑 Qt + Electron + 各种工程化中等复杂度的应用。这个我用 11 个项目证明过了。
但开发体验这一层——签名复杂度、权限分级、文档完整度、IDE 生态、工具链友好度——这些是设计可以改、不需要重写底层的事。
希望以上 9 条建议有一两条能进到设计鸿蒙 PC 的人的视野里。我不是要它变成 macOS，也不是要它变成 Windows——
我想要它成为我未来 10 年的主力机。它现在很接近了，差临门一脚。
写在最后
写这篇文章我犹豫了一周。
因为很多话写出来会得罪人——得罪做这个系统的工程师（“凭啥说我们设计不好”）、得罪某些社区里"只能说好话"的氛围。
但我后来想，如果我适配了 11 个项目踩了这么多坑都不写出来，那比我还能折腾的开发者更不会写。没人写就没人改，没人改这个系统就慢慢变成"只能看不能用"的样子。
所以这篇是诚意之作。写它不是因为我对鸿蒙 PC 失望，恰好相反——是因为我已经把它当主力机了，希望它越来越好。
如果你也是鸿蒙 PC 开发者，欢迎来 https://harmonypc.csdn.net/ 交流。如果你是华为/鸿蒙的产品/工程师看到了这篇，欢迎私信聊——我可以提供更详细的踩坑数据。