给内嵌 H5 做离线资源加速，第一反应是用 onInterceptRequest 把图片和 JS 全部拦下来，从本地读。功能确实通了，但 H5 的加载时间从 1.2 秒涨到了 4 秒以上，滑动也变卡了。你把拦截逻辑翻来覆去地看，查表、读文件、返回响应，每一步都“看起来很快”。问题不在单次拦截的耗时，在onInterceptRequest 是逐请求的同步返回链路，页面上几十个小文

推送功能上线，服务端日志显示消息全部发送成功，用户端投诉“从来没收到过”。排查发现两种情况混在一起：一部分用户的 Token 在重装应用之后已经失效，服务端还拿着旧 Token 在发；另一部分用户确实在系统设置里关掉了通知权限，但服务端根据“Token 存在”就判定“可触达”，继续推送。Push Kit 的“发送成功”只代表消息交给了推送通道，不代表用户设备上一定展示。把 Token 当成“设备可

把长列表从 ForEach 换成 LazyForEach，首屏白屏确实没了，但快速滑动的时候还是掉帧，Profiler 里 build 调用次数依然居高不下。LazyForEach 解决的是“不一次性建完”，但它不负责“建得快”和“建得少”。真正流畅的长列表需要四件事同时到位：稳定的 Key、组件复用、合理的 cachedCou

把外卖进度从普通通知迁到实况窗，第一版跑起来挺顺，创建、更新、结束三个接口都通了。上线之后投诉来了：用户锁屏上看实况窗，骑手已经点了送达，窗上还写着“正在配送”。日志里 updateLiveView 明明在调，返回码有时候是成功有时候是失败。问题不在你的业务逻辑，在实况窗的更新通道有独立的频控和生命周期规则，拿普通通知的思维往里套，高频更新会被限流，进程被杀之后窗也不会自动消失

接入 PDF 预览功能，代码照文档抄的，loadDocument 返回成功，页面上干干净净一片白。你以为是渲染没触发，反复调 loadDocument、反复刷新，甚至怀疑 PDF 文件坏了。实际上 loadDocument 的成功只代表“文件被读取了”，如果传入的路径不是应用沙箱里的本地文件，或者文件根本没有被完整拷贝进沙箱，渲染阶段拿到的就是空页面。Har

做运动手表应用的时候，有个问题在模拟器上永远复现不了：用户退出运动页面，半小时后手表烫得厉害，电量掉了百分之十几。日志里传感器回调还在刷，心率、加速度的数据一行行往外蹦。你以为是系统没回收进程，实际上是你自己没退订——HarmonyOS 的传感器订阅是“谁订谁退”的模型，页面销毁不会自动帮你调 off。穿戴设备的功耗预算比手机紧得多，一次遗漏退订，在手表上就是肉眼可见的电量流失。 on

三折叠手机展开到 G 态，期望是三栏布局，结果页面还是两列。代码里判断 isExpanded 或者设备型号，在二折叠上勉强能用，到了三折叠就完全对不上。根因很清晰：把“设备形态”和“窗口可用空间”混成了一个条件。三折叠的 G 态窗口宽度确实很大，但你的应用可能正处在一个自由窗口里，或者被平行视界切走了一半。设备型号告诉不了你“此刻窗口还剩多少宽度”，只有窗口本身知道。 断点监听

应用内拖拽一切正常，拖到另一台设备上，onDrop 里 event.getData() 返回空，getRecords() 也是空的。代码里 onDragStart 明明 setData 了一个自定义对象，字段都在，本机拖拽读得好好的。问题不在 setData 有没有执行，在跨设备拖拽不吃自定义 JS

给一个文件同步功能加了长时任务，以为退后台之后进程就不会被冻结，同步能一直跑。结果用户切出去几分钟，任务照样停了。查文档才发现两个问题叠在一起：申请的 backgroundModes 和实际业务不匹配，文件下载/上传应该用 dataTransfer，不是随便选一个看起来“通用”的类别；而且长时任务本身也不承诺进程永久保活，系统在资源紧张或策略收紧时照样会限制。 长时任务、短时任务、Wor

用 AVCodec 做自定义播放器，初始化、配置、启动，回调也注册了，但 outputBufferAvailable 一直不触发，画面停在第一帧。日志里 inputBufferAvailable 来过，说明解码器在等数据，数据也 PushInputBuffer 了，但输出就是不来。查了两天才发现，问题不在解码器配置，在输入缓冲区的归还时机