界面留白能测到什么：用容器宽度、行长和焦点顺序讨论布局

把卡片的左右 padding 从 16 调到 32，看起来也许更舒展，却可能把长标题挤成四行。留白不是一个脱离内容的审美分数；它影响的是可用宽度、信息分组和操作位置。

我会先固定同一份内容，再讨论三个容器。这样能明确说出哪里发生了变化，也能避免把未经核实的建筑语录拿来证明某个间距“必然高级”。视觉传达训练可以提供观察方式，工程判断仍要落在页面里。

宽度预算先算清楚

外层宽度、边框、内边距、列间距和列数共同决定内容宽度。下面的小函数只计算预算，不估计真实字形宽度。相同长度的中文、英文和数字在不同字体中并不等宽，字符数不能冒充浏览器排版测量。

import assert from 'node:assert/strict';
function contentWidth({container,padding,border=1,gap=16,columns=1}) {
  if (![container,padding,border,gap].every(Number.isFinite) ||
      container <= 0 || Math.min(padding,border,gap) < 0 ||
      !Number.isInteger(columns) || columns < 1) throw Error('invalid budget');
  const width = (container - 2*(padding+border) - gap*(columns-1))/columns;
  if (width <= 0) throw Error('no usable width');
  return width;
}
const scenarios = [320,640,960].map(container => ({
  container, content:contentWidth({container,padding:24})
}));
assert.deepEqual(scenarios.map(x=>x.content),[270,590,910]);
assert.equal(contentWidth({container:640,padding:24,columns:2}),287);
assert.throws(()=>contentWidth({container:40,padding:24}),/usable/);
console.log(JSON.stringify(scenarios));

<!doctype html>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width">
<title>同内容留白练习</title>
<style>
* { box-sizing:border-box; }
main { max-width:60rem; margin:auto; padding:1rem; }
article { border:1px solid #9a9a9a; padding:clamp(1rem,4vw,2rem);
  display:grid; gap:1rem; }
h1,p { margin:0; overflow-wrap:anywhere; }
p { max-width:65ch; line-height:1.6; }
button { justify-self:start; max-width:100%; white-space:normal; }
button:focus-visible { outline:3px solid #1557a0; outline-offset:3px; }
</style>
<main><article>
<h1>一个足够长的标题，应当完整说明当前操作会改变哪一份内容</h1>
<p>同一份说明文字，也包含 long-unbroken-identifier-for-layout-review。
请比较换行、分组和按钮位置，而不是只看空白面积。</p>
<button type="button">查看修改记录</button>
</article></main>

行长是观察项，焦点顺序是操作项

示例用了 max-width:65ch 作为阅读列的设计起点，不是中文一行必然 65 字的保证。ch 与字体指标有关，实际行数要看渲染。内容较宽时，限制正文列宽可以保留侧边空间；内容较窄时，继续增加 padding 可能让操作更难找。

HTML 顺序保持标题、说明、操作。视觉上把按钮挪到角落时，不能靠 CSS order 把键盘和视觉次序弄成两套。WCAG 的相关要求提供了可检查的约束，但“空白越多越好”并不是其中的结论。

把间距命名为意图

用 card.padding、section.gap 这类语义名称，比把所有 24 都替换成同一个变量更有解释力。DTCG 格式可以承载带单位的尺寸值和引用关系；它不会替团队决定何时应该使用哪个间距。不同语义偶然具有相同数值，也不意味着应该合并。

评审只改一个变量，例如把卡片内边距从 24 改成 16，保持文案、字体、视口与按钮不变。记录标题换行、操作是否完整、错误提示是否挤掉主要信息，再讨论偏好。

三张网页线框使用同样的信息次序；这是布局对照示意，不是三台设备的验收截图，也没有虚构可读性得分。

真正可复查的留白讨论，可以很朴素：哪段内容需要分组，在哪个宽度下开始拥挤，缩放后是否仍能完成操作。本文给出了预算和静态页面；320、640、960 CSS 像素及 200% 缩放的实际浏览器排版还没有验收。

验证范围与资料

本地使用 v26.3.0 检查上述示例。纯 JavaScript 示例已在 Node 权限隔离模式执行，断言通过。预算计算与非法输入断言通过；HTML 仅检查脚本语法，未测实际行长、溢出、缩放及焦点顺序。

以下发布日期或版本日期与访问日期分开记录；24—31日的新消息须发稿前再核对。

• Web Content Accessibility Guidelines (WCAG) 2.2：2024-12-12（当前所读推荐版本日期）。
• Design Tokens Format Module 2025.10：2025-10-28（最终社区组报告日期）。