推送接进去，测试消息能收到，但用户点通知栏，应用打开了，停在首页，没有跳到详情页。或者更奇怪：前台收到推送，通知栏弹一条，用户点进去又走了一遍 onCreate，路由参数丢了。再或者，卸载重装之后推送彻底收不到了，服务端还在往旧 token 发。Push Kit 的问题很少是“推不到”，更多是“收到了但接不住”：token 的生命周期、点击参数的解析、前台消息的分流，各自有各自的契约。

移动端最真实的网络环境不是 Wi-Fi 满格，是电梯、地库、高铁隧道。一个只在“网络正常”路径上测过的应用，到了弱网环境就开始表演：页面转圈转到超时，提交按钮点完没反应，用户以为没提交又点一次，结果服务端收到两条重复数据。离线优先不是“加个缓存开关”，它要求你把本地数据库当成唯一可信源，网络只负责在后台把本地数据变新。 传统“在线优先”的数据流是：页面展示 → 发 HTTP 请求 → 等响应 →

折叠屏适配最常见的错误，是代码里写一句 if (deviceType === 'foldable')，然后展开态走双栏、折叠态走单栏。在直板机上测试没问题，一到分屏、半悬停、平行视界就乱：明明设备是折叠屏，窗口宽度已经被压到 500vp 以下，代码还在按“折叠屏展开”渲染双栏，控件直接溢出。设备型号是固定的，窗口宽度是动态的。HarmonyOS 的一多适配，判断依据必

元服务卡片开发，最让人血压升高的场景之一是：主应用里数据明明更新了，updateForm 也调了，日志显示推送成功，卡片就是显示旧数据。你开始怀疑卡片是不是没刷新，手动杀进程、重新添加卡片，偶尔能好一次，下次又不行。先别急着杀进程，把 updateForm 和 onUpdateForm 的关系理清楚，能省掉一半折腾。 formProvider.up

一个支付倒计时弹窗，毫秒级的进度环加秒级数字。V1 时代跑得好好的，迁到 V2 之后，进度环先走，数字隔一小会儿才跳，连续盯着看几秒就能发现不同步。你怀疑是定时器不准，换了好几种写法，问题还在。其实这不是定时器的问题，是 V2 的状态标脏和刷新调度跟 V1 不一样。V1 的状态变化往往更“即时”，V2 走的是异步标脏、合并刷新，多个状态变化可能分批提交，进度环和秒数不保证同一帧更新。 先

老项目升 HarmonyOS 7，ArkUI 状态管理从 V1 往 V2 迁，最常听到的一句话是“我明明改了值，UI 就是不动”。你打开代码一看，父组件已经老老实实换成了 @ComponentV2，@State 也改成了 @Local，看起来挺像那么回事。再往下翻一层，子组件还是 @Component 配 @State。问题就出在这儿：V