HarmonyOS7 ArkUI 实战：Flex Row 商品信息卡片不被长文案挤变形

商品卡片最怕商品名一长就把价格和按钮挤乱。这个案例重点看图片、文字、按钮三块怎么分空间。

这里我会多讲一点代码。很多教程只把完整代码贴出来，看着是完整了，但读者真正改项目时还是不知道该动哪里。下面这几段会把数据、状态、布局和事件拆开说。

效果预览

横向卡片先稳住三块区域

这个案例对应的是「横向商品卡片」。如果只是运行一下效果，当然很快；但真要把它改进自己的项目里，最好先把页面分成“数据层、状态层、布局层、交互层”四块。

我比较推荐这种读法：先看interface定义，再看@State，最后看build()里的Column、Row、Flex怎么嵌套。这样不容易被一长串样式绕晕。

数据结构先看这里

这份代码里的核心数据模型是GoodsInfo。它决定了页面每一项需要哪些字段，比如标题、描述、颜色、状态、价格、数量、角标等。很多 ArkUI 页面写得乱，根源不是布局，而是数据字段没想清楚。

如果你要接真实接口，优先改这一层。接口字段名和页面字段名不一致也没关系，可以在请求完成后做一次映射，别把接口返回结构直接塞进 UI 里。那样短期省事，后面改样式会很难受。

状态变量负责让页面动起来

这个案例里最关键的状态是selectedId。它不是摆设，页面里的选中、展开、切换、数量变化、输入内容，基本都靠它驱动。

写 HarmonyOS7 ArkUI 页面时，我会刻意把“会变的东西”和“不会变的静态数据”分开。像goodsList这种列表数据负责提供内容，selectedId负责描述当前用户操作后的界面状态。这样读代码时很清楚：数据从哪里来，界面为什么变。

布局代码怎么读

布局部分不要从第一行样式读到最后一行，这样很累。先找最外层容器，看页面是纵向结构还是横向结构；再看每个区域内部是Row、Column还是Flex。

这个案例的布局重点是：中间信息区使用layoutWeight(1)，这是避免右侧按钮被长标题挤走的关键。

如果你调页面时发现内容挤压、对齐不准、间距失控，优先检查这几个地方：固定宽高是不是太多，layoutWeight或Blank是否用对，列表项里长文本有没有设置省略，Flex 换行条件是否满足。

交互逻辑别藏太深

这个页面的交互主线是：加购按钮点击后更新选中商品，卡片边框和按钮颜色一起变化。

小案例里直接在.onClick()里改状态没问题，读起来也直观。但如果后面业务变复杂，比如要请求接口、弹确认框、写缓存，就别把逻辑全塞在事件回调里。可以拆成一个私有方法，让 UI 代码只表达“点了什么”，具体怎么处理交给方法。

使用时我会怎么改

如果你只是学习布局，直接运行下面代码就行。如果你准备放进项目里，我建议按这个顺序改：先替换数据数组，再调整颜色和字体，最后再改交互逻辑。

还有一个小经验：不要一开始就把所有东西拆成组件。先让页面跑通，等你发现某个卡片、按钮组、列表项重复出现两三次，再抽成@Builder或单独组件。这样代码会更贴近真实需求。

完整代码

/** * Flex 水平排列：商品信息卡片 * 知识点：Flex direction:Row，子项水平排列，图文混排布局 */ interface GoodsInfo { id: number name: string price: string originalPrice: string tag: string tagColor: string bgColor: string } @Entry @Component struct ProductInfoCardListPage { @State selectedId: number = -1 private goodsList: GoodsInfo[] = [ { id: 1, name: '无线蓝牙耳机', price: '¥299', originalPrice: '¥599', tag: '限时折扣', tagColor: '#FF4D4D', bgColor: '#FFF5F5' }, { id: 2, name: '智能运动手表', price: '¥899', originalPrice: '¥1299', tag: '爆款推荐', tagColor: '#FF8C00', bgColor: '#FFF8F0' }, { id: 3, name: '便携充电宝', price: '¥129', originalPrice: '¥199', tag: '新品上架', tagColor: '#07C160', bgColor: '#F0FFF4' }, { id: 4, name: '机械键盘', price: '¥459', originalPrice: '¥699', tag: '热销榜一', tagColor: '#007DFF', bgColor: '#F0F7FF' }, ] build() { Column({ space: 0 }) { // 顶部标题栏 Row() { Text('商品列表') .fontSize(20) .fontWeight(FontWeight.Bold) .fontColor('#1A1A1A') Blank() Text('查看全部 >') .fontSize(14) .fontColor('#007DFF') } .width('100%') .padding({ left: 16, right: 16, top: 20, bottom: 12 }) // 商品卡片列表 Column({ space: 12 }) { ForEach(this.goodsList, (item: GoodsInfo) => { // 每张卡片使用 Flex Row 排列 Flex({ direction: FlexDirection.Row, alignItems: ItemAlign.Center }) { // 左侧商品图占位 Column() { Text(item.name.substring(0, 1)) .fontSize(28) .fontColor('#FFFFFF') .fontWeight(FontWeight.Bold) } .width(80) .height(80) .backgroundColor(item.tagColor) .borderRadius(10) .justifyContent(FlexAlign.Center) .alignItems(HorizontalAlign.Center) // 中间商品信息 Column({ space: 6 }) { // 商品名称 Text(item.name) .fontSize(16) .fontWeight(FontWeight.Medium) .fontColor('#1A1A1A') .maxLines(1) .textOverflow({ overflow: TextOverflow.Ellipsis }) // 标签 Text(item.tag) .fontSize(11) .fontColor(item.tagColor) .backgroundColor(item.bgColor) .padding({ left: 6, right: 6, top: 2, bottom: 2 }) .borderRadius(4) // 价格区域 Row({ space: 8 }) { Text(item.price) .fontSize(18) .fontWeight(FontWeight.Bold) .fontColor('#FF4D4D') Text(item.originalPrice) .fontSize(13) .fontColor('#BBBBBB') .decoration({ type: TextDecorationType.LineThrough }) } } .alignItems(HorizontalAlign.Start) .layoutWeight(1) .margin({ left: 14 }) // 右侧加购按钮 Button('+') .width(36) .height(36) .fontSize(22) .fontColor('#FFFFFF') .backgroundColor(this.selectedId === item.id ? '#FF4D4D' : '#007DFF') .borderRadius(18) .onClick(() => { this.selectedId = item.id }) } .width('100%') .padding(14) .backgroundColor('#FFFFFF') .borderRadius(14) .shadow({ radius: 8, color: '#1A000000', offsetX: 0, offsetY: 2 }) .border({ width: this.selectedId === item.id ? 2 : 0, color: '#007DFF' }) }) } .padding({ left: 16, right: 16 }) } .width('100%') .height('100%') .backgroundColor('#F5F6FA') } }

代码里的几个细节

看完完整代码后，可以回头重点检查三处。

第一处是数据声明。GoodsInfo这类结构把页面需要的字段提前摆出来，后面ForEach渲染时就不会到处临时拼数据。

第二处是状态更新。selectedId变化后，相关 UI 会自动刷新，这也是声明式 UI 写起来舒服的地方。你不用手动找某个控件改样式，只要把状态描述清楚。

第三处是容器嵌套。这个案例不是为了炫技才套Row、Column、Flex，而是每一层都在解决具体排版问题。读代码时多问一句：这一层容器负责什么？如果答不上来，它可能就该被简化。

常见改造坑

最容易踩的坑，是把示例里的颜色、文案、尺寸都保留，然后只替换数据。这样页面能跑，但很难和自己的项目风格统一。

另一个坑是过度依赖固定宽高。固定宽高在演示里很方便，在真实设备上就未必稳。文本变长、屏幕变窄、系统字体变大，都会把问题暴露出来。

我一般会保留固定尺寸给图标、头像、按钮这类稳定元素；文本区域、列表区域、内容卡片尽量交给弹性布局处理。

写在最后

这个案例的价值不只是“有一份完整代码”。更重要的是你能从里面看到 ArkUI 页面的一条基本思路：数据先定义清楚，状态单独管理，布局按区域拆，交互只改必要状态。

按这个思路去写，页面复杂一点也不会马上失控。