本地通知携带 WantAgent，用户点通知，应用冷启动，详情页打开了，但商品 ID 是 undefined。热启动测试一切正常，杀进程再点，参数就丢。你去看 WantAgent 的构造，参数明明塞进去了。 冷启动走的是 onCreate(want) → onWindowStageCreate → onForeground，根本不经过&n

抽了一个公共工具包，里面写了一个 ConfigManager 单例，登录态、缓存、全局开关都挂在上头。Entry HAP 里初始化完，Feature HAP 里读出来是空的。你以为是初始化时机的问题，把 onCreate 顺序调了又调，还是空。 根因在 HAR 的打包方式：HAR 是编译期静态共享包，每个引用它的 HAP 或 HSP 都会各自编译进去一份代码

两个 UIAbility 跑在独立进程里，一个写“最后浏览位置”，一个写“主题语言”。单独测都正常，一起跑就频繁丢数据，而且没有规律。你 await 了每一次 put 和 flush，返回值全是成功，日志里干干净净。 官方文档的原话是“首选项无法保证进程并发安全，会有文件损坏和数据丢失的风险，不支持在多进程场景下使用”。措辞不是“不建议”，是“不支

平板或折叠屏展开，左侧列表右侧详情看起来很美。用户点进详情，再点返回，应用直接退到桌面。你查返回键监听，没发现问题；查页面栈深度，发现 router 的栈里只有一层，详情页压根没进去过。 根因通常只有一句话：应用还在用 router.pushUrl 管列表-详情，而平行视界只接管 NavPathStack 的路由栈。系统眼里，右栏详情不是

把批量文件解析、图片压缩、大数据排序扔进 TaskPool，是性能优化里最顺手的动作。你在主线程 new 了一个业务 Bean，字段干干净净，类上也老老实实加了 @Sendable，taskpool.execute(task, bean) 一跑，直接抛 Object is not Sendable。你翻来覆去看这个类，确实只有 name、

产品提需求：应用里加“跟随系统 / 浅色 / 深色”三档开关。你调了 setColorMode，应用内三档切换完美。然后去系统设置里切了一下深色模式，App 纹丝不动。更奇怪的是，即使用户切回“跟随系统”，系统再切深色浅色，onConfigurationUpdate 也再也不触发了。 根因不是监听写错了，是 setColorMode 的语义不是“建议”，是覆

两台设备协同编辑同一份数据，WiFi 切换、蓝牙断连重连，重连之后两边的 UI 状态对不上。你去查 distributedDataObject 的同步机制，会发现它采用的是最终一致性模型：本地写入立即生效，跨设备同步存在延迟，断连期间两端各自的写入会产生冲突，而系统底层不提供自定义冲突策略的接口，默认行为就是后写覆盖先写。 指望框架自动“对齐”是不现实的。稳定的做法不在框架层，

通知渠道在 HarmonyOS 里不是一个分类标签，它是系统决定“这条通知用什么方式打扰用户”的总开关。SlotType 填错，最迷惑的表现不是报错，是通知发出去之后横幅没有、声音没有、锁屏不显示，用户只能自己去通知中心翻。 SOCIAL_COMMUNICATION 对应 IM、VOIP、未接来电，横幅、锁屏、铃声振动全开；SERVICE_INFORMATION 对应

登录页、聊天页、表单页，输入框一获焦，顶部标题飞出屏幕、底部按钮被遮住、导航栏错位。第一反应是给顶部元素加 expandSafeArea([SafeAreaType.KEYBOARD], [SafeAreaEdge.TOP])，期望它“钉”在原位。结果一点用都没有，甚至更糟。 expandSafeArea 的语义是让组件延伸到安全区域里，而不是避开安全区域。键盘弹出时，系统把键

做待办清单、歌单、收藏夹排序，第一反应往往是去翻 List 的 onItemDragStart、onItemDragMove、onItemDrop 这一套回调。文档里有、类型声明也在、编译不报错，但真机长按拖起来之后，三个回调一次都不进。这不是你的写法有问题，是这套旧 API 在 HarmonyOS 7 里已经走不通了。 旧路依赖 ListItem