面板没改高度却变高了：HarmonyOS 7 matchParent开始参与另一方向的测量

工具面板里新增了一行说明，宽度跟随父容器，高度固定。旧版本父面板没有被这一行撑高，升级target后面板终于包住了它，却让旁边的布局跟着移动。问题不一定是padding被改了，而是这行内容开始参与父容器另一方向的尺寸测量。

HarmonyOS 7修正了Row、Column、Flex里单方向matchParent子组件的测量行为。本文只处理这一条变化，不把matchParent、百分比宽度和layoutWeight混成一个概念。读完可以用一个小检查器找出受影响的测量参与者，再决定接受新布局还是保留旧尺寸。

官方Beta1说明更新于2026年8月19日，9月28日复核。下文检查器的测试在宿主运行；ArkUI页面尚未完成API26编译与设备测量。检查器只判断参与方向，不是ArkUI布局引擎，也不预测最终像素尺寸。

父容器要由内容决定大小，变化才有意义

此次变更有targetSdkVersion大于等于26.0.0的条件，相关能力起始API15。以Column为例，主轴是高度，交叉轴是宽度。如果子组件只在宽度上matchParent，它自己的固定高度仍是有意义的内容尺寸。

旧行为在父容器自适应高度时忽略了这类子组件。新行为把它计入高度测量。另一方向同理：只让高度matchParent的子组件，其宽度可以参与父容器宽度测量。这里的关键是“只在一个方向设置”，不是所有matchParent子组件无条件决定父尺寸。

案例一：纵向面板里，等宽说明行不再被漏掉

先用固定px尺寸排除字体缩放和单位换算。下列页面包含普通块、只宽度matchParent的块、只高度matchParent的块，与官方说明的条件一致：

@Entry
@Component
struct MeasureCheck {
  build() {
    Column() {
      Column({ space: '30px' }) {
        Column().width('200px').height('200px').backgroundColor('#2060A0')
        Column().width(LayoutPolicy.matchParent).height('200px').backgroundColor('#D94B46')
        Column().width('400px').height(LayoutPolicy.matchParent).backgroundColor('#39856B')
      }
      .width(LayoutPolicy.wrapContent)
      .height(LayoutPolicy.wrapContent)
      .padding('30px')
      .backgroundColor('#EEEEEE')
    }.width('100%')
  }
}

官方给出的结果是：旧行为主要由第一个子组件撑大父Column；新行为高度自适应第一、第二个，宽度自适应第一、第三个。不要仅把200、400、间距相加就宣称得到最终尺寸，布局还有约束、padding及matchParent求值的相互作用，必须通过实际页面测量。

如果产品本来就要求面板包住所有内容，通常应该接受新行为并更新截图基线。靠裁剪隐藏多出来的内容，只会保留旧缺陷。若旧尺寸是明确设计要求，则给父容器清晰的尺寸约束，而不是继续依赖“不参与测量”的历史行为。

把“谁参与”做成一个可测试检查器

检查器输入是人工确认或工具提取的布局声明。它只覆盖本文的单方向规则；flexGrow、最小最大尺寸、百分比和双方向matchParent需要另外分析，不能用这个函数给复杂页面直接下尺寸结论。

type Axis = 'width'|'height';
type SizeRule = 'fixed'|'match';
type Child = { id:string; width:SizeRule; height:SizeRule };
function contributors(children:Child[], axis:Axis, parentWrap:boolean, newBehavior:boolean): string[] {
  if (!parentWrap) return [];
  const other:Axis = axis === 'width' ? 'height' : 'width';
  return children.filter(child => {
    if (child[axis] === 'match') return false;
    if (child[other] === 'match') return newBehavior;
    return true;
  }).map(child=>child.id);
}
function eq(actual:unknown, expected:unknown): void {
  if (JSON.stringify(actual)!==JSON.stringify(expected)) throw new Error('assertion failed');
}
const panel:Child[] = [
  {id:'normal',width:'fixed',height:'fixed'},
  {id:'fullWidth',width:'match',height:'fixed'},
  {id:'fullHeight',width:'fixed',height:'match'}
];
eq(contributors(panel,'height',true,false),['normal']);
eq(contributors(panel,'height',true,true),['normal','fullWidth']);
eq(contributors(panel,'width',true,true),['normal','fullHeight']);
eq(contributors(panel,'height',false,true),[]);

返回空数组并不表示固定父容器不测量子组件，只表示这个检查器没有需要计算的“内容自适应父尺寸参与者”。函数名、返回值含义要收窄，否则一个诊断小工具很容易被误用成布局仿真器。

案例二：横向工具栏，等高按钮开始撑开宽度

换成Row后，主轴变成宽度。如果一个按钮高度跟随父容器、宽度由自身内容确定，旧代码可能认为它不会影响父Row的wrapContent宽度。新行为下，它的宽度可以参与测量，工具栏因此变宽。

这和纵向面板的“变高”不是同一条样式修复。一个需要检查高度参与者，另一个需要检查宽度参与者。可以复用同一个方向检查器，而不是复制两份按Column和Row名字硬编码的逻辑。

const toolbar:Child[] = [
  {id:'icon',width:'fixed',height:'fixed'},
  {id:'labelButton',width:'fixed',height:'match'}
];
eq(contributors(toolbar,'width',true,false),['icon']);
eq(contributors(toolbar,'width',true,true),['icon','labelButton']);
eq(contributors(toolbar,'height',true,true),['icon']);

真实工具栏还应测试长文本、不同语言和大字体。检查器不会测文本，也不会知道一个按钮最终要换几行。它的作用是帮你定位升级后新增了哪个尺寸贡献者，后面的布局验收仍要在页面上做。

保留旧外观，有三种选择

第一种，接受正确的内容自适应，让周围布局跟随变化，适合内容面板。第二种，明确父容器尺寸或边界，并对超出的内容提供滚动、换行等设计，适合固定工具区域。第三种，重新组织布局，让装饰性元素不承担内容测量职责，适合背景与前景混在同一容器的页面。

我不建议为了复现旧截图而随意给子组件负margin。那是在用另一个布局副作用抵消当前变化，很难解释大字体和横竖屏后的结果。也不要把matchParent全换成100%，两者不应在未验证约束关系时被视为完全等价。

页面目标	优先方案	代价
内容完整可见	接受新自适应	更新周边布局和截图基线
固定操作区域	父尺寸明确约束	必须设计溢出处理
装饰与内容混杂	调整容器职责	改动较多，但关系更清楚

回归测试别只看父容器尺寸

先在旧target与新target下记录父容器、三个子组件的宽高和位置，再检查点击区域是否仍与视觉一致。随后加入字体缩放、窄窗口和多语言。只记录父容器变大多少，会漏掉内容重排与遮挡问题。

遇到变化，按“父方向是否wrap、子哪一方向match、新增贡献者是谁”三步定位。不能直接从一张截图推断是系统bug；也不能因为文档说修复，就不检查自己的固定尺寸设计。版本适配最后要回到产品的布局意图。

官方依据

• LayoutPolicy.matchParent单方向布局变更
• API26行为变更与隔离条件