HarmonyOS 7 动态reuseId真正生效后：一行一个ID可能把复用池分碎

列表以前滚动很顺，升级后发现可复用组件创建得更多。检查代码时，reuseId回调返回的是每条数据的唯一ID。这段代码以前就存在，为什么现在才有影响？因为旧行为可能没有使用那个动态返回值，而是退回组件名称；API26开始真正采用回调的结果。

这篇不讨论全局复用池放在哪，而是讨论“进入哪个复用分组”。同一个组件返回不同ID可能不再相互复用，不同组件返回同一个ID又可能开始相互复用。前者容易碎片化，后者容易越过原本没有设计好的复用边界。

官方Beta1变更页更新于2026年8月19日，本文9月28日核对。下文分组和碰撞检查代码已在宿主运行；没有API26设备创建次数或帧率实测，因此不提供虚构的性能提升百分比。

变化不是“必须写字符串字面量”

@ReusableV2相关能力起始API18。本次修正的是reuse属性里的reuseId：对于读取变量、调用方法等非显式返回字符串字面量的形式，旧行为的实际标识可能是自定义组件名；新行为使用回调返回值。官方汇总将其列为全部生效，不应自行增加target26隔离条件。

下面是符合文档形式的接入片段：

const textCardPool: string = 'article:text-card:v1';

@ReusableV2
@ComponentV2
struct TextCard {
  build() { Text('示例卡片') }
}

@Entry
@ComponentV2
struct ReuseIdCheck {
  build() {
    Column() {
      TextCard().reuse({ reuseId: () => textCardPool })
      TextCard().reuse({ reuseId: () => textCardPool })
    }
  }
}

这只展示标识声明。两个组件同时显示不等于已经发生复用，实际验证要让组件退出并重新进入相应复用场景。也不能因为ID相同，就跳过可复用范围、生命周期和状态重置检查。

案例一：数据ID很稳定，但不适合做复用分组

一百条同结构文本卡片，每条记录都有唯一ID。数据ID适合区分记录；复用ID应表达哪些组件可以共享复用关系。如果把前者直接作为后者，一百条数据就可能形成一百个标识，原本同类卡片之间的复用机会被拆散。

下面的代码只计算标识数量，明确不是系统复用命中率模拟。它能在发布前发现“每个数据项都生成一份独立池名”的配置。

type RecordItem = { id:string; kind:'text'|'image' };
function poolId(item:RecordItem): string {
  return item.kind === 'text' ? 'feed:text-card:v1' : 'feed:image-card:v1';
}
function groups(items:RecordItem[], key:(item:RecordItem)=>string): Map<string,number> {
  const result = new Map<string,number>();
  for (const item of items) {
    const id = key(item);
    result.set(id,(result.get(id) ?? 0)+1);
  }
  return result;
}
function check(value:boolean): void { if (!value) throw new Error('assertion failed'); }
const items:RecordItem[] = Array.from({length:100},(_,i)=>({id:'row-'+i,kind:i%2===0?'text':'image'}));
const byRecord = groups(items,item=>item.id);
const byStructure = groups(items,poolId);
check(byRecord.size === 100);
check(byStructure.size === 2);
check(byStructure.get('feed:text-card:v1') === 50);
check(byStructure.get('feed:image-card:v1') === 50);

这不是说reuseId越少越好。图片卡片与文本卡片内部资源和结构不同，强行用同一个ID可能带来不必要的耦合。正确目标是让ID对应明确的复用契约，而不是追求数字最小。

ForEach的数据键与reuseId也不能相互替代。前者用于数据项识别，后者用于复用标识。把稳定的数据ID从ForEach里删掉，不能作为修复复用池碎片的方案。

案例二：两个模块碰巧用了同一个短ID

模块A和模块B都写了card。旧行为退回各自组件名，看起来互不影响；新行为开始采用card，两个本来独立的组件可能进入同一复用关系。官方明确列出了不同自定义组件因相同返回值而相互复用的变化。

在团队工程里，短字符串碰撞比复杂算法错误更常见。可以先让各模块登记组件名、复用ID和结构契约，再检查同一ID是否对应不同契约。

type Registration = { component:string; reuseId:string; contract:string };
function collisions(registrations:Registration[]): string[] {
  const contracts = new Map<string,Set<string>>();
  for (const row of registrations) {
    const set = contracts.get(row.reuseId) ?? new Set<string>();
    set.add(row.contract);
    contracts.set(row.reuseId,set);
  }
  return [...contracts].filter(([,set])=>set.size>1).map(([id])=>id).sort();
}
const bad:Registration[] = [
  {component:'PhotoCard',reuseId:'card',contract:'image-with-loader-v1'},
  {component:'TextCard',reuseId:'card',contract:'plain-text-v1'}
];
check(collisions(bad).join(',') === 'card');
const separated:Registration[] = [
  {...bad[0],reuseId:'media:photo:v1'},
  {...bad[1],reuseId:'feed:text:v1'}
];
check(collisions(separated).length === 0);
const intentional:Registration[] = [
  {component:'CompactText',reuseId:'feed:text:v1',contract:'plain-text-v1'},
  {component:'RegularText',reuseId:'feed:text:v1',contract:'plain-text-v1'}
];
check(collisions(intentional).length === 0);

contract只是团队自定义的审查字段。检查器相信你填的声明，不会验证两个组件真的结构兼容。它适合防止意外碰撞，不能证明有意共享一定正确。对有意共享的情况，仍要检查参数更新、订阅、图片请求和临时状态是否完整重置。

ID应该稳定到什么程度

建议由模块、组件结构类别和契约版本组成，避免直接带入行号、时间戳、随机数或每条记录ID。数据更新不改变结构时，通常不应换复用标识；结构契约发生不兼容变化时，则需要重新评估分组。

这里的v1是应用自己的命名约定，不是框架要求。也不应把每次发布版本号拼进去，导致所有组件在无结构变化时换组。ID必须能解释“为什么这两种组件允许共享”，而不是只保证字符串唯一。

ID方案	适合什么	主要问题
每条数据ID	识别数据，不是默认复用方案	容易分散复用关系
所有组件统一card	只有已验证共享契约时	容易跨模块碰撞
模块+结构+契约	明确分类的组件库	需要维护契约与重置逻辑

设备上如何证明真的修好了

准备同一批数据和固定滚动路径，分别记录创建、进入复用、重新使用以及数据更新的事件。先比较ID分布，再观察生命周期次数，最后测帧率和内存。不要把本文的100组变2组直接写成“创建次数减少98%”，两者不是同一个指标。

再加入图片加载未完成就滚出、重新出现时绑定另一条数据、主题切换和选择状态变化。复用率提升但显示旧图片、旧选中态，属于功能回归，不能算性能优化成功。

本次最容易忽略的地方，是旧代码里“写了但没真正生效”的动态ID如今开始生效。迁移不能只看新增API调用，还要检查旧配置的实际含义是否已经改变。

官方说明

• ReusableV2动态复用标识变更
• API26行为变化汇总