如果你在 Flutter 项目里维护过多端业务 ID 生成逻辑，又恰好把 App 移植到鸿蒙（OpenHarmony）上，大概率会遇到这个问题：同一个数据库里，Android 端产生的订单号是 36 位 UUID，鸿蒙端却只能用 21 位 nanoid，两边前缀、长度和字符集全对不上，服务端一合并就撞出脏数据。我这次把 Flutter 三方库 nanoid_plus 往 OpenHarmony 上做适配，目标就是让分布式唯一标识生成在三端完全一致，同时保证高并发下的安全性和性能。整个过程把适配路线、通信方案、验证方法都试过一遍，也踩了不少坑，这篇东西就是完整的实操记录，给同样在做鸿蒙 Flutter 化改造的团队一份可以照着抄的笔记。
1. nanoid 与 nanoid_plus：为什么业务 ID 生成要专门选它
1.1 UUID 的毛病：不是不能用，是不适合做业务主键
很多人一说唯一 ID 就反射性地用 UUID/UUID4，毕竟Random.uuidV4()一行代码，谁都会写。但在真正的业务场景里，UUID 的代价往往被忽略：它默认 36 个字符，作为数据库主键意味着更大的存储开销，InnoDB 这类聚簇索引下 UUID 的随机性还会把索引页拆得很碎，写入性能在数据量上来之后下降明显。更麻烦的是，UUID 的格式决定了它没法携带任何业务语义，一串550e8400-e29b-41d4-a716-446655440000既不能告诉客服这是哪个业务线的单子，也不能帮运营快速判断这是哪类单据。
还有一点经常被忽略：可预测性。UUID v1 的前半段直接编码了时间戳和节点信息，虽然不至于直接暴露订单量，但如果你的业务 ID 会出现在 URL 或者对外单据上，安全审计基本不会通过。UUID v4 虽然随机，但它在 Java/Dart 等语言里底层实现依赖的是伪随机数发生器，配置不当的话会成为碰撞隐患。所以在做订单号、物流单号、优惠券码这类对外可见的短 ID 时，我的第一选择从来不是 UUID，而是 nanoid。
1.2 nanoid 算法拆解：掩码映射、字符集与均匀分布
nanoid 的核心思路很简单：从安全随机源取字节，再把字节映射到一套 URL 安全的字符集上，默认字符集是A-Za-z0-9-_共 64 个字符，默认长度 21 位。为什么是 21？因为 64 个字符每个携带 6 bit 熵，21 位就是 126 bit 的全局唯一性，已经超过了 UUID 的 122 bit，放在业务主键绰绰有余。
真正容易做错的是映射方式。很多人会写index = bytes[i] % alphabet.length，这在数学上是错的，因为 256 不是 64 的整数倍时，字符表末尾的几个字符出现的概率会略高于前面的字符，这就是模偏差。业务 ID 只需要几百上千条时看不出问题，但到百万级之后，某些字符的分布偏差会被放大，碰撞概率就不再是理论值了。nanoid 的标准做法是先算出mask = 2^k - 1，其中 k 是刚好能覆盖字符集长度的高位位数，然后用bytes[i] & mask取下标，结果如果超出字符集长度就丢弃这个字节、换下一个字节再试。这样每个字符的出现概率严格相等。
这个细节在鸿蒙适配时特别重要。因为一旦你跨端重写这套算法，Dart 侧和 ArkTS 侧只要有一端用%取模、另一端用掩码，两端生成的 ID 字符集分布就不一致，后续做字符直方图校验时一眼就能看出来。
1.3 nanoid_plus 比通用 nanoid 强在哪：前缀、随机源注入与性能
nanoid_plus 是在 nanoid 基础上做的增强版 Dart 实现。它最实用的改动是支持二进制的安全前缀：比如ord_、user_、refund_，前缀可以直接打上业务语义，而且在算法内部前缀是经过 base64 风格编码处理的，不会因为前缀里带了特殊字符导致输出的字符集被污染。
其次是随机源注入。通用 nanoid 默认用Random.secure()，但 nanoid_plus 支持传入自定义的Random实例或者一个异步随机流。这在鸿蒙上适配时是一个关键入口，后面章节我会讲怎么利用这个接口把随机源替换成鸿蒙系统加密框架的数据。
第三是性能。nanoid_plus 内部把随机字节按块处理，避免逐字符多次请求随机数，批量生成时的吞吐比逐字符调用的老版本 nanoid 高接近一倍。再加上它有customNanoId这类弹性接口，可以带自定义字符集和长度，做短码、优惠码、邀请码时不用另外维护一套模板。所以把它作为业务 ID 生成的唯一底座，短期内不需要再引入别的 ID 方案。
2. OpenHarmony 环境下的适配路线：选型比编码更影响工期
2.1 先判断一个 Dart 库能不能在 OpenHarmony 上直接跑
拿到 nanoid_plus 之后，第一件事不是写代码，而是做依赖体检。判断标准很简单：看这个库的依赖树里有没有触及平台能力。纯 Dart 库的依赖通常只涉及dart:core、dart:math、dart:async这些 VM 内置库，在鸿蒙的 Flutter 引擎上可以直接编译，因为 OpenHarmony 的 Flutter 运行时本身就是一个 Dart VM，语言层面的东西不会被平台卡住。
需要警惕的是两类依赖：一类是dart:io里的平台能力（比如文件、socket、进程），另一类是package:ffi/dart:ffi的原生库调用。我在检查 nanoid_plus 的依赖树时发现，它的核心逻辑本身是纯 Dart，但可选的fast_sha256等性能增强包在部分平台上会尝试加载 libsodium 这类本地共享库，而 OpenHarmony 系统里默认没有这些.so，FFI 加载会失败。好在这种失败通常是可降级的，包本身会回退到纯 Dart 实现，不影响 ID 生成，只影响极限性能。要是遇到强依赖原生库的包，那适配成本就完全不一样了。
所以第一阶段的结论是：nanoid_plus 本体可以直编，但安全随机源这一环我不放心。Dart 的Random.secure()在 OpenHarmony 的 JIT/AOT 模式下底层走的是平台熵源，不同系统版本的行为可能存在差异，而业务 ID 生成最怕的就是随机源退化导致 ID 可预测或者短时间重复。为了"安全高性能分布式唯一标识生成"这个目标，我决定不赌 VM 行为，把随机源主动替换成鸿蒙系统加密框架。
2.2 三条可行路线与横向对比
在 OpenHarmony 上给 Flutter 插件做适配，业界常规路线有三条。
第一条是纯 Dart 直编。把 nanoid_plus 当普通 Dart 依赖直接加进pubspec.yaml，只要能通过编译就不做任何改动。成本最低，跨端一致性最好，因为所有平台跑的完全是同一套逻辑。缺点是随机源不可控，以及 FFI 加速组件在 OpenHarmony 上无法生效。
第二条是 C++ 复用路线。把 nanoid 的 C/C++ 实现（比如开源社区的 nanoid C++ 改造版）通过 OpenHarmony 的 NAPI 封装成.so，Flutter 侧再通过dart:ffi调用。这条路性能上限最高，但需要交叉编译适配 OpenHarmony 的 ABI，还要在 ohos 工程里配置 CMake、处理符号导出，任何一个环境差异都可能卡住一周，适合已经有 C++ 构建链的团队。
第三条是 ArkTS 原生实现加 MethodChannel 桥接。在鸿蒙工程的 ArkTS 侧用cryptoFramework系统加密框架实现 nanoid 算法，Dart 侧通过 MethodChannel 发起调用。这条路保留了系统级安全随机源，代码量不大，且天然适配鸿蒙侧的架构规范。
三条路线的取舍我用一个表格整理过：
| 方案 | 实现成本 | 随机源安全等级 | 跨端一致性 | 维护成本 |
|---|---|---|---|---|
| 纯 Dart 直编 | 最低 | 依赖 VM 实现 | 完全一致 | 最低 |
| C++/NAPI 封装 .so | 高 | 高，可自行选型 | 需自测对齐 | 高 |
| ArkTS 原生 + MethodChannel | 中 | 高，系统加密框架 | 需统一参数与算法 | 中 |
2.3 我的最终选型：ArkTS 原生为主、纯 Dart 兜底
我最后选了第三条路线，加一层纯 Dart 兜底。理由有三点：第一，团队有明确要求，随机源必须来自系统级密码学接口，方便审计，cryptoFramework在 OpenHarmony 上就是这个位置的官方入口；第二，ArkTS 重写 nanoid 算法的代码量其实很少，核心循环不超过 40 行，花半天时间就能写完，比折腾 NAPI 构建链划算得多；第三，MethodChannel 万一在高版本引擎上不可用，Dart 兜底方案可以保证业务不中断，只是少了系统级随机源的强化。
这个组合的代价是每次生成 ID 都多一次 Dart 到 ArkTS 的桥接往返，单次延迟会上来，但后面第 5 章会讲怎么用批量预生成把这个问题压下去。选型阶段不要追求极致性能，先把全链路的正确性和一致性打通，性能优化永远可以后置。
3. 适配实战：从依赖体检到原生通道打通
3.1 第一步：依赖体检，把 nanoid_plus 的依赖树摸清楚
动手前先执行flutter pub deps --style=compact，把 nanoid_plus 的完整依赖树打出来。我在项目里看到的依赖主要分三类：fast_async、fast_random这类纯 Dart 工具库，可以直接信任；fast_sha256这类带 FFI 加速的库，需要确认它的加载失败是否能降级；还有coverage之类的测试依赖，不影响生产编译。
体检的关键动作是到 pub 缓存目录里打开这几个包的源码，全局搜索dart:ffi和DynamicLibrary.open。这一步不要偷懒，因为pub deps只会告诉你依赖关系，不会告诉你哪个包在运行时试图加载原生库。我在 fast_sha256 的源码里看到了 Linux 路径下的.so加载逻辑，但它的异常处理会把加载失败吞掉然后走纯 Dart 分支，所以最终结论是：nanoid_plus 主链路在 OpenHarmony 上不会因为 FFI 缺失而崩溃，可以进入下一步。
3.2 第二步：Dart 侧统一入口设计
不管底层走 MethodChannel 还是纯 Dart 兜底，业务侧只需要暴露一个稳定接口。我把参数固定为三件套：prefix（业务前缀）、size（ID 主体长度，默认 21）、alphabet（字符集，默认 64 个 URL 安全字符）。这里有一个容易踩的坑：nanoid_plus 不同版本的参数名不完全一致，有的版本 prefix 放在第一位，有的版本要求命名参数，所以统一入口时必须先用一个适配层包住第三方包，不要直接让业务代码散着调用。
Dart 侧实现的示意结构如下：
// business_id_generator.dart import 'package:flutter/services.dart'; import 'package:nanoid_plus/nanoid_plus.dart' as np; class BusinessIdGenerator { static const String _channelName = 'com.example.business/id_generator'; static const String _defaultAlphabet = 'ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789-_'; /// 优先走 ArkTS 原生通道，失败时降级为纯 Dart 实现。 Future<String> generate({ required String prefix, int size = 21, String? alphabet, }) async { try { final String? id = await MethodChannel(_channelName).invokeMethod<String>( 'generate', <String, Object?>{ 'prefix': prefix, 'size': size, 'alphabet': alphabet ?? _defaultAlphabet, }, ); if (id != null && id.isNotEmpty) { return id; } } catch (e) { // 通道不可用或原生侧抛错时，不中断业务 } return _dartFallbackGenerate(prefix: prefix, size: size, alphabet: alphabet); } String _dartFallbackGenerate({ required String prefix, required int size, String? alphabet, }) { // 兜底实现。注意字符集必须与原生侧完全一致， // 且这里的随机源使用 Random.secure()，仅在通道不可用时启用。 final random = Random.secure(); final chars = (alphabet ?? _defaultAlphabet).split(''); final buffer = StringBuffer(prefix); for (var i = 0; i < size; i++) { buffer.write(chars[random.nextInt(chars.length)]); } return buffer.toString(); } }注意兜底实现我用了nextInt取模，严格来说这会有模偏差，但它只是临时降级路径。如果对分布均匀性有强迫症，兜底逻辑里也请实现掩码过滤，代码会多七八行，但更稳妥。
3.3 第三步：ArkTS 侧重写 nanoid 核心算法
ArkTS 侧的关键是拿到系统级安全随机字节。OpenHarmony 的@ohos.security.cryptoFramework提供了createRandom()接口，调用generateRandom(size)返回的就是Uint8Array格式的随机字节。我基于这个接口实现了 nanoid 算法：
// NanoIdArkTS.ets import cryptoFramework from '@ohos.security.cryptoFramework'; const DEFAULT_ALPHABET = 'ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789-_'; export class NanoIdArkTS { /** * 生成带前缀的 nanoid。 * @param prefix 业务前缀，例如 ord_ * @param alphabet 字符集 * @param size ID 主体长度，总长度 = prefix.length + size */ static async generate( prefix: string, alphabet: string = DEFAULT_ALPHABET, size: number = 21, ): Promise<string> { const random = cryptoFramework.createRandom(); const mask = this.calcMask(alphabet.length); const id = prefix; let filled = 0; // 随机字节不够的时候循环补取，保证最终恰好生成 size 个字符 while (filled < size) { const blob = await random.generateRandom(size); const bytes = new Uint8Array(blob.data); for (let i = 0; i < bytes.length && filled < size; i++) { const index = bytes[i] & mask; if (index < alphabet.length) { id += alphabet[index]; filled++; } } } return id; } private static calcMask(alphabetSize: number): number { // 取 2^k - 1，其中 2^k 是刚大于等于 alphabetSize 的 2 的幂 let k = 0; let power = 1; while (power < alphabetSize) { power *= 2; k++; } return power - 1; } }这段代码有几个细节要特别说明。一是掩码计算不要用log2加ceil的公式，浮点误差在字符集长度恰好是 64 时容易算出 63 的 mask，一旦字符集长度不是 2 的幂，公式很容易差一位。我在重写时直接用整数循环，稳得多。二是随机字节可能大量落入越界区间，比如字符集长度 57 时，mask 是 63，越界概率接近 10%，所以必须循环补取字节直到凑满 size 个字符。三是我没有用index = bytes[i] % alphabet.length，就是因为前面讲的模偏差问题，生成短 ID 时看不出差异，生成百万级数据后字符分布直方图会暴露。
3.4 第四步：MethodChannel 注册与参数协议设计
鸿蒙侧注册通道需要拿到 BinaryMessenger 实例，不同版本的 flutter_ohos SDK 获取方式略有差别，常见的是在 MainAbility 或者插件初始化阶段通过引擎对象取。通道名必须和 Dart 侧完全一致，否则 invokeMethod 会静默失败，这个错误不会抛异常，而是直接返回 null，容易误判成生成器返回空字符串。
// id_generator_plugin.ets import { MethodChannel, MethodCall, BinaryMessenger } from '@ohos/flutter_ohos'; export function registerIdGenerator(binaryMessenger: BinaryMessenger): void { const channel = new MethodChannel( binaryMessenger, 'com.example.business/id_generator', ); channel.setMethodCallHandler(async (call: MethodCall): Promise<Object> => { if (call.method !== 'generate') { return; } const args = call.arguments as Record<string, Object>; const prefix = args['prefix'] as string; const size = args['size'] as number ?? 21; const alphabet = args['alphabet'] as string | undefined; const id = await NanoIdArkTS.generate( prefix, alphabet ?? DEFAULT_ALPHABET, size, ); return id; }); }协议设计有两个心得：一是所有参数都放在 Map 里，不要用位置参数，因为 MethodChannel 的编解码对类型敏感，位置参数错了很难排查；二是 alphabet 原样透传即可，不需要在原生侧解析 JSON 字符串，因为 codec 对字符串做了透明传输，特殊字符也不会丢失。
3.5 兜底策略和异常边界处理
原生通道可能出现的问题不只是初始化失败，还有generateRandom偶发超时、系统低电量时熵源响应变慢等。我的建议是 Dart 侧兜底不只在 catch 中触发，还要设置一个超时时间，比如原生调用超过 2 秒就自动切到 Dart 兜底，避免业务线程卡死。实测中这个超时场景不常见，但上线后总会有用户设备处于极端状态，兜底路径就是最后一道保险。
兜底实现的随机源用Random.secure()，字符集和长度必须跟 ArkTS 侧一致。这里特别要检查有没有人把兜底实现的字符集写错了，比如少了-或_，一旦出现会导致同一业务前缀下两端生成的 ID 字符集不交集，服务端按字符集做校验时会把所有原生通道 ID 判为非法。
4. 跨端格式一致性：随机源、字符集与字节序的坑
4.1 输出格式一致性验收标准
适配完成后第一件事不是看性能，而是验证三端输出的 ID 格式完全一致。我定义了一套校验规则：前缀固定、主体长度固定、每个字符都属于预设的 64 字符白名单。用一个正则就能覆盖：
final idPattern = RegExp(r'^ord_[A-Za-z0-9_-]{21}$');正则只是第一步，第二步是拉一批真实数据做字符级分布检查。Android、iOS、鸿蒙三端各生成 1 万条带ord_前缀的 ID，统计每个字符在 21 个位置上的出现次数。如果算法实现正确，每个字符的期望频率大致相等，出现 1.5 倍以上偏差的字符基本可以断定算法有问题。我在实际操作中发现，跨端最容易出现的问题不是算法本身，而是有人把size理解成"总长度"，导致 prefix 长度参与计算，结果鸿蒙端生成了ord_加 25 位主体，Android 端却是 21 位主体，服务端合并时长度校验直接挂掉。
4.2 随机源差异：安全级别不同，但格式必须一致
很多人有个误解：既然三端用同一个 nanoid_plus 包，IDE 里跑出来的 ID 样子肯定一样。实际上随机源的选择不影响格式，只影响熵的质量和可预测性，所以两端哪怕一个用真随机一个用伪随机，只要字符映射算法一致，输出格式仍然完全相同。这就是为什么格式一致性校验能通过，不代表随机源安全级别达标——必须单独检查鸿蒙端是否真的走了cryptoFramework。
我在测试阶段做了一个隐患复现：把 ArkTS 侧的generateRandom临时替换成Math.random()生成的字节，格式校验照样全绿，但 ID 的熵值会掉到非常低。所以在验收清单里加一项：拿到鸿蒙侧生成的连续 200 条 ID，检查是否有递进、重复、可预测特征。真实的系统加密随机源不会出现这种事，出现就一定是你哪条链路被降级了。
4.3 字节序与 Uint8Array 转换的隐蔽坑
字节序这个坑我差点踩进去。ArkTS 的generateRandom返回的DataBlob.data是 Uint8Array，按字节索引取数没有任何大小端问题。但如果你图方便把字节序列转成 Int32Array 或者拿去和其他整型数据混算，大端小端就会把 ID 的字符映射彻底打乱。Android 设备基本是 ARM 小端，鸿蒙设备也以小端为主，但 OpenHarmony 可以跑在 x86 模拟器上，同样源码在小端机器上正常，在 x86 上可能所有 ID 的尾字符全部异常。
我的处理原则是：随机字节从取出来到最后掩码映射，全程保持 Uint8Array 单字节操作，不允许中途做任何整型转换。这一点也写进了团队的代码规范，避免后面有人优化时把类型改掉。桥接层唯一允许的数据交换类型是字符串、数字和 Map，任何二进制的字节序列都不要直接通过 MethodChannel 传递，因为 codec 虽然支持 Uint8List，但两端类型映射在鸿蒙 SDK 的不同版本里有过不兼容的记录。
5. 高并发实测：瓶颈在桥接不在算法
5.1 实测环境与方法设计
我跑了三组基准测试，环境是 RK3568 平台的 OpenHarmony 开发板，Flutter SDK 使用 OpenHarmony 适配版本。测试方式很简单：Dart 侧循环调用BusinessIdGenerator.generate生成 10 万条带前缀 ID，统计总耗时、单次平均耗时、p99 耗时。对照组是跳过 MethodChannel 直接调用纯 Dart 兜底实现，用来量化桥接层的开销。
这个测试设计有个容易忽略的点：必须把首次初始化和预热排除掉。MethodChannel 首次建立连接时，通道初始化和原生 Handler 注册会有额外开销，如果拿前几毫秒的数据算平均，会显得桥接特别慢。我习惯先跑 100 次 warmup，再开始正式统计。
5.2 数据结果与瓶颈定位
测试数据总结如下：
| 方案 | 平均单次耗时 | p99 耗时 | 10 万条总耗时 |
|---|---|---|---|
| 纯 Dart 兜底实现 | 约 6 us | 约 18 us | 约 0.6 s |
| MethodChannel + ArkTS cryptoFramework | 约 230 us | 约 480 us | 约 23 s |
这个结果在预期之中：单次生成 230 微秒对绝大多数业务场景完全够用，但如果你要在启动阶段成批生成几百个 ID，23 秒是绝对不可接受的。定位瓶颈时我做了个中间实验，把 ArkTS 侧generateRandom回调里加计时的逻辑，发现接近 170 微秒耗在 Dart 到 ArkTS 的桥接往返上，cryptoFramework 取 21 个随机字节本身只要几十微秒。所以结论很清晰：延迟的瓶颈是桥接，不是算法。
5.3 批量预生成缓存池：把桥接开销摊薄
为了解决桥接延迟问题，我用了批预生成的策略。ArkTS 侧维护一个容量 200 的 FIFO 队列，后台一次性生成 200 个 ID 放进队列，Dart 侧调用时跟原生侧做一次快速出队，队列低于水位线时再触发一批后台生成。
// id_pool.ets 核心思路 const POOL_CAPACITY = 200; const WARN_LINE = 50; const pool: string[] = []; let refilling = false; async function ensurePopulated(): Promise<void> { if (refilling || pool.length >= WARN_LINE) return; refilling = true; try { for (let i = 0; i < POOL_CAPACITY - pool.length; i++) { pool.push(await NanoIdArkTS.generate(/* 参数从调用侧传入 */)); } } finally { refilling = false; } }加了这个池子之后，Dart 侧取 ID 的平均延迟可以压到 10 微秒以下，代价是内存里最多缓存 200 个未使用的 ID，丢失后这些 ID 作废。业务场景上，订单号只要求全局唯一，不要求严格连续性，预生成 ID 不落库也不影响安全。但如果是券码这类需要防猜的 ID，预生成量就不要设太大，我建议保持在 50 以下，降低泄露风险。
5.4 去重与熵校验的闭环验证
性能测试做完后，我额外做了三端去重验证：Android、iOS、鸿蒙各生成 5 万条 ID，全部塞进一个 Set，元素的线程安全去重后数量正好是 15 万。然后随机抽样 1 万条做香农熵估算，21 位主体、64 字符集，理论熵是 126 bit，实测估算值在 124 bit 以上，说明随机源和映射算法都没有明显偏差。
这里要提醒一句：去重验证通过了，只能说明算法实现没有碰撞，不能说明多端一致性没有隐患。一定要保留一个"校验环境标志"，在测试包和正式包之间把兜底路径和原生路径的调用比例打印出来。我见过一个团队测试环境全走原生通道，线上因为原生通道注册失败全部走兜底，ID 格式虽然一致，但随机源降级了没人发现，后来拿到线上数据一算熵值明显偏低才定位到问题。
6. 适配过程中的几个高频问题和我的处理方式
6.1 MethodChannel 调用返回 null，又不报错
这是 Flutter 和原生侧联动时最常见的怪问题。Dart 侧invokeMethod返回 null，原生侧setMethodCallHandler看起来也设置了，但方法就是没被调用。排查思路是：先把通道名复制到原生侧和 Dart 侧做逐字符对比，检查有没有大小写或下划线差异；再看原生侧 Handler 是否在引擎初始化之前就注册了，如果注册时机太早，BinaryMessenger 还没准备好，消息会被直接丢弃。我在项目里踩的是第二种，解决办法是把注册动作放到 onLoad 完成之后，并打印一条注册日志。
6.2 dart:ffi 相关依赖在 OpenHarmony 上崩了怎么办
如果你不想像我一样绕道 ArkTS，坚持直编，那么在 OpenHarmony 上碰到 FFI 包崩溃的概率不低。处理顺序是：先确认崩溃栈是否来自DynamicLibrary.open的路径解析，再去补对应 .so 到 ohos 工程里，或者干脆用依赖替换把带 FFI 的包换掉。nanoid_plus 的情况比较温和，主算法不依赖 FFI，但如果你发现某个包强依赖原生库且没有降级路径，就不要硬上，直接换方案。
6.3 如何验证你的字符集和原生侧完全一致
字符集一致性是个橡皮筋问题，任何一端手滑多删一个字符，ID 格式校验可能要到生产环境才暴露。我给的实操建议是：把字符集作为常量写在 Dart 侧和 ArkTS 侧各一份，然后写一个启动自检，两端各生成一条 ID 做字符集判等，不一致时直接抛异常。这个自检的代码量很小，但对后续维护是长期保障。
写在最后
这次适配下来，我最大的体会是：跨端适配最耗时间的从来不是算法本身，而是选型时对平台能力边界的错误判断。nanoid_plus 其实可以直接跑在鸿蒙上，但为了保证安全随机源的可审计性，我还是选择花一天时间做了 ArkTS 原生通道。如果你的业务对安全级别要求没那么高，完全可以直接走纯 Dart 直编路线，省掉桥接层的所有维护成本。
最后再分享一个小技巧：如果后续还想进一步压性能，可以把 nanoid 的算法用 C++ 实现，通过 OpenHarmony 的 NAPI 封装成原生模块，Dart 侧只做参数透传。这样既能拿到系统级随机的安全度，又能把单次生成的延迟压到接近纯 Dart 的水平，只是构建链会复杂不少，适合已经具备 C++ 工程能力的团队去试。ID 生成看起来是个小功能，但在规模化业务里，它值得多花一点心思在方案底层的正确性上。
