用户把系统的字体大小调到了“特大”，你的应用一打开，列表里的文字截断了一大半，原本整整齐齐的卡片被撑得东倒西歪，按钮上的文字直接从中间折行，甚至底部的 TabBar 都被挤出了屏幕。这不是用户的错，是 UI 布局没抗住动态字体的冲击。 在 HarmonyOS 里，应用默认跟随系统的字体大小缩放。如果在写布局的时候用了一堆绝对数值（比如写死 height(50)），当字体放大时，文字需要更

服务端日志写着 code=80000000, msg=Success，推送请求被 Push Kit 服务端接受了，但用户手机上什么都没弹。这个组合最容易把人带到“再调一次接口”的方向上去，实际上云侧返回成功只代表请求被服务端收下了。端侧展不展示是另一条链路上的事，和云侧的成功码没有因果关系。 推送从服务端到用户眼睛，中间至少要过五道门：应用有没有通知权限、用户有没有关掉对应通道、消息类型

系统切到深色模式，页面背景还是白的，状态栏文字却跟着系统变白了，顶部直接看不见；Text 里写死的 Color.Black 在白底上好好的，切过去和深色背景融为一体；更离谱的是，整个应用退到后台再切回来，部分页面的颜色只反转了一半，看着像个半成品。 这真不是系统的深色模式有 bug，而是代码里写死了颜色，系统只认资源。鸿蒙的深色适配核心思路是“差异化声明出来，交给资源

做性能优化最让人沮丧的，不是找不到优化点，而是找到了耗时长的模块，但工具里显示那一段代码的执行时间明明很短。特别是在 ArkTS 里，当你把大量计算塞进了 TaskPool 里，主线程的 UI 确实不卡了，但如果任务本身慢，用户等的时间依然很长。你打开 Profiler，发现主线程的帧率很平稳，而 TaskPool 里的任务耗时又很难和 UI 的交互建立起直接的联系。 因为跨线

在做商品详情页时，页面整体是可以滚动的（Scroll），中间有一个“猜你喜欢”的横向瀑布流或者一个小型垂直列表（List）。用户的预期是：当我的手指按在列表上滑动时，列表先滚；等列表滚到底部，继续滑动时，外层的页面再跟着滚。这个行为叫嵌套滚动（NestedScroll）。 但很多开发者第一次做这个功能，往往会发现：要么内层列表根本不响应滚动，手势全被外层 Scroll 吃掉了；要么外层 Scrol

移动端的安全测试里，最常见的一个红榜问题就是：抓包工具（如 Charles / Fiddler）只要能装上证书，就能直接看穿你的 HTTPS 请求体。开发者的第一反应是“我明明用了 HTTPS 啊”。用 HTTPS 只能保证传输过程中的加密，但在中间人攻击（MITM）场景下，如果客户端不校验服务端的真实身份，随便一个自制证书都能蒙混过关。 这就轮到证书锁定（SSL Pinning）出场了。在 Ha

用 NAPI 写原生模块，最容易让人产生“我在写 C++”错觉的地方，是 ArkTS 和 C++ 之间的数据传递。在业务侧，传一个 10MB 的 Uint8Array 或者一串极长的文本给底层去处理，看似正常的函数调用，跑起来可能直接导致应用内存暴增甚至直接闪退。排查栈里抛出的往往是一个简单的 Out of memory，根本看不出是哪一行指针出了问题。 问题的核心在

做列表拖拽或者长按弹窗时，最容易遇到的情况是：明明加上了长按手势，但只要手指稍微滑动一点，长按就不触发，列表直接跟着滑了；或者反过来说，只要轻轻一划，系统的滑动响应被长按手势吃掉，列表滑不动。更让人头疼的是，如果在长按里面弹出一个自定义的拖拽浮层，由于手势冲突没处理好，两个节点之间甚至在屏幕上“打架”，谁都不受控。 这种体验断层的根源，在于 ArkUI 的手势系统底层有一套既定的竞争机制。系统为了

上周产品经理跑过来，指着我们的任务管理模块说：“用户提意见了，清单里的任务不能拖拽排序，每次都要手动改优先级数字，太反人类了。这周把长按拖拽排序安排上。” 我寻思着 ArkUI 的原生拖拽能力应该挺完善的，直接加个 draggable 属性不就行了？结果真机一跑，测试同学直接发飙：“我长按想拖拽，结果它直接触发了侧滑菜单！好不容易拖起来了，原来位置的卡片直接塌陷，整个列表疯狂闪动。”为了填平这个交

产品经理非要给应用加个“实时待办”的桌面卡片，要求用户在主应用勾选完成后，桌面卡片上的数据必须瞬间刷新。我一开始为了省事，直接用了系统的定时刷新机制，结果被用户疯狂吐槽延迟太高。后来重构了数据更新链路，才把刷新延迟做到了毫秒级，这其中的进程隔离和跨端通信细节，值得好好复盘一下。 理解卡片进程的天然隔离 做卡片开发，最容易犯的错就是用写普通 ArkUI 页面的思维。你如果在卡片里直接写个定时器或者发