延迟任务还有一个容易被忽略的边界：它的 repeatCycleTime 最小间隔是两小时，而且实际执行频率还受应用活跃分组约束——活跃分组两小时，经常使用四小时，常用二十四小时，极少使用四十八小时，受限或从未使用的分组直接不调度。把延迟任务当精确定时器用，代码本身不会报错，但业务节奏会永远对不上。综上所述，后台任务的核心不是“找到一种让进程别死的手段”，而是先把业务翻译成系统能理解的语义：一小段收

综上所述，onWindowStageWillDestroy 是窗口监听的最后安全出口，onWindowStageDestroy 只负责断开窗口引用，onDestroy 管 Ability 级资源——三者不是“程度不同的退出回调”，而是各自有明确的归属范围。窗口监听的所有者是 WindowStage，定时器的所有者是 UIAbility，播放器的所有者是页面或 Ability（取决于你在哪一层创建的

综上所述，put 返回成功只是本地落盘，sync() 返回只是启动同步，dataChange 触发只是信号到达，这三件事没有一件等于“对面已经按你期望的方式收到了”。同步链路跑通之后，下一个容易失控的地方在消费端。手机改标题、平板改负责人，两次修改落在同一条记录上，网络恢复后可能只剩其中一次，日志不报错，同步显示成功，但另一个字段就是没了。手机连续做了三次修改，序号 41、42、43，平板断网重连

一个扫码页，预览正常，对焦正常，点击拍照按钮的那一刻，你期望画面“定住”一下，然后弹出结果。但真机上，capture() 调了，回调也回来了，照片确实存下来了，屏幕上那张预览图却还在实时刷新，像是快门从来没按过。用户看着画面以为没拍上，又按了一次，结果相册里多出一张一模一样的照片。 你翻代码，PhotoOutput.capture() 的执行顺序没问题，错误码也没有。问题不在 capture 本身

一个相册瀑布流页面，双列，图片高度不等。数据用 LazyForEach，卡片套了 @Reusable，cachedCount 也给了 5。功能一切正常，但快速上下滚动的时候，卡片会短暂“穿模”——上一条的图片残留在新卡片的位置上，然后才刷成对的图；偶尔回滚一下，列高还会整体跳一次，滚动位置跟着飞走。你检查了 key，是业务 ID；检查了 aboutToReuse，该清的 src 也清了。但问题依旧

一个列表页，两百多条卡片，每张卡片有图、有标题、有收藏按钮。第一屏渲染完美，往下滑也流畅。然后你把列表往回滚，发现第三张卡片的收藏按钮亮着，点开详情却是另一条数据；再滑下去再回来，某张卡片的标题变成了刚才某条已经滑过去的记录。你把 key 换成了唯一 ID，把 cachedCount 从 5 调到 3，问题依旧偶现。 这里有两个容易混淆的东西在同时工作。LazyForEach 负责“按需创建”，@

一个很典型的下午。相机功能写完了，module.json5 里 ohos.permission.CAMERA 声明了，reason 和 usedScene 也填了，requestPermissionsFromUser 在代码里调得明明白白。跑起来，点“拍照”，什么都没发生。没有弹窗，没有报错，没有异常，相机预览就是黑的。你翻权限列表，确认是 user_grant，确认包名没写错，确认签名没问题。然

一个很耗人的现象：Debug 包怎么点都正常，CI 出的 Release 包一到线上就出事。数据库 insert 成功，query 抛 no such column: a1；或者更安静一点，查询不报错，但字段读出来全是 null。你以为是混淆规则漏了，往 obfuscation-rules.txt 里加 -keep，加完 UI 好了数据库还坏；再加一批 -keep-property-name，终于

一个很消耗人的场景。你照着模板写好了 InsightIntentExecutor，insight_intent.json 也配了，用 hdc shell aa start 在本地模拟，onNewWant 稳稳触发，executeParam 里的 JSON 打印得清清楚楚。然后你接上小艺智能体，对着手机说话，应用安安静静，onCreate、onNewWant、执行器，一个都没进来。日志干干净净，连一

一个很具体的场景。用户在手机笔记里写了半篇稿子，光标停在第三段中间，点了接续。平板上的应用确实被拉起来了，页面也跳到了编辑页，看起来一切正常。然后用户看了一眼屏幕：标题空的，正文空的，光标在开头。他以为是自己点错了，退回首页，重新点进那篇笔记，稿子还在——只是手机和平板之间那一段“现场”根本没搬过来。 你翻日志，onContinue 执行了，返回值是 AGREE，目标端 launchReason