HarmonyOS 应用实战 82：导入冲突别只看题库名：用 sourceId 和摘要判断重复

只按牌组名判断冲突，会把同名不同内容、改名同内容两类情况混在一起。这个问题不能只靠页面上补一个提示解决，因为真正的断点在 libraryHSP/src/main/ets/utils/DeckImport.ets、状态字段和服务 owner 之间。下面按现有工程事实展开：先看源码，再说明风险链路，最后给出可以落地的补强方式。

在这里插入图片描述

这篇解决什么：导入冲突

角度 结论 落点
当前事实 导入工具负责把分享文本解析为牌组名称和答案列表。 libraryHSP/src/main/ets/utils/DeckImport.ets
主要风险 只按牌组名判断冲突，会把同名不同内容、改名同内容两类情况混在一起。 冲突判断需要内容指纹：名称只是展示字段，答案集合才决定是否重复。
补强方向 ImportConflictState 解析阶段计算 answerHash，保存阶段才根据用户选择写入。
页面责任 导入冲突 页面展示冲突原因，避免把同名不同内容直接覆盖。

对 导入冲突 来说，这张表先把边界固定住：当前事实来自 libraryHSP/src/main/ets/utils/DeckImport.ets，风险落在 冲突判断需要内容指纹：名称只是展示字段，答案集合才决定是否重复。，补强方案只围绕 ImportConflictState 展开，不把问题扩散成泛泛的 HarmonyOS 状态管理讨论。

现有代码锚点：导入冲突 对应 libraryHSP/src/main/ets/utils/DeckImport.ets

下面这段来自 The_Book_of_Answers 当前工程，锚点是 export function parseDeckImport。它不是装饰性引用，而是判断这篇文章能不能落地的依据。

0022 /** 把题库序列化为 名#a1#a2 格式，用于分享到剪贴板 */
0023 export function composeShareText(name: string, answers: string[]): string {
0024   const cleaned: string[] = answers
0025     .map((a: string): string => a.trim())
0026     .filter((a: string): boolean => a.length > 0);
0027   return [name.trim(), ...cleaned].join('#');
0028 }
0029 
0030 export function parseDeckImport(raw: string): ParseResult {
0031   const text: string = (raw ?? '').trim();
0032   if (!text) {
0033     const r: ParseResult = { ok: false, error: '导入文本不能为空' };
0034     return r;
0035   }
0036   const parts: string[] = text.split('#').map((p: string): string => p.trim());
0037   if (parts.length < 1 + MIN_ANSWERS_PER_DECK) {
0038     const r: ParseResult = {

这段代码说明：导入工具负责把分享文本解析为牌组名称和答案列表。 所以后续补强不能绕开这个事实；如果把 导入冲突 直接写成页面局部变量，第一次交互可能看起来没问题，跨页面、重进或发布回归时就会暴露。

失败链路：问题通常不是突然出现

只按牌组名判断冲突，会把同名不同内容、改名同内容两类情况混在一起。

环节 内容 排查动作
触发点 解析导入文本 确认输入来自哪里
断点 冲突判断需要内容指纹：名称只是展示字段，答案集合才决定是否重复。 确认服务层有没有拦住
外显现象 导入覆盖了旧牌组 确认页面有没有清楚反馈

这张断点表是给 导入冲突 做回归时用的。先复现触发点，再检查 冲突判断需要内容指纹：名称只是展示字段，答案集合才决定是否重复。 是否存在，最后看用户能不能从 导入覆盖了旧牌组 这种现象里得到下一步动作。

先排除误区：导入冲突 不是页面补丁

遇到 导入冲突，最容易犯的错是先在页面里加一个局部状态，让当前场景看起来正常。这个做法短期能遮住现象，但不会处理 导入覆盖了旧牌组 这类断点。

临时做法 看起来解决了什么 后续会留下什么
页面里直接改 @State 当前界面刷新了 服务和仓储没有真实状态
保存失败后直接返回 用户看不到报错 数据可能没有写入
每个入口各写一份判断 某个页面正常 其他入口继续出错
只看成功路径 操作流程很顺 失败分支无法复现 
function unsafeHandleArticle82(reason: string): void {
  if (!reason) {
    return;
  }
  promptAction.showToast({ message: reason });
  // 只提示不收口，下一次进入仍可能遇到同一个 导入冲突 问题。
}

这段反例的目的不是讲语法，而是提醒边界：导入冲突 的根因要回到 解析阶段计算 answerHash，保存阶段才根据用户选择写入。，页面只能表达反馈，不能替服务层决定数据是否已经可靠。

在这里插入图片描述

按照图里的顺序看，真正要拦住的是这一句：冲突判断需要内容指纹：名称只是展示字段，答案集合才决定是否重复。 只要这个点没有收口，用户看到的现象就会在刷新、保存、返回、导入或发布时反复变化。

责任边界：导入冲突 不该由谁兜底

DeckImport 产出指纹，DeckService 按指纹和名称决定新增、覆盖或另存。

层级 应该负责 不应该负责
页面 页面展示冲突原因，避免把同名不同内容直接覆盖。 直接改底层 key 或吞掉失败
服务 解析阶段计算 answerHash，保存阶段才根据用户选择写入。 让每个页面复制一套规则
仓储/配置 只保存和读取真实数据 理解页面交互语义

排查 导入冲突 时先问 owner，再问信号，最后才看样式。像 导入覆盖了旧牌组，通常不是单纯的 UI 细节，而是 只用名称判断冲突 没被服务层收住。

状态模型：ImportConflictState

建议把这件事压成一个明确模型。下面代码是建议补强，不表示当前工程已经存在同名接口。

interface ImportConflictState {
  name: string; // 导入牌组名
  answerHash: string; // 答案内容指纹
  matchedDeckId: string; // 命中的本地牌组
  resolution: 'skip' | 'replace' | 'saveAs'; // 用户选择的处理方式
}

function createImportConflictState(input: Partial<ImportConflictState>): ImportConflictState {
  return {
    name: input.name || '',
    answerHash: input.answerHash || '',
    matchedDeckId: input.matchedDeckId || '',
    resolution: input.resolution || 'skip',
  };
}

ImportConflictState 至少要能回答三个问题：输入从哪里来、失败怎么表达、成功之后谁刷新。字段少一点没关系，但不能让页面靠猜来决定 页面展示冲突原因，避免把同名不同内容直接覆盖。。

提交顺序：导入冲突 要先有提交点

把状态模型写出来以后，还要约束提交顺序。否则接口名字很好看，实际调用仍可能在页面、服务和仓储之间来回绕。

  1. 页面先收集用户动作，只生成 ImportConflictState 或等价输入。
  2. 服务读取必要的当前状态，执行 解析阶段计算 answerHash，保存阶段才根据用户选择写入。。
  3. 通过边界后再写仓储、Preferences 或运行时信号。
  4. 页面根据结果展示成功、失败、刷新或恢复入口。
async function submitArticle82(state: ImportConflictState): Promise<void> {
  const result: ImportConflictStateResult = await commitImportConflictState(state);
  if (!result.ok) {
    ImportConflictStateNotice(result.reason);
    return;
  }
  AppStorage.setOrCreate('article82ChangedAt', result.changedAt);
}

这个顺序的价值在失败分支。只要 导入冲突 没通过服务闸门，就不应该提前写入运行时信号，也不应该让页面表现得像已经保存成功。

服务闸门：先判断能不能提交

导入冲突 的服务层应该先判断边界，再执行写入或刷新。下面的写法把 reason 返回给页面，是为了让 重复导入出现多份 能被解释，而不是只弹一个“失败”。

interface ImportConflictStateResult {
  ok: boolean;
  reason: string;
  changedAt: number;
}

function explainImportConflictState(state: ImportConflictState): string {
  if (!state.name) {
    return 'name 不能为空';
  }
  return '';
}

async function commitImportConflictState(state: ImportConflictState): Promise<ImportConflictStateResult> {
  const reason: string = explainImportConflictState(state);
  if (reason) {
    return { ok: false, reason, changedAt: Date.now() };
  }
  return { ok: true, reason: 'ready', changedAt: Date.now() };
}

这里的关键是：导入冲突 不满足边界时不要写仓储，也不要悄悄修改运行时状态。先返回原因，页面再决定展示刷新、重试、回退还是放弃入口。

页面接入：提示可以清楚，规则不要搬到 UI

页面要做的是把用户动作表达清楚。比如 页面展示冲突原因，避免把同名不同内容直接覆盖。，这类信息适合放到 UI；但真正的校验和写入顺序仍然应该在服务层。

@Builder
function ImportConflictStateNotice(reason: string) {
  if (reason) {
    Column({ space: 8 }) {
      Text('导入冲突')
        .fontSize(16)
        .fontWeight(FontWeight.Medium)
      Text(reason)
        .fontSize(13)
        .fontColor(AppColor.danger)
    }
    .padding(12)
    .border({ width: 1, color: AppColor.danger })
    .borderRadius(AppRadius.md)
  }
}

这种接入方式对 导入冲突 有一个好处：页面可以保持轻量，服务仍然是规则 owner。以后再加列表页、设置页、恢复页或发布回归，也不用围绕 ImportConflictState 复制判断条件。

结构收口：从源码到验证只走一条线

在这里插入图片描述

导入冲突 的结构图要能互相对应：源码锚点证明当前事实，ImportConflictState 描述新增边界，服务规则决定提交方式，验证点证明 同名同内容应提示已存在，可跳过。 没有被吞掉。

验证路径：成功和失败都要跑

序号 验证点
1 同名同内容应提示已存在，可跳过。
2 同名不同内容应要求用户选择覆盖或另存。
3 不同名同内容应提示重复内容，默认跳过。
4 选择另存时，新牌组名称不能覆盖原牌组。 
Write-Host "查看 导入冲突 的源码锚点"
rg -n "export\ function\ parseDeckImport|ImportConflictState" "D:\ProgramData\huawei\lesson\The_Book_of_Answers\libraryHSP\src\main\ets\utils\DeckImport.ets"

Write-Host "查看相关状态字段"
rg -n "name|answerHash|matchedDeckId|AppStorageKey|AppPrefKey|StorageLink|updatedAt" "D:\ProgramData\huawei\lesson\The_Book_of_Answers"

这些命令只能检查 导入冲突 的源码落点和关键字段，不代表已经完成真机交互。涉及 同名同内容应提示已存在，可跳过。 这种场景时，还需要在 DevEco/设备侧补完整流程验证。

负向回归：导入冲突 要故意跑坏一次

只跑成功路径很容易误判。导入冲突 至少要准备一组负向样本，让服务层证明它会拒绝错误输入，而不是靠页面刚好没有触发问题。

负向样本 期望反应 说明
缺少 name 返回明确原因，不写仓储 验证主输入不是默认通过
触发 导入覆盖了旧牌组 保留当前页面状态 验证失败分支不会静默返回
模拟 没有识别同内容 页面显示下一步动作 验证用户能继续处理
重复执行提交 结果保持一致 验证服务闸门能承受重进 
async function runNegativeArticle82(state: ImportConflictState): Promise<string> {
  const result: ImportConflictStateResult = await commitImportConflictState(state);
  if (result.ok) {
    return 'unexpected success';
  }
  return result.reason;
}

这组负向样本能把 导入冲突 从“看起来能用”推进到“失败时也能解释”。写文章时把这部分放出来，读者才能按自己的工程复现。

常见问题：先定位断点

现象 常见原因 优先检查
导入覆盖了旧牌组 只用名称判断冲突 加入 answerHash
重复导入出现多份 没有识别同内容 按标准化答案计算指纹
用户不知道差异 冲突原因没展示 显示名称冲突和内容冲突

遇到 导入冲突 的异常时不要先改样式。先确认是哪一层没有交接：页面是否保留 name，服务是否统一处理规则，仓储或配置是否留下旧值，运行时信号是否发出。

落地顺序：先最小闭环，再补体验

  1. 在 libraryHSP/src/main/ets/utils/DeckImport.ets 附近确认当前链路，避免改错文件。
  2. 增加 ImportConflictState 或等价状态模型，字段只保留能解释失败的部分。
  3. 把 导入冲突 的规则放到服务层，页面只展示原因和下一步动作。
  4. 跑成功路径和失败路径，特别是 同名同内容应提示已存在，可跳过。。
const regressionForArticle82: string[] = [
  '同名同内容应提示已存在，可跳过。',
  '同名不同内容应要求用户选择覆盖或另存。',
  '不同名同内容应提示重复内容，默认跳过。'
];

收口

导入冲突 的处理方法可以压成一句话：DeckImport 产出指纹，DeckService 按指纹和名称决定新增、覆盖或另存。 当前工程已经有可依赖的源码基础，文章里的新增接口和函数属于建议补强；真正落地时，优先保持 owner 清楚，再补页面反馈。

结论 内容 边界
可以直接复用 导入工具负责把分享文本解析为牌组名称和答案列表。 libraryHSP/src/main/ets/utils/DeckImport.ets
建议新增 ImportConflictState 解析阶段计算 answerHash，保存阶段才根据用户选择写入。
暂不声明 真机行为、CSDN 上传、发布结果 没有实际执行就不写成已完成
数属于建议补强；真正落地时，优先保持 owner 清楚，再补页面反馈。
结论 内容 边界
可以直接复用 导入工具负责把分享文本解析为牌组名称和答案列表。 libraryHSP/src/main/ets/utils/DeckImport.ets
建议新增 ImportConflictState 解析阶段计算 answerHash，保存阶段才根据用户选择写入。
暂不声明 真机行为、CSDN 上传、发布结果 没有实际执行就不写成已完成
Logo
HarmonyOS开发者社区

讨论HarmonyOS开发技术，专注于API与组件、DevEco Studio、测试、元服务和应用上架分发等。

更多推荐

cover

HarmonyOS NEXT AI 智能生活助手：Provider 扩展机制

avatar HarmonyOS开发者社区
cover

HarmonyOS NEXT AI 智能生活助手：源码解析与项目复盘

avatar HarmonyOS开发者社区
cover

给同事发了个鸿蒙APP，结果安装失败了？这份避坑指南请收好

avatar HarmonyOS开发者社区