企业官网建设流程全解析

前言

上一章 讲了首页待办行WorkItem如何组织标题、说明和状态标签。本篇继续看它外面的一层：为什么首页主体要放在Scroll里。

工业现场首页往往不是固定不变的。今天可能只有三条待办，明天可能增加异常复核、模板确认、夜班交接、待报工批次；同一个页面还要面对不同手机高度、系统字体缩放和底部导航占用空间。如果首页根容器完全固定，内容一多就可能被遮挡或挤压。

注塑工程师助手在 M1 阶段就把首页主体放进Scroll。这不是因为当前内容已经很多，而是提前保证后续扩展时，现场待办可以自然向下滚动，底部导航仍然保持稳定。

一、项目结构与文件概览

本篇主要看entry/src/main/ets/features/home/HomeDashboard.ets。相关页面入口在entry/src/main/ets/pages/Index.ets，底部导航在entry/src/main/ets/components/BottomNavigation.ets。

HomeDashboard负责首页正文，BottomNavigation负责固定底部入口。入口页把两者放在同一个外层Column中：正文区域使用.layoutWeight(1)占据剩余高度，底部导航固定在下方。理解这个布局后，再看Scroll的作用会更清楚。

二、首页外层结构

首页组件的外层代码如下：

@Componentexportstruct HomeDashboard{summary:DashboardSummary=newDashboardSummary(0,0,0,0);build(){Scroll(){Column({space:18}){// 标题区、指标区和现场待办区}.width('100%').padding({left:16,right:16,top:18,bottom:24})}.width('100%').height('100%').align(Alignment.TopStart).scrollBar(BarState.Off).backgroundColor(ThemeTokens.pageBackground)}}

外层是Scroll，里面是一个纵向Column。Column({ space: 18 })负责把标题区、四张指标卡和现场待办区按顺序排下去；Scroll负责在内容高度超过可见区域时提供滚动能力。

这里的关键点是：Scroll不是替代Column，而是包住Column。Column仍然负责内容布局，Scroll负责可视区域和滚动行为。

三、为什么当前内容不多也要用 Scroll

当前 M1 首页只有四张指标卡和三条待办，看起来不使用Scroll也能显示。但技术教程不能只看当前截图，还要看后续功能会怎样增长。

现场待办区很可能继续增加：调机复核、异常关闭、模板确认、批次报工、夜班交接都可能成为首页提醒。如果根容器没有滚动能力，新增内容只能压缩已有组件，或者被底部导航挡住。

使用Scroll后，首页可以保持顶部指标卡稳定，下面的待办列表随着内容增加自然滚动。用户仍然能扫到首屏重点，也能向下查看后续事项。

四、Scroll 与底部导航的关系

在入口页中，首页正文被这样渲染：

HomeDashboard({summary:demoBusinessRepository.dashboardSummary()}).layoutWeight(1)BottomNavigation({selectedTab:$selectedTab,onSelect:(tabId:string)=>{this.selectedTab=this.navigationStore.select(tabId);this.closeDetail();}})

HomeDashboard占据底部导航之外的剩余空间，底部导航不参与首页正文滚动。这样用户滚动首页时，底部入口仍然在屏幕下方，主导航不会跟着内容一起滑走。

如果把底部导航也放进同一个Scroll，用户向下滑动时导航可能离开可视区域；如果首页正文没有.layoutWeight(1)，底部导航又可能被内容挤出屏幕。当前结构把滚动正文和固定导航分开，是更适合工具型 App 的方式。

五、scrollBar(BarState.Off) 的取舍

首页设置了：

.scrollBar(BarState.Off)

这表示隐藏滚动条视觉，不表示禁用滚动。工业现场首页通常强调扫读，滚动条本身不是核心信息；隐藏它可以让界面更干净。但如果页面内容超过一屏，用户仍然可以滑动。

这里要注意，不同产品对滚动条的取舍可能不同。如果是长列表、记录表或需要明确滚动位置的页面，保留滚动条可能更合适。首页当前内容属于看板摘要，隐藏滚动条是合理选择。

六、顶部对齐为什么重要

HomeDashboard的Scroll设置了：

.align(Alignment.TopStart)

顶部对齐能保证内容从屏幕上方开始阅读。对于首页看板来说，用户第一眼应该看到标题和指标，而不是内容被居中放在屏幕中间。前面 M1 调整过页面顶部对齐，也是为了让占位页和真实首页都符合工具型页面的阅读习惯。

如果短内容被垂直居中，页面看起来像空状态提示，而不是工作台。工业工具的首页应该默认从顶部开始承载信息。

七、和 WorkItem 的关系

WorkItem已经通过maxLines和省略号保护了单条待办的高度，但这只解决“单条不撑爆”的问题。Scroll解决的是“多条内容放得下”的问题。两个层级不能互相替代。

可以这样理解：WorkItem保护行内结构，Scroll保护页面容器。行内结构稳定，页面容器可滚动，首页才能既整齐又可扩展。

后续如果待办数据改为数组并使用ForEach渲染，外层Scroll仍然成立。只要待办数量增加，用户就可以继续向下浏览，不需要重写首页外壳。

八、常见错误

第一个错误是把所有内容固定在一个不可滚动的Column里。短屏设备或字体放大后，底部内容很容易被遮挡。

第二个错误是让整个页面一起滚动，包括底部导航。这样用户滑到底部时可能失去主入口，不利于频繁切换模块。

第三个错误是为了避免滚动，强行压缩字体和间距。工业现场信息需要清楚可读，过度压缩反而降低效率。

第四个错误是把滚动当成兜底，不控制单条内容高度。即使页面能滚动，某条特别长的待办也不应该在首页占据过多空间。

九、验证口径

验证首页Scroll时，可以看三件事。第一，默认首页能从顶部显示标题、指标卡和现场待办。第二，底部导航没有遮挡首页正文。第三，当待办内容增加或设备高度变小时，正文区域应该能上下滚动，而底部导航保持在外层页面底部。

M1 测试报告已经记录：首页首屏中标题、4 个指标、3 条待办和底部导航可见，首页内容没有横向溢出，指标卡没有相互覆盖，底部导航没有遮挡页面正文。本篇基于这份结果解释布局选择，不额外声明更多设备形态已经验证。

十、如果不用 Scroll，页面会怎样坏掉

不用Scroll的页面在短内容时不一定马上出问题，所以这个坑常常被忽略。真正的问题会在内容增加、屏幕变矮或系统字体变大时出现。首页指标卡和待办区都属于纵向内容，如果外层只是固定高度Column，底部待办可能被底部导航遮住，用户看不到最后一条提醒。

另一种坏法是开发者为了让内容塞进一屏，开始压缩字号、行距和卡片高度。这样看似解决了遮挡，实际牺牲了现场扫读效率。工业页面不能为了避免滚动而把关键信息压到看不清。滚动是移动端很自然的能力，应该在合适的容器层使用它。

还有一种坏法是让指标卡、待办卡、底部导航都参与同一个滚动区域。用户向下查看待办后，底部导航可能离开固定位置，想切换模块时还要再滑回来。对工具型 App 来说，这会增加不必要操作。

十一、Scroll 里的内容仍然要有尺寸约束

很多人以为加了Scroll，内部内容就可以无限增长。其实这只是把“放不下”变成“可滚动”，并没有解决组件自身的阅读问题。WorkItem仍然需要maxLines，指标卡仍然需要固定高度，外层Column仍然需要统一间距。

可以把首页分成两层保护。第一层是组件内部保护：标题最多一行，说明最多两行，卡片高度固定。第二层是页面容器保护：当多个组件加起来超过可视区域时，由Scroll承担滚动。两层缺一不可。

这种分层很适合后续业务页面。机台列表需要列表项高度和列表容器共同保护；异常详情需要字段组高度和页面滚动共同保护；报表页需要图表区域尺寸和筛选结果滚动共同保护。B-005 讲首页，其实是在建立工业 UI 的通用布局习惯。

十二、什么时候不该使用 Scroll

并不是所有区域都应该套Scroll。底部导航不应该滚动，因为它是主入口；短小的状态标签不需要滚动，因为它们应该被压缩成一两个词；弹窗里的关键确认操作也不应该因为内容过长而把按钮挤到用户找不到的位置。

判断一个区域是否适合滚动，可以看它是不是“内容主体”。首页正文是内容主体，适合滚动；底部导航是页面框架，不适合滚动。待办列表如果独立成为一个长列表，也可以滚动；单条待办本身不应该滚动，而应该省略并进入详情页查看完整内容。

这个边界写清楚后，读者就不会把Scroll当成万能容器。它解决的是内容区可视范围问题，不解决信息架构和组件尺寸问题。

九、Scroll 承载待办列表的真实原因

很多初学者会把Scroll理解成“内容太多时才加的容器”。在这个首页里，即使当前只有三条现场待办，也值得使用Scroll，因为页面的可用高度并不稳定。不同设备高度、系统字体缩放、底部导航高度、未来新增指标都会改变内容区剩余空间。只要其中一个因素变化，原本刚好能显示的列表就可能被挤压。

Scroll的价值在于给页面留出增长空间。首页上半部分是标题和指标卡，下半部分是现场待办，底部还有固定导航。正文区域如果不可滚动，新增一条待办可能直接被底部导航遮住；正文可滚动后，布局仍然能保持完整，用户也能通过滑动查看剩余内容。对于工业现场应用来说，这比追求首屏塞满所有信息更可靠。

本项目还关闭了滚动条显示。关闭滚动条不是为了隐藏内容，而是为了减少视觉噪声。现场看板的主要阅读对象是数字、标题和状态标签，滚动条在这种短列表场景中不是必要信息。需要注意的是，scrollBar(BarState.Off)不会取消滚动能力，只是改变视觉表现。

十、Scroll 与底部导航的关系

底部导航固定在Index.ets的最下方，HomeDashboard使用.layoutWeight(1)占据剩余空间。这个组合让页面形成明确的两层结构：上方是可滚动内容区，下方是固定操作入口。用户滑动首页时，导航仍然可见；用户切换页签时，正文区域被替换，底部导航仍然保留。

如果把Scroll放错层级，就容易出现两类问题。第一类是底部导航也被卷入滚动区，用户滑到底部前看不到导航入口。第二类是正文区域没有拿到完整高度，列表末尾被固定导航盖住。当前写法把滚动限制在HomeDashboard内部，再由外层layoutWeight(1)分配空间，边界比较清楚。

排查这类问题时，不要只看某一行代码。先看页面根节点是不是Column，再看正文组件是否使用layoutWeight(1)，最后看滚动容器是否只包住正文内容。这个顺序能帮助读者把 ArkUI 的父子布局关系串起来。

十一、待办项增加后的验证方法

验证Scroll是否起作用，可以先把待办项数量从三条临时扩展到五条或六条，观察页面是否仍能从标题滚到最后一条。这个验证不需要额外图片，运行时只要确认三件事：指标区没有被压扁，最后一条待办可以通过滑动看到，底部导航始终停留在页面底部。

如果增加数据后页面出现横向溢出，优先检查WorkItem内的文本省略规则，而不是怀疑Scroll。如果出现纵向内容被截断，优先检查滚动容器高度和父级.layoutWeight(1)。如果底部导航跟着内容一起滚动，说明滚动容器包裹范围过大，需要回到Index.ets调整层级。

这个验证方式也适合后续真实接口接入。接口返回的数据量不可控，首页必须对“比演示数据更多”的情况有预案。Scroll、省略规则和固定导航一起构成了这个预案。

十四、小结

Scroll在首页里承担的是页面容器职责。Column负责组织标题、指标和待办，Scroll负责在内容变长时提供滚动能力，layoutWeight(1)让正文区域和底部导航互不挤压。

对工业 App 首页来说，提前使用Scroll是一种面向扩展的设计：当前三条待办能整齐显示，后续更多现场事项也能自然承载。