DemoCheckSafe页面CheckPlanPage任务CS-3109规则修订rev4。本文所有界面、HiLog 和日志均为构造的演示数据不代表真实 DevEco Studio 编译、真机运行或现场验收。一、一键勾选后锁定点位为什么也进了清单一个巡检班组的操作其实很简单打开待检点位列表先全选今天能去的机柜再取消临时不去的点位最后生成执行清单。麻烦出在“能去”不是固定属性。后台排程会把某些点位锁住例如消防阀正在检修现场人员仍能看到它却不该把它放进本轮执行清单。若界面只根据复选框是否显示来判断可选范围一次全选就可能把锁定项也带进结果。我把这个问题缩小成 CheckSafe 的一张页面。任务CS-3109含五个点位P-01 机房门禁、P-02 供电柜、P-03 消防阀、P-04 空调主机、P-05 应急灯。修订号rev4下只有P-03被锁定其余四项可选。演示的最终选择是P-01、P-02、P-04因此屏幕应明确显示“可选4、锁定1、已选3”并生成SNAPSHOT_READY。这些数字不是测量值而是文章、代码和配图共同使用的一组确定性输入。这里有一个容易被忽略的差别界面勾选状态是编辑中的意图提交快照才是经过规则过滤的结果。锁定项不应该通过“看起来灰了”来保证安全也不该依靠按钮点击前的一次清空来掩盖状态污染。真正的边界要放在数据层让批量选择、单项切换和最终提交都执行同一套资格判断。二、先固定数据身份再谈全选交互复选框是 ArkUI 组件但点位是否可用是业务属性。华为的 Checkbox 参考文档明确给出Checkbox({ name })、.select(boolean)和.onChange((value: boolean) …)的用法也可以使用通用的.enabled限制交互。它没有替应用提供“后台锁定仍不可提交”的业务保证这部分必须由我们实现。本文仅使用上述稳定组件能力避免把“批量筛选”包装成不存在的系统接口。先写一层最小的数据模型解决“全选究竟选哪些 ID”的问题。全选返回新数组不直接改写点位数组ID 是稳定身份而不是列表下标。这样后续即使排序或刷新勾选也不会莫名串到另一行。interfaceCheckPoint{id:string;title:string;locked:boolean;}constPOINTS:CheckPoint[][{id:P-01,title:机房门禁,locked:false},{id:P-02,title:供电柜,locked:false},{id:P-03,title:消防阀,locked:true},{id:P-04,title:空调主机,locked:false},{id:P-05,title:应急灯,locked:false}];functionselectEligible(points:CheckPoint[]):string[]{returnpoints.filter((p:CheckPoint)!p.locked).map((p:CheckPoint)p.id);}selectEligible在这组数据上会返回四个 ID其中绝不包含P-03。用户随后取消P-05页面中才剩下三个选择。方法是纯计算没有文件句柄、监听器或网络连接可释放生命周期取决于调用它的页面。真实后台更新时必须传入当时最新的规则列表不能把首次加载的POINTS当成永远有效。后台列表为空时结果就是空数组不能自行恢复旧勾选。三、灰态只是视觉反馈提交必须重新过滤我最在意的不是“点下去会不会变色”而是提交瞬间是否仍可能把不可用 ID 混进结果。比如页面刚打开时P-03可选用户勾了它随后规则修订变更点位锁定。仅将 Checkbox 置灰不会自动消除之前保存在数组里的 ID。更糟的是批量全选和逐项取消可能来自不同入口状态残留肉眼很难发现。因此提交操作不直接复制selectedIds而是先获取当前可用 ID 集合再按页面可见顺序重新筛一遍。这里还要比对规则修订号提交时若不是期望的rev4宁可返回拒绝也不拿旧规则假装成功。下面代码负责生成前端演示快照不包含真实服务端写入或权限确认。interfaceCommitSnapshot{taskId:string;ruleRev:number;ids:string[];status:string;}functionmakeSnapshot(points:CheckPoint[],chosen:string[],actualRev:number,expectedRev:number):CommitSnapshot|null{if(actualRev!expectedRev)returnnull;constallowed:SetstringnewSetstring(points.filter((p:CheckPoint)!p.locked).map((p:CheckPoint)p.id));constids:string[]points.filter((p:CheckPoint)allowed.has(p.id)chosen.includes(p.id)).map((p:CheckPoint)p.id);if(ids.length0)returnnull;return{taskId:CS-3109,ruleRev:actualRev,ids:ids.slice(),status:SNAPSHOT_READY};}这个函数解决的是提交一致性不是将状态写入磁盘。ids.slice()是为了避免外部继续修改同一数组Set只是本次运算的临时索引。条件失败返回null调用方需要显示“规则已变化请重新核验”或“没有可提交点位”不能把两种异常都解释成服务器异常。实际产品还应在服务端再次校验点位权限、锁定版本及操作者身份前端快照并不构成越权访问的凭据。四、把编辑态留给页面把不可选项留给规则进入 ArkUI 页面后我们只维护selectedIds和提交状态不在组件里复制另一套lockedMap。将一套资格来源拆成两个可修改副本正是热更新时产生不一致的根源。Checkbox的name使用点位 ID.select由数组计算锁定项通过.enabled(false)禁止人工点击即使 UI 层回调异常触发togglePoint也再次检查锁定条件。下面保留页面最关键的事件路径其他配色和间距可以按产品规范扩展。演示启动时已经走过“全选可用项再取消 P-05”的流程因此最终三项选中点击生成快照只更新页面状态不声称完成网络提交。EntryComponentstruct CheckPlanPage{privatepoints:CheckPoint[]POINTS;StateselectedIds:string[][P-01,P-02,P-04];StatecommitStatus:stringSNAPSHOT_READY;privatetogglePoint(id:string,checked:boolean):void{constpoint:CheckPoint|undefinedthis.points.find((p:CheckPoint)p.idid);if(!point||point.locked)return;this.selectedIdschecked?Array.from(newSetstring([...this.selectedIds,id])):this.selectedIds.filter((item:string)item!id);}build(){Column({space:12}){Text(CS-3109 · rev4 · 可选4 / 锁定1 / 已选3)ForEach(this.points,(p:CheckPoint){Row({space:12}){Checkbox({name:p.id}).select(this.selectedIds.includes(p.id)).enabled(!p.locked).onChange((checked:boolean)this.togglePoint(p.id,checked))Text(${p.id}${p.title}${p.locked? · 锁定:})}},(p:CheckPoint)p.id)Button(生成快照).onClick((){constsnapshotmakeSnapshot(this.points,this.selectedIds,4,4);this.commitStatussnapshot?snapshot.status:REJECTED;})Text(状态${this.commitStatus})}}}代码里标题行的“已选3”只对应这次固定演示。若将它作为真正可交互工程页面应换成this.selectedIds.length的动态显示并在后台规则变化后重新计算否则用户继续点击时数字会与实际勾选不一致。演示图采用冻结的最终状态目的是让读者直接核对快照边界而不是展示一个完整生产级选择流程。State数组采用整体赋值是为了让框架看到状态变化如果原地修改普通数组却没有触发刷新UI 就可能停留在旧值。五、校验时别只看“都打了勾”我建议验收时先做三个反向动作第一按全选路径运行确认P-03永远不进入结果第二把已选的P-02设成锁定后再提交确保快照会过滤它而不是依赖界面是否及时刷新第三将规则修订从4改到5确认提交返回拒绝。它们测试的分别是批量选择边界、提交边界和版本边界。三者通过后再去调整样式才有意义。本轮固定演示中五个点位里可选四个、锁定一个、选中三个快照中的 ID 顺序是P-01,P-02,P-04状态SNAPSHOT_READY。日志示例统一写成CS-3109 rev4 selectable4 locked1 selected3 statusSNAPSHOT_READY。这是为了方便文章与两张运行示意图逐项核对不是从 HiLog 采集的真机证据。六、页面消失以后哪些状态该保留这份 Demo 没有注册定时器、长期网络请求或蓝牙监听因此离开页面时没有额外句柄需要释放。但“没有句柄”不代表“没有生命周期问题”selectedIds是页面编辑草稿页面重新创建后可能恢复为初值。真实应用应明确选中态是一次性操作还是需要跨页保存不能默认把快照当成已经持久化的任务。若从服务端重新打开首先加载规则版本和点位列表再根据稳定 ID 恢复尚有效的草稿。对于锁定项显示为灰态是有价值的它告诉巡检人员这个点位存在但当前不能安排。把它从列表直接删除反而可能导致误以为任务丢失。另一方面锁定原因、权限和服务端变更应显示可解释文案不能把所有禁用都写成“网络异常”。页面级enabled是交互限制业务级makeSnapshot是数据限制两层必须同时存在。还有一个容易被团队忽略的验收细节服务端可能同时把新点位插入列表。旧客户端如果只保存“第几行被勾选”新列表一到就会产生位置漂移。因此恢复草稿时应按 ID 做交集遇到已经删除的点位直接标为待确认如果任务已经正式提交则展示提交时的规则版本与快照内容而不是拿今天的最新列表去覆盖历史记录。这样的记录才能支持事后追溯也能让产品明确区分“当时允许执行”和“现在仍可执行”。这次复盘最终落在一个非常具体的结论批量选中只处理用户意图提交时必须按最新规则重新建立有效集。当数据变动、页面重建或点击回调顺序不可控时只有把稳定 ID、规则修订和不可变快照分开才能避免“明明灰掉了却仍被带进工单”的隐蔽问题。本文示例没有覆盖真实协同冲突、离线同步及后台竞态那些必须交给端到端测试继续验证。参考资料华为官方 Checkbox APIhttps://developer.huawei.com/consumer/cn/doc/doccenter-capabilities/api/ts-basic-components-checkbox华为官方 ArkTS 简介https://developer.huawei.com/consumer/cn/doc/harmonyos-guides/arkts-overview