电子名片这页最值得学的，不是把卡片做得多像真名片，而是它把“我的展示页”和“我的联系人记录”拆成了两个任务场景，再用一个可切换密度的CardView()把它们收进同一套组件协议里。这样的结构后续无论扩成详情页、编辑页还是轻量 CRM，都还有很好的延展空间。

旅行地图清单页 这个案例并不靠复杂技巧取胜，它更像一个结构扎实、逻辑完整的业务页面样板。把这篇文章里的状态设计、函数组织和页面分层吃透之后，你再去写同类型功能，速度会明显快很多。

详情页经常被低估。很多人觉得它不过是把头像、姓名、电话、邮箱这些字段排出来，但真正写起来才会发现，详情页最难的地方不是信息展示，而是“展示态”和“操作态”怎么共存在一页里还不显得混乱。这样的页面结构，已经很接近真实通讯录、CRM 客户详情页或者社交资料页的工作方式。这篇详情页案例最值得借鉴的，是它把展示内容、快捷动作、渐进展开和局部编辑放进了一页统一的状态结构里。你把“主数据”和“编辑上下文”这两

拼图游戏这种案例，表面上看像是一个轻量互动页面，实际上很适合拿来练状态建模。因为它不像普通表单那样只有“输入”和“提交”，而是需要持续追踪棋盘布局、可移动范围、计时器、步数统计和完成判定。只要其中一条状态链没有理顺，游戏就会出现各种不一致的问题。这个 HarmonyOS 示例的价值就在这里：它没有追求复杂玩法，而是用一个 3x3 九宫格，把最基本的一套游戏状态机搭了出来。对初学者来说，这种体量刚好

交通出行类页面有一个很鲜明的特点：同一页里经常既有“账户信息”，又有“流水记录”，还会顺带夹带一个高频操作入口，比如充值、开票或者补登行程。页面如果没有把这三类信息组织好，用户会觉得内容很多，但抓不到重点。这个 HarmonyOS 示例值得看的地方，就在于它没有把乘车记录页写成单纯的列表页，而是做成了一个典型的“账户首页”。上半部分先用余额卡片建立账户感知，中间再用 tab 把明细和统计拆成两种阅

订单列表页看上去只是把几张卡片排出来，真正难的地方其实在于：同一份订单数据要同时服务筛选栏、状态标签、商品列表、金额汇总和底部操作按钮。只要这几个区域没有围绕同一个状态模型来组织，页面就会很快变成一堆条件分支的拼接。这个 HarmonyOS 示例比较适合拿来讲“电商业务页怎么把展示逻辑和业务语义绑在一起”。它没有引入复杂网络层，也没有拆出一堆组件，但已经把订单页最核心的几件事做全了：订单状态切换、

语音备忘录类页面经常给人一种“功能不多，随便做做就行”的错觉。实际上，这类页面一旦放到真实应用里，马上会碰到几个很具体的问题：录音列表怎么快速浏览，播放状态怎么避免互相打架，分类和搜索怎么同时生效，底部录音入口怎么既醒目又不抢内容。给出总条数。给出全部录音总时长。这两项信息放在标题下方，其实是在告诉用户当前素材库的大致规模。对媒体管理类页面来说，这种摘要信息会让列表显得更“有内容感”。catego

健康类页面最常见的问题，不是界面不够花，而是数据虽然很多，用户却很难一眼看明白。吃了多少、还剩多少、哪一餐超了、蛋白质够不够，这些问题如果只是把原始记录堆在列表里，页面就只能算“记账”，不能算“分析”。这个案例的价值，在于它已经不只是展示食物清单，而是开始把原始饮食记录往“结果视图”上做转换。也就是说，它在练的不是单纯布局，而是如何用 HarmonyOS7 的状态和派生函数，把饮食数据组织成一个真

闹钟页面是一个非常典型的“小功能看起来简单，真正做起来全是细节”的案例。时间显示要直观，开关切换要即时，重复规则要让人一眼看懂，新增面板还得保证录入过程不别扭。只要其中一个环节处理得粗糙，用户就会觉得这个工具“不顺手”。HarmonyOS7 里一个闹钟管理页，到底该怎么组织状态、怎么表达重复周期、怎么把列表展示和新增交互接起来。它虽然只是一个示例，但里面已经包含了工具类应用最常见的交互骨架。适用场

求职类页面看起来不复杂，本质上却很容易写成“只能展示、不能管理”的半成品。真正好用的简历追踪页，至少要回答三个问题：现在投了哪些公司、每一条记录走到哪一步、下一次该跟进什么动作。如何用 HarmonyOS7 的 ArkUI 状态系统，把投递记录、筛选条件、搜索输入和进度推进串成一个完整闭环。你看完之后，拿这套思路去做求职管理、销售跟单、客户进度页，基本都能复用。适用场景：求职记录、招聘助手、候选人