HarmonyOS鸿蒙Next中在潮新闻中使用UIAbilityContext.openLink拉端微信，此时微信有分身，系统弹窗让用户选择打开哪一个微信分身。无法监听到选择某一个微信分身、或者点击关闭按钮的事件。

在HarmonyOS Next中，UIAbilityContext.openLink 方法用于拉起其他应用，其回调（包括callback和CompletionHandler）的触发条件是目标应用被成功拉起并返回结果。

当系统存在应用分身并弹出选择器时，用户的操作（选择某个分身或关闭弹窗）发生在系统层级的应用选择界面，而不是目标应用本身。此时，如果用户没有做出选择（例如直接关闭弹窗），或者选择操作没有最终导致目标应用被实例化并返回数据，那么 openLink 的回调将不会被执行。这是当前API的设计行为。

核心结论：UIAbilityContext.openLink 的回调机制无法用于监听系统应用选择弹窗的中间操作（选择哪个分身或取消）。回调仅在目标应用被成功拉起并完成交互（例如通过startAbilityForResult方式返回数据）后才会触发。

当前可行的替代方案：

1. 使用隐式Want拉起：通过设置Want的parameters，可以尝试指定打开某个特定的分身。但这需要目标应用（微信）的分身有独立的包名或能力标识，并且微信支持通过Want参数区分。这通常依赖于目标应用的具体实现，并非通用解决方案。

   let want = {
       action: 'ohos.want.action.viewData',
       entities: ['entity.system.browsable'],
       uri: 'weixin://', // 示例URI
       // 可以尝试添加参数来指定分身，但这需要微信支持
       parameters: {
           // 例如： 'cloneId': 1
       }
   };
   context.openLink(want, (err) => {
       if (err) {
           // 处理错误
       }
   });
   

2. 引导用户设置默认打开项：在系统弹出选择器时，通常有“始终使用此方式打开”的选项。一旦用户为特定链接（如weixin://）设置了默认打开的应用分身，后续调用openLink将直接打开该分身，不再弹出选择器，从而避免此问题。但这依赖于用户操作。

总结：您遇到的问题是由于系统应用选择器的交互流程不在openLink回调的监听范围内。目前没有直接API可以监听该选择器的具体操作。建议优先考虑方案1（如果微信支持参数区分），或理解当前机制下回调触发的边界条件。