HarmonyOS 7.0 穿戴端互动卡片：小屏信息怎么避免塞满和误触
这篇只拆一个 HarmonyOS 7.0 / API 26 相关点：穿戴设备互动卡片信息密度。我不会把它写成“新能力清单”，因为清单看完很快就忘。更有价值的是把一个具体问题讲透：它怎么出现、怎么复现、怎么兜底、代码里怎么封装，最后怎么验证。
为什么这个点值得单独写
穿戴端不是手机页面缩小版。小屏幕里如果把标题、状态、按钮、统计都塞进去，用户真正要点的地方会变小，误触概率上升。
如果直接在大页面里排查，状态、路由、权限、设备形态、网络、资源加载会混在一起，最后很难判断是哪一层出了问题。所以我的做法是先做一个小实验，把输入、输出和失败路径都打出来，再考虑接到正式工程里。
复现场景一：卡片同时显示三行信息和两个按钮，触控区域太小
先做一个最小页面，只保留一个入口、一个状态变化、一个日志输出。连续触发两次，再切到后台回来。如果最小页面都不稳定，就不要急着塞进复杂业务。
复现场景二：弱网刷新失败后，小屏只显示空白，没有下一步提示
第二个场景要模拟真实使用：窗口变化、弱网恢复、权限拒绝、设备能力不一致、后台再进入。很多 HarmonyOS 问题不是第一次点击就暴露，而是在状态恢复和资源重新绑定时才出现。
最小 Demo
interfaceWearCardModel{title:string;status:string;primaryAction:string;disabledReason?:string}functioncompactWearCard(m:WearCardModel){return{title:m.title.slice(0,10),status:m.disabledReason||m.status,action:m.primaryAction}}这段 Demo 的重点不是代码多，而是验证路径清楚：先让状态变化可见，再把失败原因收口，最后把日志打到能定位问题的程度。只要这个小实验能稳定复现和修复，后面放到正式页面里才有意义。
三种处理方式对比
| 做法 | 适合什么情况 | 风险 |
|---|---|---|
| 页面里临时 if 判断 | 只想快速验证一个分支 | 逻辑散，后面容易漏改 |
| 把失败吞掉继续走 | 想让页面看起来不报错 | 用户看到的是假成功，后面更难排查 |
| 抽成 Guard 或 Adapter | 多页面、多设备、多状态复用 | 前期要把输入输出设计清楚 |
我会选第三种。页面只负责展示，能力判断、版本边界、降级策略放到单独函数或类里。后面设备形态、系统版本、审核要求变化时，改一个地方就够了。
可复用封装
typeRunMode='full'|'fallback'|'blocked'interfaceCheckInput{apiLevel:numberdeviceReady:booleanpermissionReady:booleanpayloadReady:booleanwindowStable:boolean}interfaceCheckResult{ok:booleanmode:RunMode reason:string}classApi26CapabilityGuard{constructor(privatereadonlyfeatureName:string){}check(input:CheckInput):CheckResult{if(input.apiLevel<26){return{ok:false,mode:'fallback',reason:this.featureName+': api below 26'}}if(!input.deviceReady){return{ok:false,mode:'blocked',reason:this.featureName+': device not ready'}}if(!input.permissionReady){return{ok:false,mode:'blocked',reason:this.featureName+': permission denied'}}if(!input.payloadReady){return{ok:false,mode:'blocked',reason:this.featureName+': payload missing'}}if(!input.windowStable){return{ok:false,mode:'fallback',reason:this.featureName+': window changing'}}return{ok:true,mode:'full',reason:this.featureName+': ready'}}}页面里只消费结果：
constguard=newApi26CapabilityGuard('穿戴设备互动卡片信息密度')constdecision=guard.check({apiLevel:26,deviceReady:true,permissionReady:true,payloadReady:true,windowStable:true})if(!decision.ok){console.info('[feature-check]',decision.mode,decision.reason)}上线前我会怎么验
- 标题里的关键词能对应开发者会搜的问题，不写空泛口号。
- 第一屏就说明版本边界，避免读者误以为 5.0、6.0 项目可以直接照搬。
- 至少两个案例：一个正常路径，一个失败或降级路径。
- 日志里能看到 API level、设备状态、权限状态、输入参数和降级原因。
- 图片解释结构，不只做装饰。
- 如果涉及审核、权限、多设备，要把失败提示和兜底路径一起准备。
总结
穿戴端互动卡片要只保留一个主动作和一个核心状态，失败提示也要短而明确。
写 HarmonyOS 7.0 的文章，不能只介绍“新增了什么”。更关键的是把问题怎么发生、怎么复现、怎么修、怎么验证讲清楚。这样读者看完不是记住一个名词，而是能把这套排查方法拿走。
