状态改了，页面却没动。这类问题刚开始会让人怀疑 ArkUI 的刷新机制，其实大多数时候不是框架没刷新，而是代码没有给 UI 一次清楚的状态变化。尤其是数组和对象，最容易踩坑：你改了对象里面的字段，但页面真正观察的是外层引用；你改了数组某一项，但没有把新数组赋回@State。排查状态问题时，先找 UI 读了什么，再看事件到底改了什么。比较稳的做法是分三步走：先把结构和职责立住，再把真实业务接进去，最

不是“更高级的 ForEach”。如果页面只有十几个固定入口，普通ForEach更直接，代码也更好读。适合的是另一类场景：数据量比较大，列表项比较重，并且数据源需要主动通知列表增删改。我看到过一种误用：列表只有十来项，也硬套，最后为了维护数据源写了一堆样板代码。页面没变快，代码先变复杂了。性能优化要有场景，不要把每个列表都写成最复杂的版本。你可以把理解成“给长列表准备的专业工具”，而不是“所有列表

优惠券卡片最怕信息堆在一起：金额很大，但门槛看不清；按钮很醒目，但用户不知道是否已领取。HarmonyOS7 里写这个页面，我更关心信息顺序和状态表达。这篇单独聊优惠券这个场景。重点不是堆 API，而是把金额、门槛、有效期和领取态拆清楚，让一张卡片能支撑真实领取流程。接领取接口时，可以先把status乐观改成received，失败后再恢复，也可以等接口成功后再更新。无论哪种方式，都要保证按钮文案、

订单状态时间线看起来只是几条记录，实际承担的是用户对订单进度的信任感。当前走到哪一步、有没有异常、用户下一步能做什么。这篇单独聊物流详情这个场景。重点不是堆 API，而是把订单节点、异常提示和刷新反馈放进一个真实页面里，看 ArkUI 布局怎么和 ArkTS 状态配合。如果后续接真实接口，刷新时建议整体替换steps数组，而不是只修改数组里某个对象字段。时间线经常会插入新节点或调整顺序，稳定的业务

消息列表前十条怎么写都能跑，真正麻烦的是后面：分页、已读未读、删除、置顶、加载失败、空态一起出现。HarmonyOS7 里的List很适合承载长内容，但前提是行数据、key 和状态更新方式要稳定。如果只是把一个大数组全量丢进ForEach，再把加载逻辑写得七零八落，页面迟早会不好维护。长列表的第一原则是行可复用、状态可追踪。这篇用一个消息中心做例子，看看ListForEach、稳定 key 和分页

Tabs做页面切换很简单，真正容易乱的是状态边界。我见过不少频道页，父页面同时管理当前下标、每个频道的列表、刷新状态、空态、错误态，最后一个页面变成几百行。刚开始还能改，等产品说要加“本地”“关注”“热榜”，就开始牵一发动全身。Tabs 页面要稳，父级只管频道配置和当前索引，频道内容自己处理自己的业务。这篇用 HarmonyOS7 写一个资讯频道页，重点看TabsTabContent@Builde

九宫格菜单看起来只是把入口排整齐，但它其实承担了首页导航效率。用户要找扫一扫、付款码、账单、客服，第一眼扫不到，就会觉得页面不好用。HarmonyOS7 里用Grid做九宫格很快，几行代码就能铺出来。真正要注意的是：入口有没有稳定身份，角标会不会挤压标题，禁用态是不是只改了颜色。工具入口不要只存标题，至少要有业务 id、展示文案、状态字段和点击目标。比较稳的做法是分三步走：先把结构和职责立住，再把

这篇继续聊 HarmonyOS7 里的Badge 综合聊天角标。如果你刚开始学 ArkUI，不建议一上来就背属性名，那样很容易看完就忘。更好的方式是先搞清楚：这个页面想解决什么问题，用户做了什么操作，代码又是怎么把这个操作反映到界面上的。这个案例的核心是Badge，它对应的使用场景是消息提醒。我会把它当成一个真实业务里的小模块来拆，而不是只贴一段代码结束。问题答案学什么Badge在消息提醒场景里的

商品卡片看起来很小，但它经常是电商页面里最容易变复杂的组件。一开始只有图片、标题、价格。要是Column和Row一开始没有分工，后面每加一个字段，布局都要跟着抖一下。商品卡片不是把内容塞进去就完事，重点是先把信息层级定住。这篇用 HarmonyOS7 的 ArkUI 写一个商品卡片。代码不追求花哨，重点看三件事：图片区怎么固定，信息区怎么伸缩，操作区怎么跟状态绑定。比较稳的做法是分三步走：先把结构

首页 Banner 很容易被写成一个巨大的Stack：背景放进去，标题放进去，按钮放进去，角标也放进去。视觉稿刚开始能还原，但运营一改文案、一加倒计时，层级就开始互相压。Stack不是不能用，它本来就适合做叠层。问题在于，Banner 不是一张图加几行字，它是一个会被频繁运营的入口。这篇用 HarmonyOS7 写一个首页 Banner。重点不是把效果做得多炫，而是把背景层、内容层、状态层分清楚，