熟悉我们购物比价应用的朋友，如果在平板（MatePad 那种 10 寸+ 竖屏）上跑过商城首页或商品列表页，可能遇到过一个很怪的现象：手机上好好的"商品列表 + 底部结算栏"布局，到了平板竖屏，结算按钮突然飞上来了，甚至直接盖住下半截商品列表，点"去结算"点到的却是列表里某个商品卡片。
QA 第一次提这个 Bug 的时候，我们以为是某个平板专属的样式分支写岔了，查了一圈才发现——根子不在平板，而在"手机时代养成的两个布局坏习惯：Stack 层叠 + position 绝对定位"，在屏幕变宽/比例变化时彻底暴露了。
华为官方这份购物比价类行业实践里专门列了这一条，根因定性就两句：
Stack 布局导致组件覆盖，position 绝对定位导致组件位置错乱。
听着像废话，但拆开看，里面其实是一条很经典的"多尺寸适配反模式"。这篇文章把这条反模式讲透，并给出商城场景下最稳的替代写法。
一、问题场景：手机OK，平板竖屏炸
先把画面还原一下。我们商城首页底部那段"购物车汇总栏"早期是这么搭的：
// ❌ 问题写法示意 Stack({ alignContent: Alignment.TopStart }) { // 下层：商品列表 Scroll() { Column() { ForEach(this.products, item => { /* 商品卡片 */ }) } } .zIndex(0) // 上层：结算按钮（想让它"浮"在底部） Row() { Text(`共${this.total}件`) Button('去结算').onClick(() => { /* */ }) } .position({ x: 0, y: '85%' }) // ← 绝对定位，手机看着还行 .zIndex(1) }手机竖屏（~360×780 逻辑宽高比约 0.46）下，y: '85%'刚好把按钮按在可视区下部，不挡列表主体，看着"能用"。
但平板竖屏（比如 10.4 寸，~600×1200，宽高比约 0.5，但关键是宽度大幅撑开、高度增长没那么猛）一跑，问题就来了：
position({ y: '85%' })是按父容器 Stack 的高度算的——平板竖屏高度从 780 → 1200，85% 对应的绝对像素从 ~663 → ~1020。按钮视觉位置上移了，但列表内容量没同步拉长（或者列表本身也有自己的高度约束），结果按钮"飘"进了列表下半区。Stack 是层叠语义——后入栈的按钮
zIndex(1)天然盖在 Scroll 上，于是出现"按钮覆盖列表最后几条商品"的经典现象，用户点"去结算"点不到，点到被盖住的商品卡片。
💡 很多人以为是"平板适配没写"，其实本质是：position 的锚点是僵死的百分比 / 像素，不随"兄弟组件的真实占位"联动；Stack 又把"覆盖关系"写死了。
二、根因拆解：两条反模式叠一起
官方文档把根因拆成两点，我们翻译成商城视角：
反模式 1：position 绝对定位在多变尺寸下的脆弱性
position的语义是"相对父组件内容区定位，且不占位"。当父容器是Row/Column/Flex时，被position的孩子不参与父容器的排版尺寸计算——父算高度时当它不存在。
这带来两个连锁反应：
在多尺寸下：平板 / 折叠展开 / 车机横屏，父容器宽高一变，
position({ x, y })算出来的绝对位置还是按那份"旧心理模型"在工作，于是飞。父容器高度算不准：因为 position 孩子不占位，父 Column 如果只靠
Scroll+Button撑，Button 不占位 → 父高度 = Scroll 高度，但 Scroll 自己又可能被内部内容撑爆 → 整个链乱掉。
反模式 2：Stack 层叠掩盖了"谁该占谁的位置"
用 Stack 的本意是"我想让按钮浮在列表上"——但商城的"列表 + 底部结算"根本不是浮层关系，是主从关系：列表是主体，按钮是尾部附属。用 Stack 硬做成"浮"，等于把"谁该在谁下面"这件事从编译器层面锁死了（zIndex 盖住），一旦位置算错，用户侧就是"按钮盖列表"的硬伤。
一句话：列表 + 底部结算 这种"一主一尾"的关系，不该用 Stack + position 做，该用 Column + layoutWeight。
三、官方给的修法（也是我们现在落地的那版）
官方示例给的修正思路很朴素，但直击要害：
把 Scroll（商品列表）和底部按钮放同一图层（同一 Column），给 Scroll 一个百分比高度或
layoutWeight(1)，按钮自然沉底，不再用 position，也不再盖。
翻译成我们商城首页的骨架：
// ✅ 修后写法（骨架级，不放全量业务代码） @Entry @Component struct MallHomePage { @State products: Product[] = [] // 商品列表数据 build() { Column() { // 顶部搜索栏 / 分类 Tab 等…… SearchBar() CategoryTabs() // 主体：商品列表（占满剩余高度） Scroll() { Column({ space: 8 }) { ForEach(this.products, (p: Product) => { ProductCard({ product: p }) }) } .padding(12) } .layoutWeight(1) // ← 关键：把剩余高度全部吃掉 .scrollBar(BarState.Off) // 底部结算栏（自然沉底，不再 position） Row() { Text(`共${this.products.length}件`) .fontSize(14) .layoutWeight(1) Button('去结算') .width(100) .height(40) .borderRadius(20) .onClick(() => { /* 跳转结算页 */ }) } .width('100%') .padding({ left: 16, right: 16, top: 12, bottom: 12 }) .backgroundColor('#FFFFFF') .shadow({ radius: 12, color: '#1A000000', offsetY: -2 }) } .width('100%') .height('100%') } }关键改动就两点：
Scroll 不写死
height('90%')也不靠 position 推按钮 → 改给.layoutWeight(1)，意思是"Column 里除了其他固定高孩子（搜索栏、Tab、底部结算栏）之外，剩余高度全归我"。底部 Row 不进 Stack、不 position、不 zIndex → 它就在 Column 的最后一行，自然沉底，高度由自己
padding + 内容决定，占位列算得清清楚楚。
这样无论屏幕从手机 360 宽 → 平板竖屏 600 宽 → 折叠展开 800+ 宽，按钮永远不会飞，也永远不会盖列表——因为它根本不在列表"上面"，是在列表"下面一行"。
四、延伸到平板横屏 / 折叠态：断点 + 栅格（呼应但别重复）
这篇跟之前写过的折叠屏展开态那篇（objectFit + aspectRatio + windowSizeChange那条）是兄弟篇，但关注点不同：
折叠屏那篇讲的是"单组件尺寸约束 + 断点驱动列数"（图片变形问题）
这篇讲的是"布局选型本身就要避开 position/Stack，改用 Flex 家族响应式原语"
两者可以串联成一条更宽的规则：
场景 | 易踩的反模式 | 正路 |
|---|---|---|
底部结算栏 | Stack + position 浮按钮 | Column + Scroll.layoutWeight(1) + 底部 Row |
悬浮拖拽按钮 | offset 无边界 | Stack + position(初始) + PanGesture + clamp（之前那篇） |
折叠展开图变形 | 固定宽高 + Fill | width(100%) + aspectRatio + Cover + 断点列数 |
平板横屏双栏 | 硬拍两套布局 | GridRow/GridCol + 断点 |
我们商城的"首页 + 底部结算"在平板横屏时可以再进化一步——用GridRow断点，竖屏单列（列表在上、结算在下），横屏切双栏（左列表 + 右结算/筛选常驻）。但那是另一篇文章的事，这篇先把"竖屏底部飞件"这一关过了。
五、我们踩过的三个具体坑（你现在避开就值了）
坑1：position 在 Row/Column 下"不占位"，导致父高度算错
Column() { Scroll().height(300) // 假设 Row().position({ y: 280 }) // 按钮"浮"在 280 处 } // Column 算高度时：Scroll 300 + Row 0(不占位) = 300 // 但视觉上按钮在 280，已经快到 Column 底部外沿了 → 某些屏下直接裁掉半截修法：别让底部栏走 position，让它进正常排版链。
坑2：Stack + zIndex 掩盖问题，调试时很难发现
Stack 的"后入栈盖先入栈"是默认行为，很多人写的时候Scroll.zIndex(0) / Button.zIndex(1)写得理所当然，但一旦位置算错，覆盖就变成产品级 Bug 而不是渲染级 Bug——用户能感知。
修法：先问自己"这两块是真·层叠关系（浮层/弹窗/红点）还是主从关系（列表+底栏/标题+内容）"，主从关系一律不用 Stack。
坑3：平板竖屏用height('90%')看似修好了，横屏又炸
Scroll().height('90%') // 竖屏 OK，横屏（高变小、宽变大）90% 太高，底部栏被挤修法：能用layoutWeight(1)就别用百分比高度——layoutWeight是"剩余分配"，天然适配任何父高变化；百分比高度是"父高 × 系数"，父高一变系数没跟着变就炸。
六、最小决策表（上线前照着过一遍）
检查项 | Pass 姿势 | Fail 姿势 |
|---|---|---|
底部栏是否在 Stack 里飘 | ❌ 不在，在 Column 尾行 | ✅ Stack + position |
底部栏是否占位 | ✅ 是（自有高度 / padding） | ❌ position 不占位 |
列表是否吃剩余高度 | ✅ | ❌ 写死 height / 靠 margin 推 |
平板竖屏是否盖内容 | ❌ 不盖 | ✅ 盖（Stack+zIndex 暴露） |
横屏/展开是否要改 | 断点驱动列数 | 又拍死数 |
七、总结
平板竖屏下"底部结算栏飞上去盖列表"这个 Bug，看着像"平板适配没做"，根子其实是手机时代留下的两个坏习惯在多变尺寸下集体暴露：
Stack 不该做主从关系，position 不该做响应式锚点。
商城的"商品列表 + 底部结算"是教科书级的Column + Scroll.layoutWeight(1) + 底部 Row结构——Scroll 吃满剩余，底部自然沉底，不飞、不盖、不占位歧义。把这条改完，手机 / 平板竖屏 / 折叠态 / 车机横屏都能一路吃下来，剩下的只是"要不要切双栏"的进阶优化，不是救命修了。
如果你也在做购物比价类应用，且首页底部栏还在用Stack + position——趁平板用户还没骂出来，先换成layoutWeight吧，十分钟的事。
