HarmonyOS 7 + DataShare Kit + ArkData 技术干货：跨应用数据共享、URI 路由与增删改查闭环【鸿蒙心迹】

2601_96710770

151人浏览 · 2026-09-28 23:50:59

2601_96710770 · 2026-09-28 23:50:59 发布

跨应用数据共享最危险的误区，是把它理解成“另一个应用能访问我的数据库”。真正合理的设计，应该是：数据提供方只暴露明确的 URI 和能力边界，访问方只通过 DataShareHelper 完成受控的增删改查。本文从一套笔记共享 Demo 出发，把这条链拆开。

一、先把一个边界说清楚：DataShare 不是“数据库暴露器”

第一次接触 DataShare 时，很容易把它想成“把本地 RDB 给别的应用查”。

这种理解非常危险。

真正的工程结构应该分成两侧：

提供方：决定哪些数据能共享、哪些操作能开放；
访问方：通过 URI 建立连接，并调用受控的 query / insert / update / delete。

也就是说，外部应用并不会直接拿到你的数据库对象。

它拿到的是一个数据服务入口。

这件事非常重要，因为一旦把这个边界想清楚，后面的权限、字段过滤、写入校验、变更通知就都顺了。

另外还有一个必须提前说明的现实约束：DataShareExtensionAbility 等部分接口属于系统能力范围。三方应用在真实项目中必须先确认当前 HarmonyOS 版本、应用类型和权限开放范围，不能只看示例代码就默认可以直接上线使用。

本文重点放在数据共享机制和工程设计，而不是绕过平台权限边界。

二、我会先设计 URI，再写任何一行 CRUD

做 DataShare 时，我现在第一步不是建表，而是设计 URI。

比如一个笔记应用要对外提供：

笔记列表；
单条笔记；
标签数据；
最近更新数据。

我会先把路由规划成类似：

datashare:///com.example.notes/notes
datashare:///com.example.notes/notes/1001
datashare:///com.example.notes/tags
datashare:///com.example.notes/recent

URI 的价值不是“看起来规范”，而是它天然就是共享边界。

外部访问方看到哪条 URI，就只应该得到那条 URI 对应的数据能力。

如果所有东西都塞进一个入口，再靠参数猜业务，后面权限控制会越来越乱。

三、提供方最重要的事情，是把业务规则挡在边界层

提供方通常会围绕 DataShareExtensionAbility 去实现自己的服务能力。

核心思路不是把数据库 CRUD 原样透传，而是要在扩展能力层先做判断：

当前 URI 是否支持；
调用方有没有权限；
写入字段是否合法；
删除是否允许；
查询是否需要限制列；
是否需要记录访问日志。

一个典型的 provider 结构，我更喜欢这样组织：

import {
  DataShareExtensionAbility,
  dataShare,
  dataSharePredicates,
  relationalStore,
  DataShareResultSet
} from '@kit.ArkData'

export default class NoteDataShareExt extends DataShareExtensionAbility {
  private store: relationalStore.RdbStore | null = null

  onCreate() {
    // 初始化数据库、校验配置、注册日志
  }

  async query(
    uri: string,
    predicates: dataSharePredicates.DataSharePredicates,
    columns: string[]
  ): Promise<DataShareResultSet> {
    // 1. 解析 URI
    // 2. 校验允许访问的列
    // 3. 根据业务规则执行查询
    // 4. 返回受控结果集
    throw new Error('demo')
  }
}

真正的项目里，我不会让页面代码直接承担这些判断。

DataShare 的核心价值，恰恰是把“共享”收口成一个边界层。

四、访问方的关键，不是 query，而是正确创建 Helper

访问方通常先根据 URI 创建 DataShareHelper。

import { dataShare, dataSharePredicates } from '@kit.ArkData'
import { common } from '@kit.AbilityKit'

async function createHelper(context: common.Context) {
  const uri = 'datashare:///com.example.notes/notes'
  const helper = await dataShare.createDataShareHelper(context, uri)
  return { uri, helper }
}

这一步我会额外做两件事：

helper 创建失败时，不直接让页面崩；
把 URI 和 helper 封装到 repository，而不是到处 new。

因为一旦业务开始变复杂，页面里直接操作 DataShareHelper 会非常难维护。

我的建议是做一层 SharedNoteRepository，把对外共享数据的访问全部收起来。

五、查询时不要“SELECT * 思维”

DataShare 支持谓词查询，工程上最有价值的地方，是你可以明确限制条件和列。

async function queryRecentNotes(
  helper: dataShare.DataShareHelper,
  uri: string
) {
  const predicates = new dataSharePredicates.DataSharePredicates()
  predicates.equalTo('status', 'active')

  const columns = ['id', 'title', 'updateTime']
  const resultSet = await helper.query(uri, predicates, columns)
  return resultSet
}

这里有一个很值得强调的习惯：共享接口返回的数据越少越好。

不是因为性能，而是因为边界。

对方只需要标题和更新时间，就不要顺手把正文、内部状态、同步标记一起带出去。

数据共享设计里，字段本身就是权限。

六、增删改查真正难的，是校验而不是调用

对于 insert / update / delete，调用代码往往不长。

真正难的是：你允许别人改什么？

比如一个共享笔记服务可以规定：

访问方可以新增标题和正文；
不允许写内部同步字段；
update 只能更新指定 ID；
delete 必须满足调用方身份和业务条件；
某些字段只能提供方内部生成。

如果这些规则不放在 provider 里，DataShare 很容易变成一个过度开放的入口。

所以我会专门做字段白名单：

const writableFields = new Set(['title', 'content', 'tag'])

function sanitizeValues(values: Record<string, Object>) {
  const result: Record<string, Object> = {}
  Object.keys(values).forEach(key => {
    if (writableFields.has(key)) {
      result[key] = values[key]
    }
  })
  return result
}

这段代码技术含量不高，但工程价值非常高。