List、ForEach 与“懒加载”展示页从 ArkTS 页面读懂状态、条目与实现边界这是一个很小的 ArkTS 单页应用。它把消息、联系人和“数据量”这三种经常出现在列表页面里的话题放在了同一张页面上顶部有三个页签第一页展示五条消息第二页展示五位联系人第三页有一个“追加 1000”按钮和四条示例文字。打开应用后即可看到这套连续的页面内容。页面标题里同时出现了 List 和 LazyForEach很容易让人把它当成已经完成的长列表示例。实际可见行为是当前页面没有使用List或LazyForEach重复内容由ForEach生成第三个页签也没有一万条真实数据按钮只会把一个计数状态增加一千下方始终只有四条固定文字。它更适合用来观察列表页面的结构与状态并把“按需构建的大列表”与当前体验明确分开。初始画面中五条消息卡片的排列还体现了页面对信息密度的控制。消息标题使用相对醒目的深色具体内容采用较小的灰色文字左侧圆形编号形成连续的视觉节奏右侧状态词则让用户知道每一行都可以被进一步查看。五条内容之间留出稳定的空隙卡片没有额外的头像、时间和操作菜单因此用户可以把注意力集中在「哪一条被选中」这一个变化上。页面没有将消息做成横向滑动卡片也没有用弹窗承载详情首次打开后从上到下就能看完整个基础列表。当用户先切换到联系人再返回基础列表时消息区依然从第一页开始显示页面没有把联系人文字混入消息卡片。随后点击某一条消息变化只发生在被点击的卡片内部编号圆形换成紫色右侧文字换成“已读”标题和摘要不变。这个对照可以帮助读者把「内容本身」和「当前选中状态」分开理解。内容是固定的状态是临时的状态变化不会改写消息文字也不会把消息移到其他位置。先运行再确认自己看到的是什么打开应用即可进入这张页面。启动后屏幕上看到的是标题、三个页签和当前页签内容没有隐藏的第二页面也没有需要先填写的路由参数。初始状态下标题为“列表与懒加载”副标题为“基础列表 · 分组联系人 · 按需加载”。下面三个等宽页签分别是“基础列表”“分组列表”“懒加载”。默认第一个页签处于蓝底白字状态内容区域标题为“消息列表”依次显示五张白色卡片。每张卡片左侧是蓝色圆形序号中间是“第 n 条消息”和一行具体消息右侧为“查看”。这个页面没有网络请求、数据库读取、下拉刷新或跳转详情。消息和联系人都是页面内置的固定文字。把运行范围看清楚能避免两个常见误解其一右侧的“查看”只是当前条目的状态提示不会打开新页面其二页面提到“按需加载”并不等同于已经接入了真实的数据分页或虚拟滚动。对于刚开始写 ArkTS 页面的人来说先能准确说清一个页面做了什么往往比先把概念名背下来更重要。代码的起点两组静态数组和三个可观察状态页面文件最上方定义了两组string[]。MESSAGES中有“项目进度已更新”“今晚 8 点团队会议”“新的设计稿已上传”“测试环境已部署”“用户反馈待处理”五条内容MEMBERS中有“家人 · 爸爸”“家人 · 妈妈”“同事 · 张三”“同事 · 李四”“好友 · 小美”五条内容。它们是普通常量不会在点击后被修改也不需要标注状态装饰器。真正会被用户操作改变的是页面关注的三个状态。一个状态保存正在显示的页签编号一个状态保存被点中的消息下标另一个状态保存第三页按钮累计增加的数量。它们都是数字初始值也都很直观。状态发生变化时使用它们的文字、颜色和内容会重新呈现。tab初始为 0所以第一页先显示。selected初始为 -1而消息的下标只会是 0 到 4因此刚启动时没有任何一条消息满足“已选中”的判断。extraCount从 0 开始第三页的总数文案就先显示为 10000。选择 -1 作为“不选中”的哨兵值在这种固定、从零开始的下标场景里是清晰的它并没有额外的业务含义也不是某个消息 ID。把这三个状态分开是这段代码最值得保留的地方。页签切换不会改变已读的消息点消息不会自动跳到其他页签点击“追加 1000”也不会触碰前两页的数据。它们虽然同处一个组件却各自只负责一类可见变化。初学者常见的写法是只声明一个笼统的对象再把不相关的字段都塞进去在本页这样简单的场景里三个明确字段反而更容易沿着点击事件追踪结果。需要同时注意selected只能记录一个下标。先点第 2 条再点第 4 条时第 2 条会恢复“查看”与蓝色圆形第 4 条转为“已读”与紫色圆形。代码并没有“已读集合”更没有把阅读状态写回消息数组。也就是说画面表示的是“最近一次被点的消息”不是一个可累积保存的消息已读功能。它足以讲清条件样式和状态驱动渲染但不能据此推断真实聊天应用也应使用同样的数据模型。组件树一个可滚动页面三段条件内容页面外层是滚动容器内部内容按纵向排列。最外层设置了百分百宽高和浅灰背景内部列设置统一的左右内边距。这个组合很朴素内容纵向排布内容高度超过屏幕时由滚动容器承接页面边缘留出统一的空白。标题区域是一行横向内容。左侧放标题和副标题占据剩余空间右侧的蓝色小标签用于提示这是一个示例页。左侧占据剩余空间后说明文字和标签会自然分布在行的两端页面顶部不会显得拥挤。标题下方又是一个Row({ space: 8 })其中连续调用三次this.Tab(...)。每个Tab都设置layoutWeight(1)所以三个页签会平分一行可用宽度space: 8只在它们之间留缝。此处没有系统自带的 Tabs 容器完全是三个可点击文本用同一段 Builder 画出来的。因此页签的切换逻辑也很直接点击哪一个就把它传入的索引写给this.tab。第三层根据当前页签显示对应内容第一个页签显示消息列表第二个页签显示联系人分组第三个页签显示数据量演示。页面只展示当前选中的一块内容而不是把三块内容同时堆在屏幕上再隐藏。切换页签时顶部高亮和内容区域会一起变化。页面的可滚动性也要实事求是地理解。外层确实使用了Scroll所以在较小屏幕、字体放大或内容超过可视高度时整页可以垂直滚动但它并没有因此变成针对大量条目的List。Scroll Column ForEach很适合少量、结构简单的内容例如这里的五条消息。数据量持续增大时问题不是“能不能滚动”而是每一项是否被持续创建、测量和绘制当前页面没有针对那个问题做处理。页签 Builder同一套外观三次不同的参数调用三个页签由一段可复用的 Builder 负责绘制。它接收一个数字和一段文字统一设置字号、字重、颜色、布局权重、居中、内边距、背景、圆角和点击行为。把共同外观集中处理的价值不在于少写几行而在于三个页签始终采用相同的视觉和交互规则。当前页签的编号决定样式。选中时文字加粗、使用白色并配蓝色背景未选中时使用常规字重、灰蓝色文字和浅灰背景。点击“分组列表”后选中编号变成第二项第一项恢复未选中样式第二项变成高亮内容区域也从消息切换到联系人。无需手动修改多个控件界面会根据状态重新呈现。这体现了声明式 UI 的实用习惯界面是什么样写成状态的结果用户做了什么限制为更新状态。从页面行为看页签没有禁用态、长按态、焦点态、滑动切换、动画或额外的可访问性描述。默认总是显示第一项。不要因为页面长得像选项卡就自动补上这些未实现的能力。当前 Builder 的职责只有三项显示名字、显示选中样式、在点击时切换索引。还有一个容易忽略的细节页签 Builder 与页面状态处在同一个作用域因此可以直接读取当前选中项并在点击时更新它。如果把这段 UI 拆成独立组件状态归属与回调接口就需要重新设计。对于只有三个页签、只在一个页面出现的场景把 Builder 放在当前页面里是合理的局部复用它不是一个已经抽象完成的通用导航组件。基础列表ForEach、稳定 key 与一条消息的状态变化当第一项页签被选中页面先显示“消息列表”标题再按顺序生成五条消息卡片。每条数据都带有自己的位置标识页面用它来识别同一项而不是把用户看到的圆形序号当成数据身份。五个消息文本目前互不相同也不在运行时改变所以这组固定数据能够保持稳定对应。需要强调这一点是因为真实消息的标题通常不适合作为唯一标识。两条消息可能恰好有相同文案文案也可能被编辑或本地化如果标识重复或频繁变化更新时就难以准确对应旧项与新项。带动态数据的消息页更适合使用不可变的消息 ID。当前页面数据固定所以采用文本标识足以支撑这次展示但它不是所有列表的通用规则。每个消息项由第二个 Builder 负责绘制。整个条目是一行横向内容宽度占满父容器内边距 14白色背景和 16 的圆角。左边序号区域宽高都为 38文字居中圆角为 19形成圆形。数据位置从零开始而界面编号从一开始这是显示规则不会改变数据位置。圆形颜色由当前选中位置决定。未选中时为蓝色选中时为紫色。中部列占据剩余空间第一行是“第 n 条消息”第二行显示具体内容第二行使用灰色。右侧根据是否选中显示“已读”或“查看”。这段文字没有单独的点击事件整张消息卡片才是可点击区域。点任意卡片当前选中位置就被替换为该项下标。因为所有消息卡片都读取同一个选中状态新的那一项满足条件旧的那一项不再满足条件。于是你会看到一个紫色圆形和一个“已读”而不是五条消息分别独立保存读过与否。将这种现象亲手点一遍比只读“状态会触发刷新”的解释更能理解状态是怎样影响多个位置的。页面也没有阻止重复点击。已经显示“已读”的条目再次点击selected被赋为相同的数字视觉上没有新的变化。这是预期内的因为没有计数、时间戳或切换逻辑。右侧“查看”也不代表存在详情操作从代码可知点击整行只设置了selected没有导航、弹窗、打印或请求。把文案和功能分开验证是避免读示例时想当然的重要习惯。MessageItem 的布局为何看起来像一张完整卡片这段 UI 没有使用图片、图标资源或自定义绘制卡片感完全来自基本组件和尺寸关系。外层白底圆角在浅灰页面背景上形成清晰边界固定 38 的序号圆形提供视线起点中间列用 3 的纵向间距把标题与摘要压得较近右侧文字以蓝色保持与序号初始色、活动页签色的呼应。Row({ space: 12 })让左圆与中部内容隔开layoutWeight(1)让中部主动占满右侧“查看”因此靠近卡片右端。序号区域通过顶部内边距和居中方式让数字在视觉上接近垂直居中。不同字体、字号或设备字体缩放下视觉重心可能略有变化页面没有额外做精确的垂直对齐校正。初学阶段可以先理解当前写法的目的不要把截图上的效果当作所有尺寸下严格不变的保证。消息摘要没有设置最大行数、截断方式或无数据占位。当前五条中文文本都足够短在常规手机宽度上能落在一行。若传入很长的内容实际布局会怎样需要以设备和 ArkUI 的文本排版结果为准不能从这份代码宣称“长消息一定省略”或“卡片高度一定不变”。同理条目卡片没有分割线间距来自外层 Column 的space: 10而不是每个条目自身的margin。这个 Builder 也说明了局部复用的边界。它依赖父组件的selected传入的参数只有名字和下标正好服务当前消息区。联系人行的结构、内容和样式不一样所以没有强行复用MessageItem。复用不是把任何“一行”都塞进同一个组件当两段 UI 的数据含义、状态变化和布局关系不同保持各自清楚的代码通常更容易维护。分组列表名称是按字符串前缀推断出来的当点击第二个页签页面进入tab 1的分支。它创建标题“联系人分组”随后也对MEMBERS使用ForEach。每次遍历会先画一个小标题再画一个联系人行Text(item.startsWith(家人)?家人:item.startsWith(同事)?同事:好友)Text(item.split( · )[1])第一句根据字符串是否以“家人”或“同事”开头决定分组只要前两个条件都不成立就统一显示“好友”。第二句用分隔符·切开字符串取数组下标 1即中点后面的姓名。于是“家人 · 爸爸”会显示分组“家人”和姓名“爸爸”“同事 · 张三”会显示“同事”和“张三”。这是一份很适合解释字符串处理的教学数据但其正确性依赖数据格式完全一致。例如如果某条字符串没有·split后没有下标 1姓名区域就没有现有表达式所预期的结果如果前缀换成“朋友”分支也会把它归到“好友”。当前页面只定义了五条满足格式的固定内容所以运行中不会遇到这些情况。理解依赖条件比凭空补写异常处理更有价值页面没有加载外部数据也没有声明格式校验它展示的只是如何对已知字符串做最短路径的拆分。更重要的是当前的“分组”是逐项显示标签并不是把联系人先整理成嵌套分组。数组顺序为家人、家人、同事、同事、好友遍历时每一项都会先生成一次标题因此屏幕上会依次出现“家人、爸爸”“家人、妈妈”“同事、张三”“同事、李四”“好友、小美”。“家人”和“同事”标题各重复一次。这不是截图遗漏也不是 UI 自动合并的效果而是ForEach函数体每次都包含一个标题文本的直接结果。联系人行本身是一行横向内容左侧姓名占据剩余空间右侧是灰色的›外层宽度百分百、内边距 14、白底、圆角 14。它没有点击事件所以点联系人不会选中、展开或进入详情箭头在这个页面里只是视觉符号不是已经接通的导航按钮。若只看界面很容易把箭头理解为“可进入下一页”但实际页面没有提供这样的操作。若需求真的是传统通讯录分组数据更适合表达为“分组对象数组分组内再有成员数组”。外层循环先渲染一次组名内层循环渲染所有成员标题自然不会重复。这是未来改造方向不是当前页面已有的结构。也不应添加折叠、搜索、字母索引或联系人详情等描述因为页面没有相应状态、控件和事件。第三个页签数据量文案不等于 LazyForEach第三个页签是最需要谨慎理解的部分。页面显示浅蓝色区域顶部一行左侧文字是“虚拟数据池”右侧是“追加 1000”按钮。每点击一次页面总数增加一千组成“共 n 条数据仅构建当前可见的列表项。”再往下显示“第 1 条懒加载数据”至“第 4 条懒加载数据”四条固定文字。因此连续点击按钮确实会让总数从 10000 变成 11000、12000界面的文案会更新但数组没有增加任何元素ForEach 的迭代次数也始终为四。没有一万条对象没有数据源类没有滚动到末尾追加数据也没有条目回收逻辑。按钮验证的是数字状态变化与文本拼接不是数据追加功能。四行文字也不会因为按钮点击而变成一千零四行或一万零四行。页面文案“仅构建当前可见的列表项”与现有实现不相符。解释这一点并不是要求读者忽略第三页而是要把它当作一个尚未完成的概念展示它给出了“总量”和“按需”两个词但没有接上实现它们所需的组件和数据。拿它做性能结论会产生误导。例如当前外层虽然能滚动但并没有根据可见范围决定哪些大数据条目创建所以不能用它比较一万条数据时的内存占用、首屏耗时或滚动流畅度。真正需要处理大量同构条目时通常会选择List作为列表容器并让LazyForEach从可按索引访问的数据源取得项目再以ListItem描述单项。这些名词在这里仅用于区分概念当前页面没有它们的调用也没有把具体的长列表实现放进来。若以后要扩展应先决定数据是否真的有上万条、每项是否有稳定 ID、滚动时需要怎样获取更多数据再针对那个新需求单独设计和验证。第三页的布局也有可直接观察的部分。外层 Column 设置了 12 的间距、16 的内边距、浅蓝背景#EAF1FF和 18 的圆角。最上方 Row 中“虚拟数据池”使用layoutWeight(1)按钮便被推向右侧按钮高度是 38字号 13背景蓝色。说明文本颜色为灰蓝色。下面四个文本各自是白底、圆角 14、内边距 14占满宽度。这里没有ListItem没有滚动条配置也没有针对每项的点击处理。ForEach 在三处的相同点与不同点当前页面一共三处ForEach。第一处遍历五条消息每项生成一张消息卡片第二处遍历五位联系人每项生成分组标题和联系人行第三处遍历四条“懒加载数据”每项生成一个文本。三处都不是 LazyForEach也都按现有数据元素生成内容。它们的相同点是都能让“数据数量变化时写很多重复 UI”的问题变得简洁都需要在数据有可能变动时认真考虑 key都把单项的内容写在遍历函数中或交给 Builder。不同点则来自数据和交互。消息项的回调同时得到下标要用它显示序号和保存选中位置联系人项只需要字符串靠字符串解析得到两段文字第三页不关心下标也不改变它的四条数组。不必把 ForEach 当作“只能渲染简单列表”的组件。它只是按数据集合重复创建 UI 的一种方式。适不适合继续使用取决于数据量、容器、交互密度和性能需求。五条静态消息、五条静态联系人这样的规模用滚动容器、纵向布局和 ForEach 直接展示结构容易理解。若单项结构不断变复杂可以先把单项抽成 Builder 或组件若数量进入大规模且需要高效滚动则需要重新选择列表容器和数据供给方式。不要因为页面标题出现“懒加载”就跳过中间这些判断。这里还可以观察到 key 并不会出现在画面上。消息左侧显示的 1 到 5 来自index 1联系人右侧的箭头是常量文本第三页前面的闪电符号也是文本拼接。key 的目的与这些显示元素完全不同。把用户可见编号拿来充当数据唯一标识在排序、筛选或删除后往往容易出现错位当前数组不会变动示例才没有暴露这个问题。从事件到画面逐项追踪三种状态更新用三条实际操作可以把这个页面的状态流走一遍。第一启动后点击“分组列表”。第二项页签被选中标题和副标题不变页签颜色改变消息区域被联系人区域替换。消息选中状态和第三页的数量状态仍保持初始值因为它们不参与当前分支的显示。第二切回“基础列表”点击第 3 条消息。第 3 张消息卡片中的圆形背景变为紫色右侧文字变成“已读”其他四条继续保持蓝色和“查看”。随后点击第 1 条刚才的第 3 条又回到未选中样式。这正是单个数字状态只能指向一项的体现。第三打开“懒加载”点击一次“追加 1000”。页面总数从 10000 变为 11000再点击一次变为 12000。四条示例文字不会变化因为数量显示和这四条文字是两组独立内容。看到“总数已变化而内容数量未变化”时不应误判为渲染故障。这三种操作都没有跨组件的复杂通信。状态属于当前页面Builder 从页面作用域读取状态事件也直接更新对应字段。这是小页面容易理解的形态页签、消息标记和第三页数字各自有明确来源。当页面发展为多个独立组件、状态来源又增加时再考虑状态提升、参数传递或其他组织方式目前不需要为了“看起来完整”提前增加没有用途的层次。样式数值不是装饰它们构成了信息层级页面的颜色和间距虽少却分担了明确职责。全页的#F5F7FB让白色卡片从背景中浮出来主蓝#2563EB同时用于活动页签、序号圆形、按钮和部分文字告诉用户哪些元素与当前操作相关选中的消息改用紫色#7C3AED让它区别于普通的蓝色序号。副标题和辅助信息使用#667085联系人箭头使用更浅的#98A2B3避免与标题和动作文字争夺注意力。字号也按内容重要程度排列。页面标题为 24 且粗体是视觉起点分区标题为 18 且粗体消息标题和联系人姓名为 16 或附近尺寸摘要、页签与按钮文字为 13 或 14。颜色直接用于各个页面元素没有主题切换或暗色模式适配。对于这个小页面这样能让读者一眼看到各层信息的区别。圆角数值也有层次消息卡片 16联系人行和第三页条目 14第三页容器 18页签 10序号标签 12序号圆形 19。并不需要从这些数值推导出严格的设计规范它们的作用是让容器在视觉上有差别。若调整其中一个值应该在设备上重新查看边缘、空间和点击区域。当前页面没有针对不同屏幕尺寸的特殊分支验证应覆盖实际要支持的设备。还要注意外观属性的先后并不改变页面状态。字体颜色、背景色和圆角只负责视觉呈现真正触发切换的是点击动作对状态的更新。理解页面时先把“哪个状态决定什么”列清再看各状态对应的样式通常会比只看颜色更容易掌握交互关系。这个示例没有实现什么以及为什么必须写清楚从实际交互可以确定当前页面没有List、ListItem、LazyForEach、动态数据源、接口请求、分页参数、下拉刷新、上拉加载、删除条目、筛选、搜索、联系人跳转、消息详情或持久化已读状态。点击“追加 1000”也不会真的生成一千项。每一种能力都需要额外的数据、状态或事件当前页面没有提供这些入口。这并不让页面失去学习价值。相反它把一个最小的可运行界面放在眼前固定数组如何遍历状态如何控制条件分支点击如何改变样式字符串如何做一次简单解析滚动容器如何包住整页。能先把这些小点看明白后续接入真实数据时才知道应该替换哪一层而不是把所有概念混成“列表会自己变快”。接口、缓存、埋点、权限和复杂架构都不属于当前五条静态数据的交互范围。真正的扩展应由新的需求启动。例如需要消息详情就要定义点击后进入哪里和传递什么数据需要累积已读就要把单个选中位置改成可表达多项状态的数据需要大数据滚动才设计 List、LazyForEach 与稳定 ID。每一步都应当有新的实现和运行验证。页面图片只用于帮助读者辨认初始布局和操作后的界面位置。初始图对应默认的消息列表操作图也只作为页面视觉参考不把图片中的静态内容解释成额外功能。文章中的结论仍以实际点击后的文字、颜色和数量变化为准。在设备上逐项验证下面的检查不需要修改页面内容目的是把每一条关于当前交互的描述落到可观察结果上。运行应用。确认启动后进入标题为“列表与懒加载”的页面默认高亮的是“基础列表”。查看基础列表。确认有五张消息卡片左侧数字从 1 到 5右侧初始都为“查看”消息文字按固定顺序出现。点击任意一张消息卡片例如第 3 条。确认该条圆形编号变紫右侧显示“已读”。再点另一条确认新条目成为已读旧条目恢复查看。这个现象说明页面只保留最近一次选中的位置。点击“分组列表”。确认第二个页签变为蓝底白字内容标题改为“联系人分组”。逐项向下查看会发现“家人”和“同事”的标签跟随各自联系人重复出现。这正是当前遍历函数每次都创建分组标题的结果不应期待自动合并。点击联系人行。确认当前页面没有选中颜色、详情页或弹窗出现。右侧箭头只是文本符号这一步用来排除“箭头等于已实现导航”的误读。点击“懒加载”。确认有“虚拟数据池”、一个“追加 1000”按钮、一句总数说明和四条白色示例项。点击按钮两次确认数字以 1000 为步长增加两次而四条示例项的数量和文字不变。这说明页面没有真的追加一千条数据。旋转或换用较小的设备时观察页面能否纵向滚动、标题和卡片是否仍可见。这里记录实际设备结果即可不要根据某个截图推断所有屏幕都有相同排版。回到三个页签重复观察消息、联系人和四条示例数据。若要判断是否存在真正的懒加载应以条目数量是否随总数增加、滚动时是否出现新内容为依据当前页面的四条示例项始终不变。读完这一页后应该带走什么这个页面的价值并不在于展示一个规模庞大的高性能列表而在于把三类非常基础的页面行为放到一张可操作的界面中。第一页说明固定消息如何变成重复卡片以及一个选中状态怎样同时驱动颜色和文案第二页说明同样的遍历也可以结合字符串判断和拆分来组织显示第三页提醒我们数据量的文字、按钮的计数变化和真正的按需构建是三件不同的事。如果你正在学习 ArkTS可以按“看默认状态—切换页签—点击条目—回看变化”的顺序体验它。先记住当前页签决定哪块内容出现选中状态决定哪条消息呈现已读第三页数量决定总数文字再看两个复用区域如何保持共同外观。这样体验后不仅能复述页面样子也能解释每个变化为什么发生。如果之后确实要把它改造成真实的长列表需要重新准备结构化数据、选择合适的列表容器、定义稳定标识、验证滚动过程和数据追加。当前页面没有完成那一步所以这里不把设想描述成现有功能。准确地理解一个小示例是走向复杂页面的可靠起点。一次针对这张页面的观察练习面对内容不多的页面可以先只看界面预测启动时会出现哪一页、哪条消息会被标成已读、第三页数字是多少再运行应用逐项比对预测。这个过程能检验自己理解的是状态关系还是只记住了组件名称。接着从每个可点击元素倒推行为。顶部三个文字采用相同的页签样式因此点击任意一个都只切换当前内容消息区看起来有五个“查看”但它们的交互规则一致点击整行后只会标记最近一条不会跳转。这种按页面区域观察的方式能避免在重复卡片中迷路。第三页则适合练习区分总数文字和具体 UI 项。点击“追加 1000”后总数说明会增加一千但下方四条示例项不变。这样一步一步观察按钮的真实影响范围就很明确它影响一句文本不影响示例项个数。若只从“追加 1000”四个字推断功能很容易把界面文案误当成实现。还有一个实用的观察是把默认画面和点击结果逐一对比。启动时第一页被选中消息没有已读标记第三页总数是 10000点第 5 条消息后只有它变紫并显示已读点“追加 1000”后总数变成 11000。这样的对照比笼统地说“界面会更新”更具体。这个练习同样提醒我们不要超出页面证据。页面没有网络失败提示、长文案专门排版、深色模式或性能指标。可以如实记录当前设备上看到的内容却不应把局部观察扩写成产品承诺。已实现的地方说清细节没有实现的地方说明边界下一步若要扩展则需要新的设计和验证。最后可以试着用一句话概括每个页签。基础列表是“由五条固定消息生成、可选中一条的消息卡片”分组列表是“按文字前缀显示类别、类别标题随联系人重复的联系人行”第三页是“总数文字可以增加、但始终显示四条固定示例项的演示区”。当这三句概括都能被页面操作直接验证时就已经掌握了这张页面最重要的内容。之后再学习真正的 List 或 LazyForEach也更容易看清哪些是新加入的容器、数据源和性能行为。三个页签之间的连续体验三个页签虽然展示不同内容但共享相同的顶部结构和页面背景。用户从基础列表切到分组列表时标题区域不会消失只有下方内容区域改变再切到懒加载时顶部仍保持原来的位置第三个页签通过蓝底白字提示当前所在区域。这样安排让用户不会因为内容更换而失去方向也不会误以为每次点击页签都重新打开了一个完全独立的页面。页签切换还可以用来观察状态是否被意外重置。先在基础列表选中第 2 条再查看分组列表联系人行不会出现消息的紫色标记回到基础列表后第 2 条仍然是已读。再进入懒加载并点击一次追加按钮回到基础列表时消息的选中结果不会被清除第三页的总数也不会倒退。这些结果说明不同状态各自服务自己的区域页签只是改变当前可见内容。如果用户重复点击当前已经选中的页签画面不会增加新的卡片也不会把消息状态清空。重复点击“分组列表”不会重新生成一套不同联系人重复点击“懒加载”页签也不会自动增加总数只有点击页签内部的“追加 1000”按钮数字才会变化。把导航动作和内容动作分开是这张页面保持可预测性的原因之一。第三页的总数文字即使增加到很大的数字页面下方仍只有四条固定项因此它适合观察数字反馈不适合用来判断大量数据滚动性能。用户可以连续点击按钮看到 10000、11000、12000 依次变化同时看到四条白色条目的位置和文字不变。这个对照很直白上方数字表达一个演示中的总量下方条目表达当前真正放在屏幕上的内容两者不能互相替代。