布局引擎实现：弹性盒和网格到底该抄哪一套

自研 UI 引擎绕不开布局。这次我们实现了一个简化版的布局引擎，只支持 Flex 和 Grid 的子集，把取舍过程记录一下。 先说结论：不要试图完整实现 CSS 的 Flex 和 Grid，那是十几年的规范积累，实现成本和维护成本都极高。我们只实现了约 30% 的能力，覆盖了 95% 的实际用例。 弹性盒保留的能力：主轴方向、主轴对齐、交叉轴对齐、伸缩比、固定尺寸、内边距和外边距。砍掉的能力：换行、基线对齐、反向排布、复杂的 min/max 约束交互。 网格保留的能力：固定列数、分数单位、固定间距、跨列。砍掉的：自动填充、自动放置的复杂规则、命名区域、span 的各种组合。 实现上的两个关键点。一是布局必须是一次遍历出结果，不要做多趟迭代收敛，否则嵌套深一点性能就崩。二是把测量和排布分开：先自底向上测量期望尺寸，再自顶向下分配最终位置。这个两阶段模型是绝大多数布局引擎的共同做法。 调试这类东西，可视化是刚需。我在引擎里加了一个调试模式，把每个节点的边界、计算出的尺寸、剩余的可用空间直接画在预览上。用 MiMo Desktop 打开这个预览页，一眼就能看出是哪一层算错了。相比之下用 Claude Code 排查的问题是"我描述不出我看到的画面"，两边配合刚刚好。 给要做类似事情的同行一句话：先把你要支持的布局能力写成一份明确的清单，写清楚支持什么、不支持什么，然后再动手。清单比代码重要，它决定了你后面会不会被无穷的需求拖垮。