重新理解 Figma：从画布绝对坐标到浏览器文档流
很多做设计的朋友在把设计稿转入真实网页、或者自己尝试写界面时，常会遇到一种典型的断层：在 Figma 里看，各个间距、图标、卡片都经过细致排布，视觉平衡恰到好处；可一旦放进真实浏览器里拉伸一下窗口，卡片可能会挤压重叠；文本多填了两行，标题就容易溢出卡片边缘；切换到不同宽度的屏幕时，原本并排的布局也往往难以自适应舒展。
这种现象的根源，不在于视觉设计是否精致，而在于静态矢量画布（Canvas）与动态网页介质（DOM）遵循着完全不同的几何与物理法则：
- Figma 的默认直觉是二维画布（Canvas）：基于笛卡尔绝对坐标系
(X, Y)。在这个维度里，只要元素在视觉平面上摆放妥当、肉眼对齐，图形结构就宣告闭环。 - 浏览器的底层逻辑是文档对象模型（DOM）与流式渲染：这是一个树状嵌套的盒模型系统。运行时的浏览器并不预设屏幕宽度，每一个盒子的大小和位置，都是顺着**文档流（Normal Flow）**与自适应约束动态计算得出的。
从画板走向真实软件，本质上是一场设计介质的跃迁。今天我们站在工程实现的客观原理上，重新梳理 Figma 的布局逻辑——当我们学会用盒模型与文档流的规律去组织图层，你的设计稿在多端设备与不同文本内容下，都能保持稳定、优雅的动态生命力。
认识容器与流向：真实界面的物理法则
在现代浏览器的排版体系中，元素默认不会固定悬浮在某个静态坐标点上，而是顺着文档流自上而下、自左向右依次流动、相互依附。
要在 Figma 里建立这种结构意识，第一步是厘清两个基础组织工具的差异：优先使用 Frame，慎用 Group。
在软件工程视角下，它们代表着完全不同的数据结构：
| 关键特性 | Figma Group（组） | Figma Frame（画框容器） | 对应 Web 基础概念 |
|---|---|---|---|
| 空间定义 | 虚包围盒（无自身物理边界，尺寸完全由子元素外轮廓决定） | 真实容器（拥有独立尺寸、内边距、圆角与背景） | <div> 容器盒 |
| 内容约束 | 无法处理内容溢出 | 支持 Clip content | overflow: hidden |
| 排布规则 | 纯静态图层打包，无法约束内部流向 | 可承载 Auto Layout 与 Layout Grid | display: flex / display: grid |
当你使用 Group 打包几个图形时，在底层数据中只记录了一组松散图层的相对位移。而如果用 Frame 作为外壳，它就成为了一个具有明确边界、能够承载内边距（Padding）和对齐约束的结构单元。
什么时候才需要脱离正常流？
流式布局负责管理页面中绝大部分常规内容的排布。只有在极少数需要与主体文档流解耦的场景下，才应该使用绝对定位（Absolute Position）：
- 头像右上角提示状态的小圆点（Badge）
- 浮动模态框右上角的关闭按钮（
X） - 界面右下角悬浮的操作入口（Floating Action Button）
- 鼠标悬停时浮现的气泡说明（Tooltip）
在这些场景下，启用 Figma 的 Absolute position 图钉图标是完全符合实现规律的。
而在常规列表、表单、内容卡片或大版面中，元素应当尽量留在容器流中。滥用绝对坐标会切断元素之间的相对依赖，当视口宽度变化或文本长度增减时，布局就会失去自我调整的能力。
一维排布规律：Auto Layout 对应的流式机制
熟练使用 Auto Layout，本质上就是在运用现代前端最通用的布局机制：CSS Flexbox。
Figma 右侧面板中的 Auto Layout 参数，与浏览器渲染引擎有一一对应的几何映射：
主轴与交叉轴的流向约束
- Horizontal 对应
flex-direction: row：内容沿水平主轴铺开，垂直方向为交叉轴。 - Vertical 对应
flex-direction: column：内容沿垂直主轴叠放，水平方向为交叉轴。
对齐方式同理：
- 居中、靠顶或靠底，对应交叉轴的
align-items计算。 - 间距均分（如选择
Space between两端对齐），对应主轴的justify-content: space-between。这种机制常用于顶部栏左右两端元素的自然拉伸分布。
空间与留白的来源：Gap 与 Padding
在规范的流式排布中，留白不依赖放置空白图形来占位，而是由容器属性统一度量：
- Gap 对应
gap属性：约束子元素之间的固定物理间隔。 - Padding 对应
padding属性：定义容器外框到内部内容之间的内缩安全距离。
决定响应式弹性的三种尺寸法则
界面在不同屏幕宽度下的适应性，核心取决于图层的 Resizing 属性分配：
| Resizing 模式 | 对应计算原理 | 适用场景 | 尺寸定义不当的表现 |
|---|---|---|---|
| Fixed | 锁定物理像素宽度或高度 | 固定尺寸的图标、头像、特定宽度侧边栏 | 自适应卡片误设为 Fixed，在大屏上留白过大，小屏上被视口截断 |
| Hug contents | 容器尺寸由内部子内容完全撑开（fit-content） | 按钮、Tag 标签、独立说明气泡 | 按钮误设为固定宽度，多语言切换或字数微调时文字溢出边框 |
| Fill container | 容器自动填满父级分配的全部剩余空间（flex: 1） | 卡片标题、自适应输入框、栅格列 | 输入框误设为 Fixed，父容器拉宽后右侧留下未被吸收的空白 |
自动换行 Wrap 的流向补充
当需要排布 Tag 标签墙或多选筛选项等不确定数量的元素时，启用 Auto Layout 的 Wrap 模式（对应 flex-wrap: wrap），可以让内容排满当前行后自动折向下一行，且每行元素依然保持预设的间距规范。
二维网格秩序：为什么单一维度会导致嵌套过深？
Auto Layout 擅长处理单一维度的线性流（单行或单列）。但在面对规整的仪表盘面板、Bento Grid（便当盒网格）或商品矩阵时，如果仅仅依靠一维排布，容易产生多层级嵌套。
例如制作一个 3 行 3 列的看板，若纯靠一维思维，通常需要先创建三个水平 Frame，再将它们装入一个垂直 Frame。这种方式存在局限：
- 结构层级冗余：多出了仅为辅助横向排列的中间包装层。
- 缺乏二维协同：一旦某一处需要做跨行或跨列展示（如顶部第一张卡片横跨两列），原本维护的横纵嵌套关系就需要整体拆解重建。
这正是现代排版中引入 二维网格（Grid） 的原因。在 Figma 中，与之对应的是 Layout Grid。
栅格参数的标准映射
工程实践中常用的 12 列响应式栅格系统，在 Figma 中具有清晰的参数映射：
| Figma Layout Grid 配置 | 对应 CSS Grid 概念 | 实际物理作用 |
|---|---|---|
| Columns: Count (12) | grid-template-columns: repeat(12, 1fr) | 将可用空间等分为 12 份基准列（1fr 为弹性比例单位） |
| Gutter (如 24px) | gap: 24px | 列与列、行与行之间的走道间隙 |
| Margin (如 64px) | 容器内边距 padding | 整个网格内容区与画板边缘的安全安全边界 |
比例分配与跨列机制
在网格系统下，元素直接平铺在同一层级内，通过占用列数（Column Span）实现宽度的灵活划分：
- 半宽卡片：占 6 列（
col-span-6） - 三等分卡片：占 4 列（
col-span-4） - 主区与侧边栏：8 列 + 4 列组合（
col-span-8与col-span-4）
面对不同尺寸的设备时，无需重新构筑图层架构，只需将元素在小屏上的占用列数调整为 12 列满宽，整体内容就会自然转为纵向单列排布。
排布方案的选用边界
- 选用 Auto Layout：导航栏、列表单项、卡片内部结构（头像+文字）、按钮等局部组件（关注内容尺寸驱动与单向流水）。
- 选用 Layout Grid：页面最外层骨架、Bento Grid 看板、电商商品流等宏观二维布局（关注整体比例分割与多单元格跨越）。
文本图层：动态内容下的排版规律
在真实界面中，文本并非静态刻印的字形，而是具有动态排版特征的矩形内容块。为文本框设置合理的尺寸模式，是保证多语言与长文本稳定展示的基础。
文本尺寸模式的应用场景
在 Figma 的 Text 设置面板中，三种模式各自对应不同的计算规律：
- Auto width：单行文本，宽度随文字增减而变化，不自动换行。适用于按钮文案、数据指标、单行标签。
- Auto height：正文段落推荐的标准模式。宽度锁定或受父级容器约束（配合
Fill container），文本增加时仅向下折行并自然撑开高度。 - Fixed size：固定宽高的受限模式。文字过长时可能导致显示不全，字数过少时容易留出无意义空白。适合在限定空间内配合省略规则使用，常规排版中建议谨慎设定。
行高计算与段落间距机制
- 避免通过连续回车控制段距：空回车在排版系统中被视为独立的行内字符。由于不同操作系统与设备默认字体的度量基线存在差异，空回车在各端可能产生不同程度的垂直间距漂移。
- 推荐统一的段距与行高规范：建议使用文本面板中的
Paragraph spacing统一管理段间距，或通过父容器 Auto Layout 的Gap实现多段落的精确分隔。行高推荐设置为无单位比例（如正文采用150%），确保在不同分辨率渲染下高度表现一致。
语义清晰的图层架构：映射组件化思维
无论是前端开发构建代码，还是设计师管理大型系统，界面的高层组织都遵循 组件化（Component Decomposition） 思想：将复杂的版面拆解为职责明确、便于复用的功能单元。
观察以下两组图层目录的对比：
未组织语义的图层目录：
Frame 481
├── Group 12
│ ├── Rectangle 4
│ └── text
├── Frame 482 copy
└── Rectangle 10这种命名方式只记录了软件默认的生成顺序，掩盖了界面的业务意图与模块归属，使得后续维护者需要逐个核对内部元素才能确认其用途。
具备清晰语义的图层架构：
DashboardLayout (Grid)
├── Sidebar (Vertical Frame)
│ ├── UserProfile (Auto Layout)
│ └── NavigationList (Auto Layout)
└── MainContent (Vertical Frame)
├── PageHeader (Auto Layout)
└── MetricCardGrid (Grid)
├── MetricCard (Auto Layout)
└── MetricCard (Auto Layout)这种结构直接呈现了界面的功能全貌：Sidebar 明确代表侧边栏；MetricCard 清晰标注了同类卡片的复用形态。在设计系统沉淀或工程实现时，这种自解释的命名让模块拆分与协作一目了然。
设计稿重构实践：自查五步法
面对历史遗留的自由排布设计稿，可以按照以下步骤逐步梳理为符合介质特性的结构：
- 统一容器类型：将承担外壳功能的组转换为具备明确边界定义的 Frame。
- 由内而外封装基础单元：从最底层的小结构（如：图标加文字）开始，添加 Auto Layout，设定规范的 Gap 与 Padding。
- 核查弹性伸缩配置：为各级容器与内容分配合适的 Resizing 属性。需要填满区域的设置为
Fill container，自适应内容的设置为Hug contents。 - 收敛绝对定位范围：除角标、遮罩浮层或独立悬浮按钮外，让常规元素自然归入流式排布。
- 视口拉伸压力测试（Stress Test）：
- 选中最外层 Frame，按住边缘水平拉宽并收缩。
- 观察重点：正文是否按预期换行？卡片是否均匀分配空间？内部间距是否保持稳定？若出现元素重叠或固定留白失控，顺着图层链条即可排查出哪一级的
Fill / Hug设置中断。
交付自查清单
在设计定稿或进入实现阶段前，可以对照以下清单进行快速核验：
- [ ] 页面结构以具备明确边界与内边距的 Frame 为主体。
- [ ] 常规排布依赖流式或网格约束，绝对定位仅用于少数特定浮动场景。
- [ ] 按钮等内容型微组件，文本设为
Auto width，容器设为Hug contents。 - [ ] 多行说明及正文设为
Auto height，宽度受容器Fill container弹性约束。 - [ ] 二维规整的卡片阵列明确设定了列数与间距规范，避免不必要的深度嵌套。
- [ ] 关键功能区与通用组件保持清晰的语义化命名。
- [ ] 经过外层框架的拉伸走查，动态弹性表现符合预期。
掌握浏览器流式与盒模型的运转机制，并不是为了用技术规矩去束缚创意，而是让设计语言与软件介质达成更深度的默契。当设计在构建之初就具备了严谨的结构秩序，它在任何终端屏幕上，都能从容展现最初所构想的秩序与美感。
在下一篇 Phase 1 中，我们将真正打开浏览器的 DevTools（检查器），直观观察这些盒子在实际渲染引擎中是如何被计算与布局的。