Flutter 插件适配 OpenHarmony：onMethodCall 分发与参数处理实战

这里采用 if-else 结构而非 switch-case，因为待处理的方法较少，这样更简洁直观。相比之下，某些其他插件（如 secure_application）因方法较多而选择了 switch-case。

参数提取与类型安全

Dart 层通过 invokeMethod 传递参数，原生层需进行提取和断言。

Dart 层传递

return await _channel.invokeMethod('authenticate', <String, dynamic>{
    'url': url,
    'callbackUrlScheme': callbackUrlScheme,
    'preferEphemeral': preferEphemeral ?? false,
});

原生层提取

const url = call.argument('url') as string;
const callbackUrlScheme = call.argument('callbackUrlScheme') as string;

需要注意的是，call.argument() 返回的是 ESObject 类型，必须使用 as 进行类型断言。虽然 Dart 层使用了 required 关键字保证参数不为空，但在原生层仍建议做好防御性编程，例如检查 url 是否为空，避免后续 openLink(null) 导致崩溃。

关于 preferEphemeral 的处理

当前实现中忽略了 preferEphemeral 参数。这是因为 OpenHarmony 的 openLink API 尚不支持隐私浏览模式。这并非代码遗漏，而是基于平台能力的有意设计。若未来系统支持该功能，可在此处恢复对该参数的提取。

异步回调与清理机制

authenticate 是异步方法，而 cleanUpDanglingCalls 是同步的。理解两者的区别对调试至关重要。

cleanUpDanglingCalls 执行流程

当用户取消登录或发生异常时，需要清理所有挂起的 MethodResult。

private cleanUpDanglingCalls(result: MethodResult): void {
    FlutterWebAuthPlugin.callbacks.forEach((danglingResult: MethodResult) => {
        danglingResult.error("CANCELED", "User canceled login", null);
    });
    FlutterWebAuthPlugin.callbacks.clear();
    result.success(null);
}

1. 遍历 callbacks Map 中所有待处理的 MethodResult。
2. 向每个结果返回 CANCELED 错误码及消息。
3. 清空整个 Map。
4. 向 Dart 层返回成功状态。

延迟使用的风险

由于 authenticate 方法会立即返回并等待 onNewWant 回调时才通知结果，result 对象会被存入 Map 中。只要 Map 持有引用，就不会被 GC 回收，因此无需担心内存问题。

日志记录与安全

调试阶段打印完整 URL 很方便，但生产环境需注意敏感信息泄露。

// ⚠️ 生产环境建议只打印 Scheme，不打印完整 URL
console.info(TAG, `authenticate called with scheme=${callbackUrlScheme}`);

URL 中可能包含 client_id、state 等敏感参数，直接打印到日志存在安全风险。此外，对于未知方法的调用，flutter_web_auth 选择返回 notImplemented() 而非静默忽略，这有助于开发者快速发现版本不匹配或通道冲突问题。

总结

适配过程中重点关注了以下几点：

1. 方法分发：仅处理 authenticate 和 cleanUpDanglingCalls，其余返回未实现。
2. 参数处理：使用 as 断言，注意 preferEphemeral 的平台限制。
3. 生命周期管理：利用 Map 缓存 MethodResult 以支持异步回调。
4. 安全性：生产环境避免在日志中输出完整认证 URL。

后续可进一步研究 Dangling Calls 的具体触发场景及用户取消认证时的完整处理流程。