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

DBX 是基于 Tauri 2、Rust 和 Vue 3 的数据库客户端。本次适配保留原有业务代码，在 Tauri 的 OpenHarmony 后端之上，接通 OHOS 原生编译、ArkTS Ability、ArkWeb 页面和系统文件、窗口接口。

本文按实际适配顺序说明：遇到了什么问题、依据什么定位、修改了哪一层，以及如何确认修改生效。构建和真机操作统一使用 devecocli；Rust 与第三方 C/C++ 库由 Cargo、ohrs 和 OHOS SDK 原生工具链编译。

2026-10-04 实测结果：当前签名 HAP 已在 HarmonyOS API 26 的 2in1 真机上覆盖安装并启动，真实 DBX 主界面、新建连接与 SQLite 表单正常显示；原生桥接完成请求往返，应用自绘按钮完成最大化和还原，工具栏拖动改变了窗口位置，系统文件选择器可打开和取消，应用私有目录中的 SQLite 数据库完成连接测试与连接。

仓库地址：https://atomgit.com/OpenHarmonyPCDeveloper/ohos_dbx

一、先确定适配边界

适配不是重新实现一个 GUI 框架，而是将 DBX 的 Tauri 依赖栈切到具有 OHOS 支持的修订，再处理应用自身的平台差异：

Vue 业务界面
  ├─ Tauri IPC → Rust 数据库与存储逻辑
  └─ OHOS 平台适配器 → ArkTS 文件与窗口接口
                                  ↓
                         EntryAbility / ArkWeb
                                  ↓
                         DevEco 构建的签名 HAP

相关代码集中在以下位置：

位置	职责
Cargo.toml、src-tauri/Cargo.toml	Tauri 依赖修订、平台依赖与 feature 门控
src-tauri/src/lib.rs	启动、私有数据目录、平台初始化
src-tauri/src/ohos_hilog.rs	将 Rust 日志接入系统 hilog
apps/desktop/src/lib/backend/ohosPlatform.ts	前端与 ArkTS 的请求、回复及窗口操作
apps/desktop/src/lib/backend/platformDialog.ts、platformFs.ts	文件对话框与文件读写的平台入口
src-tauri/gen/ohos/entry/	EntryAbility、入口页面、权限及原生 .so
src-tauri/gen/ohos/ohos-rs-ability/	项目内的本地 HAR、ArkWeb 控制器与事件接入
scripts/ohos.mjs、scripts/build-ohos-native.mjs	devecocli 包装与 Rust 原生构建
agents/scripts/build_ohos_native.py	OHOS 原生 Agent / 插件制品构建与 ELF 校验
harmonyos/	工具链说明、定位记录与适配时间线

二、解决“OHOS 被当成 Linux 编译”的问题

现象与定位

OHOS Rust 目标 aarch64-unknown-linux-ohos 同时满足 target_os = "linux" 和 target_family = "unix"。只按 Linux 判断的平台分支，会把 GTK/WebKitGTK 依赖、Linux 渲染环境变量或 Linux 外部程序选择逻辑带入 OHOS。

DBX 原有的 wry 修订也早于 OHOS 后端的接入。单独修改应用目标 triple 不够，必须让 Tauri、wry、tao 和 Ability 桥接使用匹配的依赖栈。

处理方式

1. 将 Tauri 相关依赖切到支持 OpenHarmony 的 feat/open-harmony 修订；原有 wry 平台补丁继续保留在对应平台模块中。

2. 对只属于普通 Linux 的实现使用显式门控：

   #[cfg(all(target_os = "linux", not(target_env = "ohos")))]
   

3. 托盘、原生菜单及桌面插件按目标条件编译；Tauri capabilities 拆分为公共声明与桌面插件声明。

4. current_platform()、current_plugin_target() 优先判断 OHOS，生成 ohos-arm64 等目标键，而不是沿用 linux-arm64。

这一步同时解决了编译依赖选择和运行时制品选择：操作系统名称相近，不代表二进制 ABI 可以混用。具体修改集中在工作区依赖配置、src-tauri/src/lib.rs 和 crates/dbx-core 的平台识别逻辑中。

三、建立可复现的 Windows 构建链路

工具链与项目配置

项目	本轮使用的配置
宿主	Windows x64
Rust / Cargo	1.99.0，安装 OHOS 目标标准库
Rust 目标	aarch64-unknown-linux-ohos
ohrs	1.4.2
devecocli	1.3.4
SDK	DevEco Studio 的 OpenHarmony SDK，编译目标 API 26
HAP 兼容配置	compatibleSdkVersion: "6.1.1(24)"
HAP 目标配置	targetSdkVersion: "26.0.0"、runtimeOS: "HarmonyOS"
原生构建工具	SDK Clang / sysroot、CMake、Ninja；OpenSSL 构建使用 GNU make 与 Perl

构建入口的调整

原先依赖 Tauri CLI 临时回调服务的构建方式，不适合作为独立的 DevEco 工程入口。现在由 entry/hvigorfile.ts 的原生构建 hook 调用 scripts/build-ohos-native.mjs：

1. 构建 Vue 前端。
2. 准备 Tauri 配置和 OHOS SDK 编译环境。
3. 使用 ohrs / Cargo 编译 Rust 库并生成 NAPI 类型，启用 sqlite-bundled,custom-protocol。
4. 交给 DevEco 完成 ArkTS 编译、HAP 打包与签名。

scripts/ohos.mjs 负责从仓库根目录进入壳工程并调用 devecocli，不再连接临时 WebSocket 服务。保留已经适配的 gen/ohos 工程，不重新生成并覆盖路由、权限或本地 HAR 配置。

Windows 路径与原生依赖

harmonyos/env-windows.sh 根据实际 SDK 位置组织环境，处理 Windows 短路径和 Bash PATH 分隔符，不再硬编码用户名或代理。GNU make 可通过 OHOS_BUILD_TOOLS_DIR 或 PATH 提供，Perl 模块通过 PERL5LIB 提供。

OHOS 交叉编译使用 SDK Clang；宿主 MSVC 构建使用 Windows 原生 Perl 与 MSVC 环境。两套编译器、sysroot 和 Perl 环境分开配置，避免把宿主参数带入 OHOS 构建。

安装与构建示例：

npm install -g @deveco/deveco-cli@latest
devecocli --version
rustup target add aarch64-unknown-linux-ohos
cargo install ohrs --locked

# 换成本机 DevEco Studio 的 SDK 目录
export DEVECO_SDK_HOME='<DevEco Studio 安装目录>/sdk'
export CARGO_PROFILE_DEV_DEBUG=0
source harmonyos/env-windows.sh

pnpm build:ohos --build-mode debug

若 npm 提示官方实现包的安装脚本未获准，可仅对本次安装放行，不必修改全局安全配置：

npm install -g @deveco/deveco-cli@latest --allow-scripts=@deveco/deveco-cli-common

签名材料沿用本机配置，并覆盖目标设备。新环境可在 src-tauri/gen/ohos 中查看 devecocli signature generate --help；证书、密码和设备标识不写进仓库教程。

签名 HAP 输出位置：

src-tauri/gen/ohos/entry/build/default/outputs/default/entry-default-signed.hap

图 1：早期最小应用验证（2026-09-18，2in1 模拟器）。smoke-app 窗口已经显示 Hello World，用于区分基础显示链路与后面的 DBX 业务页面加载。

四、让 RustAbility 真正加载业务页面

路由和入口页面

启动时的 failed to create page: RustAbility 指向页面入口与路由元数据，而不是 Vue 业务代码。处理时保留项目显式配置的 routerMap，并补齐实际入口页：

入口组件为 RustAbilityPage，使用 @Entry({ routeName: 'RustAbility' }) 声明；页面内容沿用项目中的 RustAbility 实现。

main_pages.json 登记 pages/RustAbility，WindowStage 使用实际页面路径加载：

await windowStage.loadContent('pages/RustAbility');

Ability HAR 放在 DevEco 项目根内的 ohos-rs-ability/，entry 通过本地依赖引用，统一模块名为 ohos_rs_ability。这样模块路径、包身份与页面入口都由同一个壳工程管理。

图 2：入口修复过程中的历史白窗（2026-10-04，真机）。可见 DBX 窗口和标题，但没有业务内容；这是当时的页面加载现象截图，不是修复后的运行结果。

原生初始化与控制器关联

两个启动顺序需要明确区分：

• 原生模块准备好之后才能创建业务窗口。 EntryAbility.nativeReady 保存异步初始化 Promise，onWindowStageCreate 等待它完成，再通知 Rust 生命周期并加载内容。
• Web 控制器关联到 Web 组件之后才能设置下载委托。 SDK 曾明确报告 The WebviewController must be associated with a Web component。委托注册从创建 Web 数据对象的阶段移到 .onControllerAttached()，再执行 URL / HTML 加载。

图 3：已解决问题的报错摘录图。依据 E59 / E60 留档与原始 crash 日志重新排版，明确不是原始终端或设备截图；保留页面入口、控制器关联和 SIGILL 的关键定位信息，分别对应本节及第六节的处理过程。

页面加载 API 返回成功只是中间证据。最终确认来自设备上的 UI 树和截图：工具栏、连接侧栏、统计卡和常用操作均显示为真实 DBX 业务界面。

五、修正私有数据目录的初始化时机

OHOS 数据存储采用 Ability 的 context.filesDir/<identifier>。原生初始化仍传入：

nativeModule.init({ basePath: this.context.filesDir });

定位启动异常时，日志已经证明旧 XDG 数据目录解析成功；随后访问 Ability basePath 才进入异常路径。检查 Tauri 生命周期发现：Builder::build() 在 setup 运行前，通过 .take() 消费全局 OHOS APP。因此不能在 setup 中再次从该全局读取 Ability 上下文。

修复位于 src-tauri/src/lib.rs：在 run() 中、构建 Builder 之前取得 basePath，再把这个路径值移入 setup 闭包。存储目录仍由现有 sandboxed_data_dir 逻辑生成，不改回共享用户目录。

旧数据迁移沿用非覆盖策略：复制到新的私有目录，已有目标文件不覆盖，旧目录不删除。解决的是上下文所有权与初始化时机，而不是通过清空用户数据绕过问题。对应定位记录见 harmonyos/errors.md 的 E59。

六、修复 OpenSSL ARM 特性检测导致的延迟退出

这一问题说明了为什么短时间启动检查不足以证明运行链路正常：应用启动后约 14 秒，TLS 工作线程因 SIGILL 退出。对实际崩溃文件中的地址使用 SDK llvm-addr2line 符号化，定位到 ChaCha20_ctr32_sve，调用链经过 ChaCha20-Poly1305 TLS 加密。

OpenSSL 3.6.3 的 ARM 特性检测没有把本轮 OHOS musl 环境识别为 getauxval 平台，选择了基于信号的探测路径。修复采用 SDK 提供的辅助向量与 HWCAP，而不是禁用 TLS、关闭证书校验或关闭全部汇编优化。

scripts/ohos-openssl.h 的关键内容：

#if !defined(__ASSEMBLER__) && (defined(__aarch64__) || defined(__arm__))
#include <sys/auxv.h>
#define OSSL_IMPLEMENT_GETAUXVAL
#endif

构建脚本统一使用该头文件，设置 CC_SHELL_ESCAPED_FLAGS=1，并把 forced-include 写成单个参数 -include"<仓库路径>/scripts/ohos-openssl.h"。其中有三个具体处理点：

• C 声明不进入汇编输入，避免汇编器把 typedef 等声明当成指令。
• 含空格的 Windows 路径由编译参数解析器正确处理。
• -include 与文件名保持一个 joined 参数，避免 OpenSSL Configure 把独立文件名识别成第二个构建目标。

完整原生重编译后，SDK 反汇编确认 OPENSSL_cpuid_setup 调用了 getauxval(16)、getauxval(26)，SVE / SVE2 分派由 HWCAP 控制。之后真机展示实际主界面，并继续完成连接与窗口交互。对应记录见 E60。

图 4：完成入口、初始化时序和 HWCAP 修复后的真机主界面（2026-10-04）。工具栏、连接侧栏、统计卡和常用操作区均已显示；为方便阅读，此图由原始运行截图裁取应用窗口区域。与图 2 的历史白窗形成前后对照。

七、接通页面与 OHOS 原生接口

代理存在，不等于方法已获准调用

最初可以在页面中看到 __DBX_OHOS_NATIVE__，也能取得 request 函数，但直接调用返回 Error: Jsb Permission Denied。这将定位范围从“页面没有加载”收敛到 JSBridge 的授权与调用路径。

当前请求入口在 DbxPlatform.request() 中读取 SDK 的 getLastJavascriptProxyCallingFrameUrl()，在解析和执行请求之前检查调用页面 URL。可信范围限定为应用的 tauri://localhost、Tauri 本地 HTTP(S) 页面及指定的开发端口，不采用页面自行传入的来源字符串。

原生入口同步返回拒绝原因或空字符串，前端据此处理调用拒绝；业务结果仍通过异步回复完成：

页面 request({ id, action, ...options })
  → 原生检查 SDK 报告的调用页面
  → 执行文件或窗口操作
  → __DBX_OHOS_REPLY__(id, value, error)
  → 前端完成对应 Promise

设备上的只读 state 请求得到空的接受回执，以及 { value: false, error: null } 回复；随后最大化、还原和文件选择器均通过真实页面操作触发。验证结束后，临时状态探针、日志与诊断弹窗从源码移除。

文件接口与数据库路径分开设计

前端通过 platformDialog.ts、platformFs.ts 和 ohosPlatform.ts 接入原生接口，桌面端继续使用原有插件。HAP 声明：

权限	对应用途
ohos.permission.INTERNET	数据库连接及网络请求
ohos.permission.FILE_ACCESS_PERSIST	系统选择器所授文件、目录权限的持久化

文件访问从用户操作系统选择器开始。普通导入复制为应用沙箱中的常规文件；原 URI 的保留、描述符生命周期与授权恢复由 ArkTS 平台层管理。路径检查逐级检查符号链接，并对保留描述符核对 inode，不通过开放全部 /proc 来扩大访问范围。

数据库使用普通沙箱文件。真机通过原生确认框创建 filesDir/databases/<时间戳>/database.db，SQLite 表单的“测试”返回 连接成功，随后连接出现在应用侧栏和已连接统计中。这条路径将 SQLite 文件、锁与辅助文件放在同一应用存储范围内。

图 5：真机新建连接对话框（2026-10-04）。画面展示数据库分类和类型选择，是从主界面实际进入连接流程的运行截图。

窗口装饰和拖动落到正确的层

DBX 自绘窗口按钮，而 Tauri 配置中的 decorations: false 在本轮 OHOS 后端不能单独完成系统装饰管理。处理放在 EntryAbility：加载页面并设置窗口布局后，显式调用 setWindowDecorVisible(false) 和 setWindowTitleButtonVisible(false, false, false)。

修改前：系统装饰与应用自绘按钮同时出现。

图 6：2026-09-18 的模拟器历史截图。关闭确认框后方仍可看到上下两组窗口控制按钮，说明仅保留前端自绘控件不足以管理原生装饰。

修改后：应用工作区保留一组窗口控制按钮。

图 7：2026-10-04 的真机 SQLite 工作区，左侧显示已连接的验证连接，右上保留一组最小化、最大化和关闭按钮。图片裁取应用区域；编辑器中的 PRAGMA 是当时可见的编辑内容，数据库连接成功依据前述表单测试与连接状态。

最大化与还原分别使用主窗口的 maximize()、recover()，而不是调用桌面专属后端。拖动则分成两个时机：前端 pointerdown 发起请求；原生 Web .onTouch 收到 Down 后记录状态，在 Move 回调中同步调用 startMoving()，结束或取消触摸时释放拖动状态。

真机几何变化提供了直接证据：

操作	实际观察的窗口边界 [left, top, right, bottom]
初始浮动窗口	[515, 292, 2605, 1686]
点击应用最大化按钮	[0, 0, 3120, 1978]
点击还原按钮	[515, 292, 2605, 1686]
工具栏拖动 (1600, 330) → (1750, 430)	[665, 392, 2755, 1786]

这里验证的是窗口真正改变了状态与位置，而不是点击命令返回成功。主窗口截图同时显示右上角只有一组应用窗口控制按钮。

八、OHOS 原生 Agent / 插件制品的构建原则

平台键修正之后，还需要让制品来源与 ABI 一致。agents/scripts/build_ohos_native.py 使用 OHOS SDK Clang、sysroot 和目标 Rust 标准库构建真实原生可执行文件，供 Agent / 插件构建流程调用。

本段记录构建与制品校验：本轮已经编译 plugins/examples/hello-workbench/backend 的 OHOS arm64 后端，并通过 ELF 校验。检查包含 ELF64 小端格式、CPU 架构、可执行入口、程序头及加载段边界，以及动态 musl 加载器；不把普通 Linux glibc 制品改名成 OHOS 制品，也不把加载器名称单独当成来源证明。

# OHOS_SDK_ROOT 指向包含 native/ 的 SDK；CMake/Ninja 位于 PATH
python agents/scripts/build_ohos_native.py --target ohos-arm64 \
  --manifest-path plugins/examples/hello-workbench/backend/Cargo.toml \
  --bin dbx-example-hello --target-dir target/ohos-plugin \
  --output target/ohos-plugin/dbx-example-hello

Agent 发布 job 使用 DBX_OHOS_RUNNER、DBX_OHOS_SDK_ROOT 指定原生构建环境。Go 与 Java 制品分别按 OHOS Go 工具链、OHOS JRE 的实际运行环境组织，不使用 GOOS=linux 或普通 Linux JRE 代替目标平台。

九、复现构建与实测的方法

在仓库根目录部署已成功构建的签名产物；--skip-build 表示不重复构建，并不省略安装与启动：

DEVICE='<设备名或序列号>'
devecocli device list
pnpm run:ohos --skip-build --device "$DEVICE"
devecocli ui window list --device "$DEVICE"
devecocli ui layout --device "$DEVICE" --window <窗口ID> --depth 20 --format json
devecocli ui screenshot --device "$DEVICE" --path <截图路径.png>
pnpm logs:ohos --device "$DEVICE" --keyword DBX --tail 100

本次实测按以下证据链进行：

1. 构建证据：DevEco 完成 Rust / ArkTS 编译、HAP 打包与签名。
2. 页面证据：设备 UI 树出现真实业务节点；主界面截图为 3120×2080，非黑像素约 54.98%，并可见 DBX 工具栏、连接侧栏与操作区。
3. 交互证据：实际打开新建连接、选择 SQLite，系统文件选择器打开后取消可回到连接表单。
4. 原生证据：桥接请求得到回复；窗口最大化、还原和拖动具有可测量的边界变化。
5. 数据库证据：应用沙箱中的 SQLite 文件连接测试成功，并完成连接。

截图先检查像素，再检查可见内容；设备需处于解锁、亮屏状态。日志经 ohos_hilog.rs 接入 hilog，使用 DBX 标签检索。历史报错定位时同时参考实际崩溃文件和未剥离的 Rust 库，避免仅凭启动命令或短时 Smoke 的返回值作结论。

ArkWeb 代理调用与权限接口说明可参照官方 WebviewController 文档。

---

功能到底能用到什么程度

下面三张表是这份文档最实用的部分，软件迁移能力按 T0 / T1 / T2 三档来列——T0 基础能力（能不能编、能不能装、能不能起、能不能渲染）、T1 主要能力（数据库客户端的日常核心功能）、T2 增强能力（桌面端的加分项）。

表里的结论都取自正文各节和 2026-10-04 的真机实测证据，状态分三种：

• 能用：在真机上实际操作过，并有可复核的证据（构建输出、UI 树、截图、窗口边界或日志）。
• 待验证：正文只给出做法或原则，尚未给出实测结论。
• 未适配：桌面端专属能力，OHOS 下按目标条件编译关闭，属于按平台特点主动取舍。

T0 基础能力（能不能编、能不能装、能不能起、能不能渲染）

能力	状态	依据
Rust 与原生 C/C++ 依赖交叉编译	能用	第二节、第三节：ohrs / Cargo 与 SDK Clang、sysroot、CMake、Ninja 编译 aarch64-unknown-linux-ohos；第六节 OpenSSL 重编译后经 SDK 反汇编确认 HWCAP 分派
HAP 打包与签名	能用	第三节：DevEco 完成 ArkTS 编译、HAP 打包与签名，产物为 entry-default-signed.hap
真机安装与启动	能用	开头 2026-10-04 实测结果与第九节：签名 HAP 在 HarmonyOS API 26 的 2in1 真机上覆盖安装并启动
业务页面加载	能用	第四节：RustAbilityPage 与 main_pages.json 登记入口，windowStage.loadContent('pages/RustAbility')；第九节 UI 树出现真实业务节点
主界面渲染	能用	第九节：主界面截图 3120×2080、非黑像素约 54.98%，工具栏、连接侧栏与操作区均可见
页面与原生桥接	能用	第七节：页面 request() → 原生校验调用页面 → __DBX_OHOS_REPLY__ 回复；设备上只读 state 请求取得回执
窗口装饰与窗口操作	能用	第七节：setWindowDecorVisible(false)、setWindowTitleButtonVisible(false, false, false) 后只保留一组应用按钮；最大化、还原、拖动的窗口边界实测发生变化
运行日志与崩溃可定位	能用	第六节、第九节：日志经 ohos_hilog.rs 接入 hilog（标签 DBX）；SIGILL 退出用 llvm-addr2line 定位到 ChaCha20_ctr32_sve

小结：编、装、起、渲染这条底线上，每一环都有真机证据；第九节把构建、页面、交互、原生、数据库五类证据分别列出，不靠启动命令的返回值下结论。

T1 主要能力（数据库客户端的日常核心）

能力	状态	依据
新建连接流程	能用	第七节图 5：真机进入新建连接对话框，显示数据库分类与类型
SQLite native 驱动端到端	能用	第七节：在 filesDir/databases/<时间戳>/database.db 建库，「测试」返回连接成功，连接随后出现在侧栏与已连接统计中
应用私有数据目录	能用	第五节：使用 context.filesDir/<identifier>，初始化时机修正后不再依赖共享 XDG 目录；旧数据按非覆盖策略迁移，旧目录保留
文件读写与系统选择器	能用	第七节：platformDialog.ts、platformFs.ts、ohosPlatform.ts 接入原生接口，选择器打开后取消可回到连接表单；ohos.permission.FILE_ACCESS_PERSIST 持久化授权
宿主构建链路可复现	能用	第三节：harmonyos/env-windows.sh 与 scripts/ohos.mjs 在 Windows x64 宿主上一条命令完成前端、Rust 库与 HAP 构建
OHOS 原生 Agent / 插件制品（Rust 侧）	能用	第八节：编译 hello-workbench 的 OHOS arm64 后端，并通过 ELF 格式、架构、程序头与 musl 加载器等校验
Go / Java 原生制品	待验证	第八节说明按 OHOS Go 工具链与 OHOS JRE 的实际运行环境组织，但未给出对应构建与运行实测结论

小结：数据库客户端的日常主线（新建连接、系统选择器、私有目录、SQLite 连接测试与连接）都已在真机跑通；没有实测结论的只有 Go / Java 原生制品这一项，它属于制品矩阵的工程量，不是配置问题。

T2 增强能力（桌面端的加分项）

能力	状态	依据
系统托盘	未适配	第二节：按目标条件编译，OHOS 构建不引入托盘依赖
原生菜单	未适配	第二节：与托盘同样按目标条件编译
桌面插件	未适配	第二节：桌面插件按平台门控，Tauri capabilities 拆分为公共声明与桌面插件声明；第七节中文件、对话框等能力改由 platformDialog.ts、platformFs.ts 等平台入口承担，桌面端继续使用原有插件

小结：这一档没有一项是「做不出来」——托盘、原生菜单、桌面插件在 OHOS 上本就没有对应的系统概念，按平台条件编译关闭而不是硬搬。

这么算下来，整体到什么程度

把上面三张表合起来看：

• T0 基础能力：Rust 与原生依赖交叉编译、HAP 打包签名、覆盖安装与启动、业务页面加载、主界面渲染均在真机上实测通过。
• T1 主要能力：页面与原生桥接往返、窗口装饰处理与最大化/还原/拖动、系统文件选择器、应用私有数据目录、SQLite 连接测试与连接、Rust 侧原生插件制品构建均在真机上实测通过；Go / Java 原生 Agent / 插件制品只给出组织原则，尚无实测结论。
• T2 增强能力：系统托盘、原生菜单、桌面插件按平台条件编译关闭，属于按平台特点主动取舍，不是没做出来。

这里不折算百分比：三张表每一项都对应正文的实测证据或明确的取舍说明；缺实测证据的项如实标为「待验证」，不用估算把表补满。

一句话总结：DBX 已在 HarmonyOS API 26 的 2in1 真机上完成签名 HAP 的覆盖安装与启动，业务页面、原生桥接、窗口操作、文件选择器、私有数据目录与 SQLite 连接等日常链路均已实测跑通；托盘、原生菜单、桌面插件按平台特点关闭，Go / Java 原生制品只给出组织原则、尚无实测结论。

---

关于 OpenHarmony PC 社区

加入开源鸿蒙 PC 社区的引导见本文开头。

欢迎在 PC 社区平台申请新建项目：https://atomgit.com/OpenHarmonyPCDeveloper

本项目按社区规范提交入库申请：

• 命名：按社区「项目命名指导」，仓库统一命名为 ohos_<项目名>（项目名与官网保持一致，社区同规范仓库如 ohos_marktext、ohos_joplin）。本项目对应 ohos_dbx。
• 流程：在社区 community 仓按「新建仓库指南」提交 issue 申请，标题规范为 【新建仓申请-XXX】；审批通过后由社区维护者创建仓库，代码托管至 https://atomgit.com/OpenHarmonyPCDeveloper。
• README 与变更记录：按社区「开源项目发布规范」，仓库根 README 保持「简介 / 安装 / 权限 / 使用示例 / 约束与限制（含支持的 API 与 SDK 版本）/ 目录结构 / 贡献 / 协议」等要素，License 与 ChangeLog 随仓库提供。

目标仓库地址：https://atomgit.com/OpenHarmonyPCDeveloper/ohos_dbx（仓库尚在社区审批流程中，暂未生效）。