文章目录前言代码讲解页面入口怎么安排数据模型先稳住状态变量控制页面反馈布局代码不要从样式开始读Builder 和方法承担复用使用方式完整代码关键代码解析interface 不是摆设State 是交互的开关列表和卡片要靠数据驱动事件回调要短一点样式参数别急着抽常量总结前言消息列表适合讲分组和未读数。用户点一下消息UI 上至少要有明确反馈。我建议把这篇当成一个可以直接改造的 ArkUI 页面模板来看。先跑起来确认页面展示和交互都正常再把里面的模拟数据替换成接口数据最后再调整颜色、间距和业务字段。这样改起来比较稳不容易一边改样式一边把状态逻辑弄乱。这篇文章会按「页面意图、数据结构、状态流转、布局组织、交互细节」这条线来读代码。你不用从第一行样式硬看到最后先抓住主线后面的细节会轻松很多。代码讲解页面入口怎么安排代码里的入口组件是GroupedMessageListPage。如果你把它当成单独页面预览保留Entry就可以如果要塞进现有工程的路由体系通常会去掉Entry再由外层页面或路由模块统一管理。这个习惯很重要。一个项目里入口页面太多预览时容易混后期拆组件也会麻烦。我的做法是案例阶段保留入口接业务时只保留真正需要被路由访问的页面。数据模型先稳住本案例涉及的数据模型主要有ChatMessage_va9m。这些interface的作用不是为了“看起来规范”而是给 UI 层划边界。比如列表项需要标题、描述、颜色、选中态就应该在模型里说清楚。后续从接口拿数据时可以在请求层做字段映射别让后端字段名直接污染页面代码。如果你准备接真实业务建议把模拟数组替换成接口返回后的 ViewModel。页面只关心自己要渲染什么不关心接口原始字段长什么样。状态变量控制页面反馈本案例里的关键状态包括messageList。State的职责是让 UI 对用户操作有反馈。比如选中某个卡片、切换分类、展开内容、修改输入值、控制加载中状态这些都应该由状态驱动。状态一变相关 UI 自动刷新这也是 ArkUI 声明式开发最核心的体验。这里有个容易踩的坑不要把所有数据都塞进State。静态配置用普通数组就够了只有用户会改、接口会更新、页面需要重新渲染的数据才适合放进状态里。布局代码不要从样式开始读这个页面里比较关键的组件有Row横向排列、左右分栏、按钮组或卡片行都依赖它来控制水平方向的节奏。Column纵向组织标题、内容、操作区适合搭页面主骨架。Stack负责图层叠放常见于角标、遮罩、封面文字压图。List适合长列表和分组列表重点是数据过滤、滚动和状态同步。ListItemGroup适合按日期、分类、字母分组还能处理吸顶标题。读布局时我更建议先找大容器再看内部如何拆块。比如一个页面通常会先用Column纵向放标题区、内容区、操作区内容区里再用Row、Grid、List或其他容器细分。这样看代码层级会比逐行看.padding()、.fontSize()清楚得多。如果页面显示错位优先检查容器关系而不是马上改像素。很多问题不是某个.margin()不对而是外层容器的宽高、滚动方向、权重分配或对齐方式没想清楚。Builder 和方法承担复用代码中拆出的 Builder 主要有GroupHeader、MessageRow。辅助方法主要有getGroupMsgs、getTotalUnread、clearUnread。Builder更适合复用 UI 片段比如卡片、列表行、头部区域、按钮组。普通方法更适合放计算逻辑比如筛选列表、统计数量、切换状态、生成颜色。两者分清楚后页面会干净很多。我不建议把所有东西都塞进build()。刚开始代码少还行需求一多build()会变成几百行后面改一个按钮都要找半天。使用方式把下面的完整代码放到 ArkTS 页面文件里即可运行。文章中的组件名已经是语义化命名不包含编号式案例名称接路由时直接使用GroupedMessageListPage就行。如果你要改成业务页面优先改三处数据模型、状态变量、事件方法。样式可以后调先保证数据流和交互是通的。完整代码// GroupedMessageListPage: 列表项分组 - ListItemGroup 分组列表 // 知识点: ListItemGroup、header/footer、sticky 吸顶效果、分组展开收起 interface ChatMessage_va9m { msgId: number senderName: string senderEmoji: string senderBg: string lastMessage: string msgTime: string unreadCount: number isPinned: boolean isMuted: boolean groupType: string } Entry Component struct GroupedMessageListPage { State messageList: ChatMessage_va9m[] [ { msgId: 1, senderName: 产品设计群, senderEmoji: , senderBg: #FFE4E1, lastMessage: 明天上午10点开产品评审会, msgTime: 刚刚, unreadCount: 5, isPinned: true, isMuted: false, groupType: 置顶 }, { msgId: 2, senderName: 小美, senderEmoji: , senderBg: #FFE4F4, lastMessage: 那个文档发我一份~, msgTime: 1分钟前, unreadCount: 2, isPinned: true, isMuted: false, groupType: 置顶 }, { msgId: 3, senderName: 技术一群, senderEmoji: , senderBg: #E0EFFF, lastMessage: [图片], msgTime: 10分钟前, unreadCount: 0, isPinned: false, isMuted: false, groupType: 今天 }, { msgId: 4, senderName: 项目组, senderEmoji: ️, senderBg: #E8F5E9, lastMessage: 李工看一下最新的需求文档, msgTime: 32分钟前, unreadCount: 12, isPinned: false, isMuted: false, groupType: 今天 }, { msgId: 5, senderName: 阿豪, senderEmoji: , senderBg: #FFF3E0, lastMessage: 晚上打球吗, msgTime: 1小时前, unreadCount: 1, isPinned: false, isMuted: false, groupType: 今天 }, { msgId: 6, senderName: 老妈, senderEmoji: , senderBg: #FFF9C4, lastMessage: 记得吃饭别太晚, msgTime: 3小时前, unreadCount: 0, isPinned: false, isMuted: false, groupType: 今天 }, { msgId: 7, senderName: 同学会群, senderEmoji: , senderBg: #F3E5F5, lastMessage: 大华同学们线下聚会定下来了, msgTime: 昨天, unreadCount: 0, isPinned: false, isMuted: true, groupType: 更早 }, { msgId: 8, senderName: 小王, senderEmoji: , senderBg: #E1F5FE, lastMessage: 那个项目资料我整理好了, msgTime: 昨天, unreadCount: 0, isPinned: false, isMuted: false, groupType: 更早 }, { msgId: 9, senderName: 购物通知, senderEmoji: , senderBg: #FCE4EC, lastMessage: 您的订单已发货单号12345…, msgTime: 2天前, unreadCount: 0, isPinned: false, isMuted: true, groupType: 更早 }, ] getGroupMsgs(groupType: string): ChatMessage_va9m[] { return this.messageList.filter(m m.groupType groupType) } getTotalUnread(): number { return this.messageList.reduce((sum, m) sum m.unreadCount, 0) } clearUnread(msgId: number) { this.messageList this.messageList.map((m: ChatMessage_va9m) { if (m.msgId msgId) { m.unreadCount 0 return m } return m }) } Builder GroupHeader(title: string, count: number, color: string) { Row({ space: 8 }) { Text(title) .fontSize(13) .fontWeight(FontWeight.Bold) .fontColor(color) .layoutWeight(1) if (count 0) { Text(${count} 条未读) .fontSize(11) .fontColor(#EF4444) .padding({ left: 6, right: 6, top: 2, bottom: 2 }) .backgroundColor(#FFF0F0) .borderRadius(8) } } .width(100%) .height(36) .padding({ left: 16, right: 16 }) .backgroundColor(#F8F9FA) .alignItems(VerticalAlign.Center) } Builder MessageRow(msg: ChatMessage_va9m) { Row({ space: 12 }) { // 头像Stack 实现角标 Stack({ alignContent: Alignment.TopEnd }) { Text(msg.senderEmoji) .fontSize(28) .width(50) .height(50) .textAlign(TextAlign.Center) .backgroundColor(msg.senderBg) .borderRadius(25) if (msg.unreadCount 0) { Text(msg.unreadCount 99 ? 99 : msg.unreadCount.toString()) .fontSize(9) .fontColor(#FFFFFF) .fontWeight(FontWeight.Bold) .padding({ left: 4, right: 4, top: 1, bottom: 1 }) .backgroundColor(#EF4444) .borderRadius(9) .border({ width: 1.5, color: #FFFFFF }) .constraintSize({ minWidth: 18, minHeight: 16 }) .textAlign(TextAlign.Center) .offset({ x: 4, y: -4 }) } } .width(50) .height(50) .flexShrink(0) Column({ space: 5 }) { Row({ space: 0 }) { Text(msg.senderName) .fontSize(15) .fontWeight(FontWeight.Medium) .fontColor(#1A1A1A) .layoutWeight(1) .maxLines(1) .textOverflow({ overflow: TextOverflow.Ellipsis }) Text(msg.msgTime) .fontSize(11) .fontColor(#BBBBBB) .flexShrink(0) } .width(100%) .alignItems(VerticalAlign.Center) Row({ space: 4 }) { Text(msg.lastMessage) .fontSize(13) .fontColor(#999999) .layoutWeight(1) .maxLines(1) .textOverflow({ overflow: TextOverflow.Ellipsis }) if (msg.isMuted) { Text() .fontSize(12) .flexShrink(0) } } .width(100%) .alignItems(VerticalAlign.Center) } .layoutWeight(1) } .width(100%) .height(72) .padding({ left: 16, right: 16 }) .backgroundColor(#FFFFFF) .alignItems(VerticalAlign.Center) .onClick(() { this.clearUnread(msg.msgId) }) } build() { Column({ space: 0 }) { // 顶部标题 Row({ space: 0 }) { Text(消息) .fontSize(20) .fontWeight(FontWeight.Bold) .fontColor(#1A1A1A) .layoutWeight(1) if (this.getTotalUnread() 0) { Text(${this.getTotalUnread()} 未读) .fontSize(13) .fontColor(#FFFFFF) .fontWeight(FontWeight.Bold) .padding({ left: 10, right: 10, top: 4, bottom: 4 }) .backgroundColor(#EF4444) .borderRadius(12) } Text(➕) .fontSize(20) .margin({ left: 12 }) } .width(100%) .height(56) .padding({ left: 16, right: 16 }) .backgroundColor(#FFFFFF) .border({ width: { bottom: 1 }, color: #F0F0F0 }) // 搜索框 Row({ space: 8 }) { Text() .fontSize(16) .fontColor(#BBBBBB) Text(搜索) .fontSize(14) .fontColor(#CCCCCC) .layoutWeight(1) } .width(100%) .height(36) .padding({ left: 12, right: 12 }) .backgroundColor(#F5F5F5) .borderRadius(8) .margin({ left: 12, right: 12, top: 8, bottom: 8 }) // 分组消息列表吸顶效果 List({ space: 0 }) { // 置顶分组 ListItemGroup({ header: this.GroupHeader( 置顶, this.getGroupMsgs(置顶).reduce((s, m) s m.unreadCount, 0), #EF4444) }) { ForEach(this.getGroupMsgs(置顶), (msg: ChatMessage_va9m) { ListItem() { this.MessageRow(msg) } }, (msg: ChatMessage_va9m) msg.msgId.toString()) } .divider({ strokeWidth: 0.5, color: #F5F5F5, startMargin: 78 }) // 今天分组 ListItemGroup({ header: this.GroupHeader(今天, this.getGroupMsgs(今天).reduce((s, m) s m.unreadCount, 0), #333333) }) { ForEach(this.getGroupMsgs(今天), (msg: ChatMessage_va9m) { ListItem() { this.MessageRow(msg) } }, (msg: ChatMessage_va9m) msg.msgId.toString()) } .divider({ strokeWidth: 0.5, color: #F5F5F5, startMargin: 78 }) // 更早分组 ListItemGroup({ header: this.GroupHeader(更早, 0, #888888) }) { ForEach(this.getGroupMsgs(更早), (msg: ChatMessage_va9m) { ListItem() { this.MessageRow(msg) } }, (msg: ChatMessage_va9m) msg.msgId.toString()) } .divider({ strokeWidth: 0.5, color: #F5F5F5, startMargin: 78 }) } .sticky(StickyStyle.Header) .scrollBar(BarState.Off) .edgeEffect(EdgeEffect.Spring) .layoutWeight(1) .backgroundColor(#FFFFFF) } .width(100%) .height(100%) .backgroundColor(#F5F6FA) } }关键代码解析interface不是摆设很多新手写 ArkUI 页面时会直接在ForEach里使用一堆临时对象。页面小的时候没问题但字段一多就很难知道每个字段到底用于哪里。本案例把数据结构提前声明出来读代码时能很快判断每个 UI 区块依赖哪些字段。后续如果接接口也建议保留这层结构。接口可以变页面模型尽量稳定。这样页面不会因为后端多返回一个字段、少返回一个字段就跟着大改。State是交互的开关本案例的交互反馈都围绕状态展开。点击、切换、输入、刷新这类行为本质上都是修改某个状态值然后让 UI 重新计算显示结果。写这类代码时有一个简单判断如果某个值变化后页面应该立刻变那它大概率应该是状态如果它只是配置项、静态文案、固定颜色就不要放进状态。列表和卡片要靠数据驱动只要页面里出现重复结构就应该优先想到数据数组加ForEach。这样新增一项、删除一项、调整顺序都只动数据不用复制粘贴一段 UI。这个案例的完整代码里已经把主要内容抽成数组或方法。你可以试着多加一条数据看页面是否能自然渲染出来。如果能说明结构是健康的如果加一条就要改很多 UI说明组件拆分还不够。事件回调要短一点.onClick()、onChange()这类回调里可以直接改状态但不建议堆太多逻辑。简单切换可以写在回调里复杂逻辑最好拆成方法。这样做有两个好处一是读页面结构时不会被业务逻辑打断二是后面要加埋点、请求接口、异常处理时有明确的位置可以改。样式参数别急着抽常量这个案例里有不少颜色、间距、圆角、字号。学习阶段直接写在组件链上反而更容易看出效果。等你确定页面风格稳定后再把主题色、通用间距、卡片圆角提到统一常量里。过早抽象会让示例代码变绕。先让页面清楚再谈工程化这是我比较推荐的顺序。总结这个案例真正值得学的不只是某个 ArkUI 组件怎么写而是一个页面如何从数据走到状态再走到布局和交互。你可以按这个顺序改造先替换数据模型再确认状态更新是否正确接着调整布局容器最后打磨样式细节。只要这条主线不乱页面规模变大也不会失控。如果后续继续扩展我会优先把可复用的卡片、列表行、筛选栏或控制区拆成独立组件。这样主页面只保留数据和流程代码会更接近真实项目里的写法。