深圳一个三人小队把 TPWallet 装进 HarmonyOS NEXT 的 Mate 60，准备跑通 DApp 授权。扫码连接顺利，点“钱包里面确认”却弹回浏览器了，签名结果没回来。这个失败把 tpwallet HarmonyOS 适配里最隐蔽的一段链路翻了出来。

鸿蒙的 Want 跳转、应用后台状态、回调 URI，任何一环没对齐了，用户看到的就是“钱包没反应”。他们先排除了网络。日志显示 DApp 发出的 deep link 被系统识别成普通网页链接，TPWallet 虽然被拉起了， entry ability 拿到参数时少了 callback。原来安卓端沿用的 intent-filter 在鸿蒙上语义不同，是从浏览器跨应用跳转，隐式 Want 的匹配规则更谨慎。开发人员把 scheme 改成显式 Want。并在 module.json5 里补上 skills 配置，回跳才稳定一半了。这里有个主观判断，把 APK 套壳当鸿蒙原生，短期能装，长期会在签名回传和权限授权上反复翻车的。真正让成功率上去的改动不复杂。

他们把 callback 从自定义 scheme 换成 HTTPS 域名， TPWallet 在 HarmonyOS 端拦截并转发，把签名结果写入应用级 KV了，再触发一次轻量通知。测试数据 62% 提还有 91%。

我还留意到，鸿蒙对后台任务管控更细，钱包进程被冻结时，WebSocket 长连接基本会断，所以 tpwallet HarmonyOS 场景下，不要把希望全押在实时回执上。短轮询加本地缓存更实际。这个案例里，用户不关心底层是 Want 还是 App Linking，只关心扫完码能不能回到 DApp的。团队后来把错误码暴露在前端， 4101 表示回调域名未登记，4102 表示钱包未解锁。客诉少了三分之一。我的看法是tpwallet HarmonyOS 的竞争点不在界面像不像，但在跨应用链路够不够稳。谁先把 deep link 规范、权限说明和失败提示做清楚啊？谁就更容易留住鸿蒙用户啊？