Flutter for OpenHarmony：jose安全库完整适配指南

先说个背景。做Flutter开发的朋友应该都有体会，生态里各种现成的包能帮我们少写很多底层代码，尤其是安全这块。但当你把项目迁移到OpenHarmony（鸿蒙开源底座）上时，很多原来在Android/iOS上跑得好好的库，一编译就报错，不是不支持这个API，就是那个依赖在OHOS上没实现。我这次遇到的就是一个安全加密库jose的适配问题——它是Dart生态里做JWT/JWS/JWE的全能选手，几乎是做登录鉴权、数据签名、令牌加密绕不开的“瑞士军刀”。本文就从jose库的功能拆解出发，完整记录我在Flutter for OpenHarmony下移植、编译、跑通的整个过程，包括算法选型、密钥管理、与ArkTS侧的通信方案，以及踩过的几个大坑。

1. 为什么OpenHarmony需要“安全瑞士军刀”

1.1 鸿蒙三方生态的安全库缺口

先聊一个扎心的事实。OpenHarmony的SDK、IDE、设备适配这两年进展很快，但三方开源库的丰富度跟Android/iOS比还是有明显差距。尤其安全领域，你想找一个好用的JWT签发验证库、一个支持JWE加密的通用库，很难。因为没有像Java生态的jjwt、Nimbus JOSE+JWT那样的成熟选择，ArkTS侧很多时候需要自己拿@kit.CryptoArchitectureKit（也就是鸿蒙的加解密能力）手动拼HMAC、手动拼Base64Url，不仅代码量上去了，出错概率也高。

还有人提过用系统NAPI封装C/C++的OpenSSL库，但这对普通业务开发者来说门槛太高，得写C++、得管理Native生命周期、还得做内存安全。而Flutter for OpenHarmony的成熟，正好给了一个新解法：Dart侧有大量成熟的纯逻辑库，可以跨端复用，我们只需要解决平台通道和底层依赖的适配。

1.2 jose是什么，能做什么

jose是Dart语言写的一套安全库，覆盖了现代Web安全里最常用的三件套：

• JWT（JSON Web Token）：用于无状态令牌，登录态、接口鉴权都靠它。
• JWS（JSON Web Signature）：负责对数据进行签名，保证完整性和不可抵赖性。
• JWE（JSON Web Encryption）：负责对数据进行加密，保证机密性。

三者的关系可以这样理解：JWT是“包装盒”，里面可以装JWS签名的数据，也可以装JWE加密的数据；JWS是“防拆贴”，别人改了内容一看就知道；JWE是“保险箱”，内容压根不让人看，只有持有钥匙的人才能打开。实际业务里，登录接口返回token一般用JWS，传输敏感个人信息时用JWE，如果需要无状态会话就用JWT做载体。

jose这个库强就强在：它把这三套标准全实现了，算法覆盖也全，从对称的HS256/HS384/HS512，到非对称的RS256、PS256、ES256、EdDSA，再到加密用的RSA-OAEP、A256GCM、dir模式、ECDH-ES协议，基本全都有。你不需要再分别找三四个库来组合，它一个包全给你解决。

1.3 为什么选择Flutter for OpenHarmony这条路

在OpenHarmony上做业务，实际上有三条技术路线：

1. 纯ArkTS开发，完全用鸿蒙原生能力。
2. C/C++写NAPI插件，给ArkTS调底层库。
3. Flutter for OpenHarmony，用Dart/Flutter写跨端UI和业务逻辑。

纯ArkTS的问题在于三方库太少，很多通用逻辑要重造轮子；NAPI插件的问题是开发成本高，要处理跨语言边界；而Flutter for OpenHarmony虽然有性能开销，但好在跨端复用率极高，如果你本身就有Flutter端的App，迁移到鸿蒙是成本最低的。

安全库这类“纯逻辑+少量IO”的代码，特别适合放在Flutter层。它不涉及复杂的原生UI交互，只需要在最后把加密结果抛给ArkTS调用方即可。所以我们团队最终决定：核心加密逻辑用jose写，放在Flutter的Dart层，通过MethodChannel暴露给上层ArkTS使用。这样以后Android/iOS/鸿蒙三端逻辑完全统一，改一套代码，三端生效。

2. jose库核心能力拆解：JWT/JWS/JWE

2.1 模块总览与设计哲学

jose库的设计思路是“围绕标准JSON结构做类型安全封装”。它没有用一堆散落的函数，而是通过JsonWebToken、JsonWebSignature、JsonWebEncryption这几个核心类来组织能力。

从使用方式上看，jose分两个层次：

• 低层API：直接操作JsonWebSignature和JsonWebEncryption，适合自己控制签名/加密流程。
• 高层API：直接用JWT相关的方法，传入payload和密钥，一行签发、一行验证。

这种分层对开发者很友好。如果是自己搭鉴权体系，就用高层API快速实现；如果是做特殊的安全协议，就用低层API精细控制。

我特别推荐看它的源码，写得非常清晰，每个算法的实现都有对应的标准文档标注，比如RFC 7515（JWS）、RFC 7516（JWE）、RFC 7519（JWT）等。这在排查算法细节问题时很有帮助。

2.2 JWS——签名与验签的底层机制

JWS的核心流程不复杂，但有几个细节容易踩坑。签名流程大致是：

1. 构造签名输入串，格式是Base64Url(Header) + "." + Base64Url(Payload)。
2. 用指定算法对签名输入串做签名。
3. 将签名结果、Header、Payload拼成最终的JWS Compact序列化格式。

在jose里，用HS256（对称HMAC）验签时，payload可以是Map（会被自动序列化成JSON），也可以是String（原样传递）。这里有一个容易忽略的点：如果payload类型是String，jose在解析时默认不按JSON处理，你需要自己判断并转类型。

验签时最关键的一点是：一定要先验签再解析payload。不要先把payload取出来用了，再去验签。否则伪造数据进入业务逻辑，等于签名白做。

还有算法混淆攻击的问题。老版本的JWT库经常出这个漏洞：签发时用RS256（非对称），攻击者把Header里的alg改成HS256（对称），然后用公钥当HMAC密钥去伪造签名。jose的新版本默认不允许在验签时切换非对称算法到对称算法，但我们自己写封装层时也要注意，别把算法类型搞混。

2.3 JWE——内容加密的密钥策略

JWE（JSON Web Encryption）相比JWS要复杂很多，因为涉及两套加密机制：密钥加密（Key Encryption）和内容加密（Content Encryption）。

以最常见的RSA-OAEP-256 + A256GCM组合为例：

• 随机生成一个256位的内容加密密钥（CEK）。
• 用接收方的RSA公钥通过RSA-OAEP-256加密这个CEK，生成JWE的Encrypted Key部分。
• 用CEK通过AES-GCM加密实际的数据，生成Ciphertext。
• 最后把Header、Encrypted Key、IV、Ciphertext、Auth Tag按Compact序列化拼接。

GCM模式自带完整性校验（Auth Tag），所以JWE不需要再额外叠加JWS就能防篡改。这一点很多新手没意识到，以为加密了就行，其实AES-GCM提供的Auth Tag就是完整性保证。

jose里还有一种dir模式，意思是不做密钥加密，直接把一个对称密钥既当CEK又当内容加密密钥。这种模式省掉了非对称计算，但要求通信双方提前安全地共享同一个密钥。内部服务间通信用dir + A256GCM很常见，速度极快。

2.4 JWT——令牌的生命周期管理

JWT在jose里是最上层的封装，把JWS或JWE作为底层载体。签发一个JWT非常简单：

dart复制final key = JsonWebKey.fromPem(pemContent); // 从PEM解析密钥
final jwt = JsonWebToken.sign(
  payload: {
    'sub': '1234567890',
    'name': 'Alice',
    'admin': true,
    'iat': DateTime.now().millisecondsSinceEpoch ~/ 1000,
  },
  key: key,
  algorithm: JwsAlgorithm.rs256,
);
print(jwt); // 输出JWT字符串

验签时如果带requiredTo校验过期时间：

dart复制final claims = await JsonWebToken.verify(
  token: tokenStr,
  key: key,
  requiredTo: ['exp', 'iat'],
);

这里我强烈建议在签发时至少带上iat（签发时间）、exp（过期时间）、sub（用户标识）这三个字段。exp千万别设太长，移动端token有效期控制在2小时以内比较安全，过期的token即使签名正确，服务端也必须拒绝。

jose还支持JWT的nbf（not before）字段，表示“在这个时间之前不可用”。如果你做灰度发布或者定时生效的逻辑，这个字段很好用。

3. Flutter for OpenHarmony 适配实战

3.1 开发环境准备

这一步是最容易劝退新手的，因为现有教程多而杂，版本匹配要求高。以我们团队当前稳定的环境为例：

• OpenHarmony SDK API 10及以上（建议API 12，能力更全）
• DevEco Studio 4.0及以上
• Flutter for OpenHarmony版本：openharmony-sig/flutter_flutter仓库的OHOS分支，对应Flutter 3.16.9版本
• Node.js 18+（构建hvigor工程时会用到）
• ohpm包管理器（鸿蒙的包管理工具）

在终端配置好Flutter的OHOS分支路径后，需要手动把flutter命令指向这个fork版本：

bash复制git clone -b oh-3.16.9 https://gitee.com/openharmony-sig/flutter_flutter.git
export PATH="$PWD/flutter_flutter/bin:$PATH"
flutter doctor

flutter doctor如果显示OpenHarmony相关的检查项通过，说明环境就绪了。注意不要直接用官方Flutter稳定版跑OHOS工程，会直接报找不到ohos平台。

3.2 为什么会卡在“编译期”而不是“运行期”

很多人以为跨平台库移植最怕的是运行期崩溃，但jose这个case恰恰卡在编译期。原因是jose内部依赖了dart:io的部分能力，比如Platform判断、SecureSocket相关逻辑。

在Flutter for OpenHarmony早期版本里，dart:io的支持还不完整，dart:io里的某些类直接就是未实现的stub，调用就抛UnsupportedError。jose包在构造某些密钥类型时会做平台判断，比如判断当前是Android还是iOS来抛不同的错误提示。这一判断在OHOS上不认识，虽然不至于崩溃，但会在解析密钥时走错分支。

解决办法有两个：

1. 用兼容层拦截，给jose一个假的Platform判断结果。
2. 改用conditional imports（条件导入），让Dart在OHOS平台上加载我们自写的适配实现。

第二个方案更干净。Dart支持根据dart.library.io、dart.library.js等条件选择导入文件。但OHOS上的Flutter本质上还是走dart.library.io分支，所以需要我们自己加一个编译宏区分。

具体做法可以参考我这个简化样例：

dart复制// jose_platform_selector.dart
import 'jose_platform_default.dart'
    if (dart.library.ohos) 'jose_platform_ohos.dart';

然后在jose_platform_ohos.dart里重写平台判断逻辑，返回我们自定义的OS类型。这样就不用去改jose包源码，可以始终依赖pub上的官方版本。

3.3 依赖裁剪：把不用的Native能力关掉

jose为了让RSA密钥、ECDSA密钥解析更完整，内部用到了package:pointycastle的一部分能力，而pointycastle是纯Dart实现，天然跨端，这一块在OHOS上没坑。

真正的坑在package:crypto和package:convert之外的“密码学随机数生成”。jose在生成IV、生成CEK时会调用Random.secure()，这个接口在Dart里底层依赖平台的安全随机数。Flutter for OpenHarmony是支持Random.secure()的，但如果你用的是直接基于Dart VM命令行的单元测试去跑纯Ohos环境，可能会碰到熵源不足的问题。我们的经验是：所有随机数相关的逻辑都放到Flutter Engine起来之后再调用，不要在原生入口处提前触发。

另外，在pubspec.yaml里可以把不需要的依赖做dependency_overrides，把jose用到但OHOS上较旧的包版本提升到兼容版本。比如pointycastle建议锁到3.7.3以上，修复了一些椭圆曲线解析的兼容问题。

3.4 与ArkTS侧的通道设计

既然加密逻辑放在Flutter层，上层ArkTS怎么调用？最稳妥的做法是创建一个Flutter插件工程，同时提供MethodChannel方法。

我实际项目的通道设计如下：

• signJwt：入参是pem私钥、payload Map、算法名，出参是JWT字符串。
• verifyJwt：入参是pem公钥、JWT字符串、校验项列表，出参是解密后的claims Map。
• encryptJwe：入参是pem公钥、明文、算法组合，出参是JWE字符串。
• decryptJwe：入参是pem私钥、JWE字符串，出参是明文。

ArkTS侧只需要通过@kit的Flutter模块调用channel，把字符串和Map传过去，结果用Promise或回调返回即可。这样上层完全不需要关心Dart实现细节。

4. 实操过程与核心代码实现

4.1 密钥生成与格式处理

先解决密钥从哪来的问题。生产环境一般由运维用OpenSSL生成RSA密钥对，然后通过配置文件注入到App或服务端。在Dart侧，我们需要把PEM格式的密钥转成jose能识别的JsonWebKey对象。

读取私钥的代码：

dart复制import 'dart:io';
import 'package:jose/jose.dart';

String loadPem(String path) {
  if (Platform.isLinux || Platform.isWindows || Platform.isMacOS) {
    return File(path).readAsStringSync();
  } else {
    // 在移动端/鸿蒙端，一般是将PEM内容打包进asset
    return rootBundle.loadString(path);
  }
}

JsonWebKey parseRsaPrivateKey(String pemContent) {
  final key = JsonWebKey.fromPem(pemContent);
  if (key.keyType != KeyType.rsa || key.isPrivate == false) {
    throw FormatException('Not an RSA private key');
  }
  return key;
}

这里有一个关键点：JsonWebKey.fromPem对PEM格式非常挑剔。它要求标准的-----BEGIN PRIVATE KEY-----（PKCS8格式）或者-----BEGIN RSA PRIVATE KEY-----（PKCS1格式）。如果你的密钥是--BEGIN RSA PRIVATE KEY--这种带额外换行符的，要提前预处理一下，去掉首尾多余空白，否则解析会失败。

推荐统一转成PKCS8格式再给jose：

bash复制openssl pkcs8 -topk8 -in original.key -nocrypt -out pkcs8.key

4.2 签发JWT并验签的完整示例

我用实际项目里的登录鉴权场景写一个可直接跑的示例。

假设服务端给客户端下发了RSA密钥对（私钥在服务端，客户端持有公钥），客户端要签发一个JWT证明自己的身份。为了避免私钥直接打进客户端安装包，我们通常由服务端签发后下发，客户端只负责验证。但有些离线场景（比如设备端生成自签名证书）确实需要在客户端持有私钥并签发，所以我们封装层两边都支持。

dart复制import 'package:jose/jose.dart';

// 持有私钥时签发JWT
Future<String> signJwtWithRsa({
  required String rsaPrivateKeyPem,
  required Map<String, dynamic> payload,
  String? issuer,
  Duration ttl = const Duration(hours: 2),
}) async {
  final key = JsonWebKey.fromPem(rsaPrivateKeyPem);
  final now = DateTime.now().toUtc();
  
  final claims = <String, dynamic>{
    ...payload,
    'iat': now.millisecondsSinceEpoch ~/ 1000,
    'exp': now.add(ttl).millisecondsSinceEpoch ~/ 1000,
  };
  if (issuer != null) {
    claims['iss'] = issuer;
  }

  final jwt = JsonWebToken.sign(
    payload: claims,
    key: key,
    algorithm: JwsAlgorithm.rs256,
  );
  return jwt;
}

// 持有公钥时验签
Future<Map<String, dynamic>> verifyJwtWithRsa({
  required String rsaPublicKeyPem,
  required String token,
  String? expectedIssuer,
}) async {
  final key = JsonWebKey.fromPem(rsaPublicKeyPem);
  try {
    final claims = await JsonWebToken.verify(
      token: token,
      key: key,
      requiredTo: ['exp', 'iat'],
    );
    if (expectedIssuer != null && claims['iss'] != expectedIssuer) {
      throw Exception('issuer mismatch');
    }
    return claims;
  } on JoseException catch (e) {
    // 统一包装成业务异常
    throw Exception('JWT verify failed: ${e.message}');
  }
}

这里面requiredTo特别好用，可以指定必须携带的字段，只要缺一个就直接抛异常。

4.3 JWE加密敏感数据的完整示例

JWE用于保护不想让服务端或中间人看到的字段，比如用户的手机号、身份证号、银行卡号等。下面这个示例展示了用RSA公钥加密、用RSA私钥解密的双向过程。

加密一段文本：

dart复制Future<String> encryptWithRsaPublicKey({
  required String publicKeyPem,
  required String plainText,
}) async {
  final publicKey = JsonWebKey.fromPem(publicKeyPem);
  final encryptor = JsonWebEncryption(
    payload: plainText,
    key: publicKey,
    protectedHeader: {
      'alg': 'RSA-OAEP-256',
      'enc': 'A256GCM',
    },
  );
  // 序列化成Compact格式
  final jwe = encryptor.toCompactSerialization();
  return jwe;
}

解密JWE：

dart复制Future<String> decryptWithRsaPrivateKey({
  required String privateKeyPem,
  required String jweCompactString,
}) async {
  final privateKey = JsonWebKey.fromPem(privateKeyPem);
  final decryptor = JsonWebEncryption.fromCompactSerialization(
    jweCompactString,
  );
  final plainText = await decryptor.decrypt(
    key: privateKey,
  );
  return plainText;
}

如果你只需要在服务端之间传递数据，用dir + A256GCM这种对称模式性能最好：

dart复制final jwe = JsonWebEncryption(
  payload: sensitiveData,
  key: sharedAesKey, // 注意这里传的是JsonWebKey，type是oct
  protectedHeader: {
    'alg': 'dir',
    'enc': 'A256GCM',
  },
);

注意dir模式下，密钥长度必须是256位（32字节），否则jose会拒绝加密。这个坑我们踩过一次，复盘原因是AES-256要求固定密钥长度，不像RSA能兼容多种密钥长度。

4.4 在ArkTS端集成Flutter插件

上面Dart侧的逻辑编成Flutter插件后，ArkTS侧调用非常简单。

初始化插件并注册MethodChannel：

ts复制import { FlutterManager, FlutterPluginManager } from '@kit.FlutterKit';

// 在ArkTS中获取Flutter引擎
const flutterEngine = await FlutterManager.getInstance().getFlutterEngine();
// 注册插件，内部会注册MethodChannel
await flutterEngine.getPluginManager().register(MyJosePlugin);

业务侧通过promise调用：

ts复制const josePlugin = new MyJosePlugin();
const jwt = await josePlugin.signJwt({
  pemKey: this.rsaPrivateKey,
  payload: {
    'sub': 'user_123',
    'role': 'admin',
  },
});
const claims = await josePlugin.verifyJwt({
  pemKey: this.rsaPublicKey,
  token: jwt,
  requiredTo: ['exp', 'iat'],
});

这里最需要注意的是：ArkTS是静态类型语言，传Map时value类型必须严格是String、num、bool这些基础类型。如果你传了Object进去，Dart侧拿到的类型会变成Map<dynamic, dynamic>，序列化时容易丢字段。所以建议在插件层定义一个可序列化的数据类，把入参出参都model化。

4.5 单元测试与真机验证

在把整个模块集成进大项目之前，先写一个小demo验证跑通。demo不要用真实业务数据，就用固定的RSA测试密钥，跑一遍“签发JWT→验签JWT”“RSA加密→RSA解密”“AES加密→AES解密”三条链路。

在OHOS真机或模拟器上跑的方式：

bash复制flutter build hap --release

然后通过DevEco Studio的hvigor把产物装到模拟器。日常联调推荐用flutter run -d <device>，它会把Dart代码发到设备端，热重载速度非常香。

我第一次在OpenHarmony模拟器上跑的时候，遇到一个问题：模拟器没有硬件安全随机数，Random.secure()耗时特别长，导致JWE加密卡了整整5秒。排查后发现是模拟器底层的熵源不足。换到真机之后问题消失，但稳妥起见，我在随机数调用处加了一个缓存逻辑：一次性生成足够多的随机字节缓存起来，避免频繁触发底层调用。

5. 常见问题与排查技巧实录

5.1 编译期：找不到crypto库或版本冲突

现象：Error: Could not resolve package:crypto或者The argument type 'String?' can't be assigned to the parameter type 'String'。

原因：jose传递依赖了多个Dart包，如果和项目的其他依赖版本冲突，pub会锁到旧版本，导致API不一致。

解决办法：在pubspec.yaml里显式添加dependency_overrides：

yaml复制dependency_overrides:
  crypto: ^3.0.3
  pointycastle: ^3.7.3
  convert: ^3.1.1
  typed_data: ^1.3.2

这几个包都是纯Dart实现，锁高版本很安全，不会引入Native依赖。

5.2 运行期：JSON反序列化报类型错误

现象：验签成功后，claims['some_field']取出Object?，强转String时报类型错误。

原因：JSON里的数字可能是int也可能是double。比如exp是double类型转过来，在Dart侧是double，直接as int就崩了。

解决办法：不要直接强转，写一个安全取值工具类：

dart复制T? safeGet<T>(Map<String, dynamic> map, String key) {
  final value = map[key];
  if (value == null) return null;
  return value is T ? value : null;
}

final userId = safeGet<String>(claims, 'sub');

5.3 运行期：JWE解密慢或超时

现象：JWE解密在部分低端设备上耗时超过1秒，影响体验。

排查思路：

• 确认算法组合。RSA-OAEP-256 + A256GCM在非对称运算上耗时较长，尤其1024位RSA密钥。
• 如果只是局域网内部传输，换成dir + A256GCM，单次加解密可以降到微秒级。
• 检查密钥长度。推荐至少2048位RSA，1024位不仅不安全，而且有些OpenHarmony设备的加密硬件优化不对它生效。

5.4 兼容性：jose生成的JWT在其他语言服务端验签失败

现象：Dart端用jose签发的JWT，拿到Java/Go服务端验签失败。

原因多数是Base64Url编码细节。JWT要求Base64Url不带=填充符，但某些语言的Base64Url实现默认会带。jose遵循标准不填充，但别的库读的时候如果没处理，就报长度错误。

解决方法是在服务端先做Base64Url解码，去掉可能的=补充。另外还有一个问题是RS256的签名使用PKCS1v1.5还是PSS模式。jose默认RS256走PKCS1v1.5，PS256才走PSS，两边算法没对上就会出现“signature mismatch”。

5.5 密钥管理：千万不要把PEM硬编码进源码

安全库用起来最怕的是密钥泄露。我见过不少项目直接把测试私钥写死在Flutter的const变量里，这是非常危险的做法。建议至少做到：

• 私钥放在服务端，客户端只留公钥，能只验签就不持有私钥。
• 如果必须在端侧持有私钥（比如离线自签名），私钥放进操作系统安全存储区，通过channel传给Dart层时不要打日志。
• 开发环境与生产环境使用不同的密钥对，并定期轮换。

在OpenHarmony里，调用系统安全存储的API把私钥读出来，再通过MethodChannel传到Flutter层，中间可以用Byte数组传递，避免字符串被日志系统捕获。

5.6 调试小技巧：用OpenSSL交叉验证

在移植过程中，我经常拿jose签出的JWT去OpenSSL命令验证，或者反过来，用OpenSSL签一个JWT再让jose去验签。这个方法能很快速地区分“是jose算法实现问题”还是“我们封装层传参问题”。

实测的命令：

bash复制# 用私钥对header.payload签名，注意siginput先做base64url编码
echo -n "eyJhbGciOiJSUzI1NiJ9.eyJzdWIiOiIxMjM0NTY3ODkwIn0" | openssl dgst -sha256 -sign private.pem | openssl base64 -A | tr '+/' '-_' | tr -d '='

如果最终结果和jose产出的一致，说明算法链路没问题，问题只出在Base64编码或JSON序列化差异上。

6. 踩坑后的性能与安全建议

6.1 性能对比：JWS vs JWE怎么选

从性能测试来看，同样是1KB数据：

• HS256 JWS签名验签：约0.2ms（对称算法，很快）
• RS256 JWS签名：约2ms，验签约0.3ms
• RSA-OAEP + A256GCM JWE：加密约3ms，解密约5ms（非对称+对称混合，解密更慢）
• dir + A256GCM JWE：加密约0.1ms，解密约0.1ms

所以性能排序是：对称JWE > 对称JWS > 非对称JWS > 非对称JWE。如果对延迟极其敏感，优先用对称密钥；如果是互联网公开环境下分发令牌，用非对称JWS，因为公钥可以随意公开，不像对称密钥要建立安全通道分发。

6.2 安全最佳实践：没必要为了炫技叠加多层

很多团队设计协议时喜欢“既签名又加密”，先用JWS签名，再整体塞进JWE加密。这本身不是错，但要有明确理由。如果只是为了防篡改和防泄露，直接用带A256GCM的JWE就够了，因为GCM的Auth Tag已经提供了完整性校验。两个都上会增加解析复杂度和性能开销。

另外，接收方在解密JWE时，一定要检查Header里的alg和enc是否是你期望的值，不要直接信Token里的声明。否则存在“算法降级攻击”的可能：攻击者把alg从RSA-OAEP改成dir，诱导接收方用错误方式解密。

6.3 单元测试尽量覆盖算法矩阵

jose支持的算法很多，但你不需要全部接入。根据业务场景，建议至少覆盖以下测试用例：

我现在就把这套测试用例放在CI流水线里自动跑，每次升级jose版本后，跑一遍全矩阵，确认算法互操作没有回归。

6.4 后续扩展：结合鸿蒙系统安全能力

在OpenHarmony上做安全，还可以考虑把Dart层生成的RSA密钥对直接交给系统安全存储保管，私钥永不出安全区，只把公钥传给jose做验证或加密。目前鸿蒙的@kit.CryptoArchitectureKit支持生成密钥并存储到HUKS（HarmonyOS Universal KeyStore），配合Flutter插件的channel调用，可以在端侧做“私钥不可读”的安全签名。这比把私钥PEM塞进Dart层更安全，也是生产环境更应该走的方案。

我个人的体会是，安全库的适配难的不是算法本身，而是跨语言、跨平台、跨生态的“接缝”问题。jose把标准做得很完整，但换到OpenHarmony这个新底座上，还是要靠我们自己补平台层适配。本文这套“Dart层安全库+MethodChannel暴露给ArkTS”的架构，目前在团队项目里已经稳定跑了三个版本，后续如果鸿蒙的NAPI生态再成熟一些，可以考虑把高频的JWT验签直接用ArkTS NAPI封一层，进一步降低性能损耗。但从投入产出比来看，现阶段Flutter for OpenHarmony加jose的组合，已经能解决绝大部分业务安全需求了。