移植一个布局库时，真正需要翻译的是什么——以 ohos_vlayout 的“局限性”为线索

把一个成熟的 Android 布局库搬到 ArkUI，直觉上是“翻译 API”的工作。但 ohos_vlayout 的 README 里有一份比功能列表更值得读的内容：“局限性”。这些条目看似是使用约束，实际上是一份 ArkUI 约束模型的诊断记录。

固定布局为什么必须用 Stack

README 第④条写明：FLOAT_LAYOUT、FIX_LAYOUT、SCROLL_FIX_LAYOUT、STICKY_LAYOUT 使用时，父容器必须使用 Stack 堆叠容器。

在 Android 的 vlayout 里，“固定”是 LayoutHelper 对某个位置区间的子项下达的摆放指令：无论列表滑到哪里，这个子项都被画在同一个屏幕坐标上。RecyclerView 的布局流程默认接受这种“越权”摆放。

ArkUI 的线性容器不提供这个语义。List/Column 的约束沿主轴依次传递，子项的位置由它在流中的次序决定，而不是由某个外部 Helper 直接指定坐标。Stack 是少数允许子组件脱离主轴流、以叠层方式定位的容器。强制搭配 Stack，本质上是在说：“固定”这个行为在 ArkUI 里不是一种布局策略，而是一种容器能力。LayoutHelper 可以计算位置，但计算出的坐标必须落在一个本身就允许自由定位的容器里，才能成为有效约束。

Grid 在 List 里滑不动：两套滚动约束在争夺同一段手势

第②条是整份文档里信息密度最高的一条：Grid 在无 rowsTemplate 时可以内部滑动，但一旦嵌套在 List 中且 List 能开始滑动，Grid 的内部滑动就失效了。

这不是 Grid 的 bug，而是滚动约束的归属问题。List 的滑动本质上是父容器在消耗“垂直位移”这个约束维度；Grid 的内部滑动是子容器试图在同一维度上建立自己的约束消耗路径。在 ArkUI 的声明式布局中，同一方向上的滚动优先级需要由容器层级显式裁决，而不是像 RecyclerView 那样由 LayoutManager 在测量阶段通过 canScrollVertically 动态协商。README 给出的解法——要么设置宫格高度让 Grid 内部滑动、要么不设高度让 List 滑动——实际上是在手动把滚动约束明确分配给其中一层，消除两套路径同时活跃的状态。

高度：有时算出来，有时必须显式给

第⑦条和第⑧条把 14 种容器分成了两类：一类可以显式提供宽高，另一类的高度“由 Builder 内提供的组件计算出来”。第⑨条进一步指出，如果同时提供 aspectRatio 和 Builder 内组件的高度，会出现布局异常，解决方案是让 Builder 内的 height 给定 '100%' 或“给定由布局传出来的高度”。

这组约束直接触及 ArkUI 布局的核心机制：尺寸是父约束与内容尺寸协商的结果。vlayout 的某些 Helper 天然倾向于“我计算好每个子项的位置和尺寸，容器高度是计算结果”；另一些 Helper 则倾向于“容器高度由内容撑开”。在命令式布局中，这两种模式可以共存，因为测量和布局是分离的。但在 ArkUI 的自定义布局中，onMeasureSize 需要返回一个确定的容器尺寸，而这个尺寸又会影响子组件收到的约束。当 aspectRatio（一种基于宽度推导高度的规则）与 Builder 内显式高度同时存在时，两条尺寸推导路径在同一轮测量中给出了不同的答案，框架没有优先级规则来裁决，只能表现为异常。

真正需要翻译的，是“约束的归属权”

vlayout 在 Android 上的设计前提是：LayoutHelper 是布局行为的唯一决策者，RecyclerView 把测量和摆放的权限让渡给它。移植到 ArkUI 时，Helper 的逻辑可以照搬，但 ArkUI 的容器并不默认让渡这个权限。每个容器都已经内建了自己的约束传递规则；自定义布局能做的是在一个已经被父容器约束过的空间内重新分配子组件的尺寸和位置，而不是从零开始定义一套独立的布局协议。

因此，ohos_vlayout 的“局限性”清单，本质上是在逐条标记那些约束归属权无法从 Android 模型直接继承的位置：固定布局需要 Stack 来承接越权坐标，嵌套滚动需要显式指定由哪一层消耗位移，容器高度需要在“计算”和“撑开”之间选边。把这些归属权逐一重新分配给 ArkUI 容器层级，比把 LayoutHelper 的代码翻译得更“像 ArkTS”要关键得多。这也是任何跨框架布局移植的通用教训：先确认目标框架把约束的决策权留在了哪一层，再决定 Helper 的逻辑应该写在哪一层。