文章目录前言代码讲解页面入口怎么安排数据模型先稳住状态变量控制页面反馈布局代码不要从样式开始读Builder 和方法承担复用使用方式完整代码关键代码解析interface 不是摆设State 是交互的开关列表和卡片要靠数据驱动事件回调要短一点样式参数别急着抽常量总结前言侧边栏页面要先把导航区和内容区分清楚否则状态很容易散落在各个组件里。我建议把这篇当成一个可以直接改造的 ArkUI 页面模板来看。先跑起来确认页面展示和交互都正常再把里面的模拟数据替换成接口数据最后再调整颜色、间距和业务字段。这样改起来比较稳不容易一边改样式一边把状态逻辑弄乱。这篇文章会按「页面意图、数据结构、状态流转、布局组织、交互细节」这条线来读代码。你不用从第一行样式硬看到最后先抓住主线后面的细节会轻松很多。代码讲解页面入口怎么安排代码里的入口组件是ArticleSidebarLayoutPage。如果你把它当成单独页面预览保留Entry就可以如果要塞进现有工程的路由体系通常会去掉Entry再由外层页面或路由模块统一管理。这个习惯很重要。一个项目里入口页面太多预览时容易混后期拆组件也会麻烦。我的做法是案例阶段保留入口接业务时只保留真正需要被路由访问的页面。数据模型先稳住本案例涉及的数据模型主要有MenuItem_3udw、ContentArticle。这些interface的作用不是为了“看起来规范”而是给 UI 层划边界。比如列表项需要标题、描述、颜色、选中态就应该在模型里说清楚。后续从接口拿数据时可以在请求层做字段映射别让后端字段名直接污染页面代码。如果你准备接真实业务建议把模拟数组替换成接口返回后的 ViewModel。页面只关心自己要渲染什么不关心接口原始字段长什么样。状态变量控制页面反馈本案例里的关键状态包括isSideBarShown、activeMenuId。State的职责是让 UI 对用户操作有反馈。比如选中某个卡片、切换分类、展开内容、修改输入值、控制加载中状态这些都应该由状态驱动。状态一变相关 UI 自动刷新这也是 ArkUI 声明式开发最核心的体验。这里有个容易踩的坑不要把所有数据都塞进State。静态配置用普通数组就够了只有用户会改、接口会更新、页面需要重新渲染的数据才适合放进状态里。布局代码不要从样式开始读这个页面里比较关键的组件有Row横向排列、左右分栏、按钮组或卡片行都依赖它来控制水平方向的节奏。Column纵向组织标题、内容、操作区适合搭页面主骨架。RelativeContainer用锚点关系描述组件之间的位置比手写大量 margin 更稳定。SideBarContainer把侧边导航和内容区分开适合文章、设置、后台类页面。Divider负责信息分组不只是画一条线而是帮用户理解层级。List适合长列表和分组列表重点是数据过滤、滚动和状态同步。读布局时我更建议先找大容器再看内部如何拆块。比如一个页面通常会先用Column纵向放标题区、内容区、操作区内容区里再用Row、Grid、List或其他容器细分。这样看代码层级会比逐行看.padding()、.fontSize()清楚得多。如果页面显示错位优先检查容器关系而不是马上改像素。很多问题不是某个.margin()不对而是外层容器的宽高、滚动方向、权重分配或对齐方式没想清楚。Builder 和方法承担复用这篇没有额外拆出 Builder页面结构主要集中在build()中。辅助方法不多逻辑主要写在事件回调和渲染表达式里。Builder更适合复用 UI 片段比如卡片、列表行、头部区域、按钮组。普通方法更适合放计算逻辑比如筛选列表、统计数量、切换状态、生成颜色。两者分清楚后页面会干净很多。我不建议把所有东西都塞进build()。刚开始代码少还行需求一多build()会变成几百行后面改一个按钮都要找半天。使用方式把下面的完整代码放到 ArkTS 页面文件里即可运行。文章中的组件名已经是语义化命名不包含编号式案例名称接路由时直接使用ArticleSidebarLayoutPage就行。如果你要改成业务页面优先改三处数据模型、状态变量、事件方法。样式可以后调先保证数据流和交互是通的。完整代码// ArticleSidebarLayoutPage: 侧边栏布局 - SideBarContainer 侧滑面板 // 知识点: SideBarContainer、showSideBar、sideBarWidth、sideBar/content 区域划分 interface MenuItem_3udw { menuId: number menuName: string menuEmoji: string menuBadge: number } interface ContentArticle { articleId: number articleTitle: string articleSummary: string articleEmoji: string articleBg: string articleTime: string articleViews: string } Entry Component struct ArticleSidebarLayoutPage { State isSideBarShown: boolean true State activeMenuId: number 1 private menuList: MenuItem_3udw[] [ { menuId: 1, menuName: 全部文章, menuEmoji: , menuBadge: 0 }, { menuId: 2, menuName: 技术博客, menuEmoji: , menuBadge: 5 }, { menuId: 3, menuName: 设计分享, menuEmoji: , menuBadge: 2 }, { menuId: 4, menuName: 产品思考, menuEmoji: , menuBadge: 0 }, { menuId: 5, menuName: 开源项目, menuEmoji: , menuBadge: 3 }, { menuId: 6, menuName: 生活随笔, menuEmoji: ✍️, menuBadge: 0 }, { menuId: 7, menuName: 我的收藏, menuEmoji: ⭐, menuBadge: 12 }, ] private articleList: ContentArticle[] [ { articleId: 1, articleTitle: HarmonyOS ArkUI 布局系统深度解析, articleSummary: 从 Flex、Column、Row 到 RelativeContainer全面掌握 HarmonyOS 的布局能力…, articleEmoji: ️, articleBg: #F0F4FF, articleTime: 2024-01-15, articleViews: 1.2万 }, { articleId: 2, articleTitle: 打造高性能的列表滚动体验, articleSummary: LazyForEach 懒加载、缓存预加载、列表复用机制让你的 List 丝滑如飞…, articleEmoji: ⚡, articleBg: #F0FFF4, articleTime: 2024-01-10, articleViews: 8千 }, { articleId: 3, articleTitle: 状态管理最佳实践从 State 到 AppStorage, articleSummary: 五种状态装饰器的使用场景与最佳实践避免常见的状态管理陷阱…, articleEmoji: , articleBg: #FFF8E7, articleTime: 2024-01-05, articleViews: 1.5万 }, { articleId: 4, articleTitle: 自定义组件与复用的艺术, articleSummary: Component、Builder、BuilderParam 组合使用构建可复用的 UI 组件库…, articleEmoji: , articleBg: #FDF0FF, articleTime: 2023-12-28, articleViews: 6千 }, ] build() { SideBarContainer(SideBarContainerType.Overlay) { // 侧边栏内容 Column({ space: 0 }) { // 侧边栏顶部用户信息 Column({ space: 8 }) { Text(‍) .fontSize(44) .width(64) .height(64) .textAlign(TextAlign.Center) .backgroundColor(#EDF4FF) .borderRadius(32) Text(技术博主) .fontSize(16) .fontWeight(FontWeight.Bold) .fontColor(#1A1A1A) Text(专注 HarmonyOS 开发) .fontSize(12) .fontColor(#888888) } .width(100%) .padding({ top: 24, bottom: 20 }) .alignItems(HorizontalAlign.Center) .backgroundColor(#FAFBFF) Divider().strokeWidth(1).color(#F0F0F0) // 菜单列表 Scroll() { Column({ space: 2 }) { ForEach(this.menuList, (item: MenuItem_3udw) { Row({ space: 10 }) { Text(item.menuEmoji) .fontSize(18) .width(28) .textAlign(TextAlign.Center) Text(item.menuName) .fontSize(14) .fontColor(this.activeMenuId item.menuId ? #007DFF : #333333) .fontWeight(this.activeMenuId item.menuId ? FontWeight.Bold : FontWeight.Normal) .layoutWeight(1) if (item.menuBadge 0) { Text(item.menuBadge.toString()) .fontSize(11) .fontColor(#FFFFFF) .padding({ left: 6, right: 6, top: 2, bottom: 2 }) .backgroundColor(#EF4444) .borderRadius(10) .constraintSize({ minWidth: 20 }) .textAlign(TextAlign.Center) } } .width(100%) .height(48) .padding({ left: 16, right: 16 }) .backgroundColor(this.activeMenuId item.menuId ? #EDF4FF : transparent) .borderRadius({ topLeft: 0, topRight: 24, bottomLeft: 0, bottomRight: 24 }) .margin({ right: 8 }) .alignItems(VerticalAlign.Center) .onClick(() { this.activeMenuId item.menuId }) }, (item: MenuItem_3udw) item.menuId.toString()) } .padding({ top: 8, bottom: 8 }) } .scrollBar(BarState.Off) .layoutWeight(1) // 底部设置 Divider().strokeWidth(1).color(#F0F0F0) Row({ space: 8 }) { Text(⚙️) .fontSize(18) Text(设置) .fontSize(14) .fontColor(#666666) } .width(100%) .height(52) .padding({ left: 16 }) .alignItems(VerticalAlign.Center) } .width(100%) .height(100%) .backgroundColor(#FFFFFF) // 主内容区 Column({ space: 0 }) { // 顶部导航 Row({ space: 0 }) { Text(☰) .fontSize(22) .fontColor(#1A1A1A) .padding({ right: 12 }) .onClick(() { this.isSideBarShown !this.isSideBarShown }) Text(this.menuList.find(m m.menuId this.activeMenuId)?.menuName ?? 全部文章) .fontSize(18) .fontWeight(FontWeight.Bold) .fontColor(#1A1A1A) .layoutWeight(1) Text() .fontSize(20) .fontColor(#1A1A1A) } .width(100%) .height(56) .padding({ left: 16, right: 16 }) .backgroundColor(#FFFFFF) .border({ width: { bottom: 1 }, color: #F0F0F0 }) // 文章列表 Scroll() { Column({ space: 12 }) { ForEach(this.articleList, (article: ContentArticle) { Column({ space: 10 }) { Row({ space: 12 }) { Text(article.articleEmoji) .fontSize(32) .width(56) .height(56) .textAlign(TextAlign.Center) .backgroundColor(article.articleBg) .borderRadius(10) .flexShrink(0) Column({ space: 6 }) { Text(article.articleTitle) .fontSize(15) .fontWeight(FontWeight.Bold) .fontColor(#1A1A1A) .maxLines(2) .textOverflow({ overflow: TextOverflow.Ellipsis }) .lineHeight(22) Text(article.articleSummary) .fontSize(12) .fontColor(#888888) .maxLines(2) .textOverflow({ overflow: TextOverflow.Ellipsis }) .lineHeight(18) } .layoutWeight(1) .alignItems(HorizontalAlign.Start) } .width(100%) .alignItems(VerticalAlign.Top) Row({ space: 0 }) { Text(article.articleTime) .fontSize(12) .fontColor(#BBBBBB) .layoutWeight(1) Text( ${article.articleViews}) .fontSize(12) .fontColor(#BBBBBB) Text( 收藏) .fontSize(12) .fontColor(#007DFF) } .width(100%) .alignItems(VerticalAlign.Center) } .padding({ left: 16, right: 16, top: 14, bottom: 14 }) .backgroundColor(#FFFFFF) .borderRadius(12) }, (article: ContentArticle) article.articleId.toString()) // 提示文字 Text( 点击左上角 ☰ 按钮切换侧边栏显示) .fontSize(13) .fontColor(#AAAAAA) .textAlign(TextAlign.Center) .width(100%) .margin({ top: 8 }) } .padding(12) } .scrollBar(BarState.Off) .layoutWeight(1) .backgroundColor(#F5F6FA) } .width(100%) .height(100%) } .showSideBar(this.isSideBarShown) .sideBarWidth(220) .minSideBarWidth(180) .maxSideBarWidth(260) .onChange((isShow: boolean) { this.isSideBarShown isShow }) .width(100%) .height(100%) } }关键代码解析interface不是摆设很多新手写 ArkUI 页面时会直接在ForEach里使用一堆临时对象。页面小的时候没问题但字段一多就很难知道每个字段到底用于哪里。本案例把数据结构提前声明出来读代码时能很快判断每个 UI 区块依赖哪些字段。后续如果接接口也建议保留这层结构。接口可以变页面模型尽量稳定。这样页面不会因为后端多返回一个字段、少返回一个字段就跟着大改。State是交互的开关本案例的交互反馈都围绕状态展开。点击、切换、输入、刷新这类行为本质上都是修改某个状态值然后让 UI 重新计算显示结果。写这类代码时有一个简单判断如果某个值变化后页面应该立刻变那它大概率应该是状态如果它只是配置项、静态文案、固定颜色就不要放进状态。列表和卡片要靠数据驱动只要页面里出现重复结构就应该优先想到数据数组加ForEach。这样新增一项、删除一项、调整顺序都只动数据不用复制粘贴一段 UI。这个案例的完整代码里已经把主要内容抽成数组或方法。你可以试着多加一条数据看页面是否能自然渲染出来。如果能说明结构是健康的如果加一条就要改很多 UI说明组件拆分还不够。事件回调要短一点.onClick()、onChange()这类回调里可以直接改状态但不建议堆太多逻辑。简单切换可以写在回调里复杂逻辑最好拆成方法。这样做有两个好处一是读页面结构时不会被业务逻辑打断二是后面要加埋点、请求接口、异常处理时有明确的位置可以改。样式参数别急着抽常量这个案例里有不少颜色、间距、圆角、字号。学习阶段直接写在组件链上反而更容易看出效果。等你确定页面风格稳定后再把主题色、通用间距、卡片圆角提到统一常量里。过早抽象会让示例代码变绕。先让页面清楚再谈工程化这是我比较推荐的顺序。总结这个案例真正值得学的不只是某个 ArkUI 组件怎么写而是一个页面如何从数据走到状态再走到布局和交互。你可以按这个顺序改造先替换数据模型再确认状态更新是否正确接着调整布局容器最后打磨样式细节。只要这条主线不乱页面规模变大也不会失控。如果后续继续扩展我会优先把可复用的卡片、列表行、筛选栏或控制区拆成独立组件。这样主页面只保留数据和流程代码会更接近真实项目里的写法。