网页制作排版方法：从布局体系到字号行高与间距网格的系统实践

做网页排版这件事，我前后折腾了差不多八年。最早那几年，我以为排版就是把文字塞进 div 里，调调字号、加加边距就完事了；后来接手一个内容站，用户反馈"看着累""读两段就想关"，我才意识到问题不在内容，在网页制作的排版方法。同一个页面，字号差两像素、行高差零点二、段落间距从 12px 改成 16px，读者的停留时长可能差出一大截。排版不是装饰，它决定信息能不能被读进去。

下面这些内容，是我把一个内容型页面从"能看"打磨到"耐看"的完整过程记录。里面涉及布局体系的选择、字号行高的量化方法、间距网格的搭建、中英混排的处理、响应式的断点策略，以及一堆在真实项目里踩出来的坑。适合两类人看：一类是刚学完 HTML/CSS，写出来的页面总感觉"哪里不对但说不上来"的新手；另一类是做了几年页面，能跑起来但缺少系统方法、每次都要凭感觉调样式的人。我会把每个参数的来由算给你看，把每一步的操作意图讲清楚，代码可以直接抄。

1. 排版方案的整体设计与思路拆解

1.1 先定基准线，别一上来就写样式

我见过太多新手拿到设计稿，第一件事就是给标题写font-size: 32px，给正文写font-size: 14px，然后一路往下堆。写到第八个模块的时候，发现字号出现了 13px、15px、17px、22px 这种零碎值，整页看起来像四五个人分别做的。

根源在于没有基准线。排版的本质是比例关系的重复，不是一个个孤立的数值。所以我现在的习惯是：动手写任何一条样式之前，先确定三件事——基准字号、基准行高、基准间距单位。这三样定死之后，后面所有的值都从它们推导出来，页面自然就"齐"了。

基准字号我一般取16px。理由很实在：浏览器默认字号就是 16px，1rem = 16px，取整换算不产生小数；主流手机屏幕在 375px 宽度下，16px 的中文字符一行能排 20 个出头，不会挤；再小到 14px，中文字形笔画密集时确实吃力，尤其是"镶嵌""饕餮"这类字，在低分辨率屏上会糊成一团黑。

基准行高取1.6，也就是 16 × 1.6 = 25.6px。这个数字后面会再优化，先记着。

基准间距单位取8px。为什么是 8 不是 10？因为 8 是 2 的三次方，能被 2、4 整除，在 1 倍、1.5 倍、2 倍、3 倍屏下都不会出现半像素模糊；而且 8 的倍数序列 8、16、24、32、48、64 之间的疏密关系，恰好符合人眼对"亲近—疏远"的感知分层。10px 体系做出来的间距是 10、20、30、40，颗粒度相对粗，表达"稍微靠近一点"这种微妙关系时就不够用了。

提示：基准值定下来之后，写进 CSS 变量里，并且在团队里强制只允许使用这些值。我吃过一次亏，两个人协作，一个用 15px 一个用 16px 做卡片间距，视觉上几乎看不出来，但整页扫过去就是有一种说不出的不协调。

1.2 三套布局体系各管什么，别乱用

排版的骨架是布局，布局选错了，后面调死也调不顺。CSS 发展到现在，实际在用的是三套体系：文档流（Normal Flow）、Flexbox、Grid。它们的定位不是"新的一定比旧的好"，而是各管一段。

文档流负责最基础的自上而下堆叠，段落、标题、列表、图片，天然就是块级元素垂直排列。这一层根本不需要额外写布局代码，反而是很多人喜欢给每个段落套一层display: flex，纯属自找麻烦——flex 容器的子元素会失去外边距合并行为，段落间距要重新算，还容易出各种对齐怪相。

Flexbox 负责一维排列，也就是一行或者一列的分配。导航栏、按钮组、图文左右结构、表单标签与输入框的对齐，这些都是一维问题，一行 flex 就解决。它的强项是子元素之间的空间分配（justify-content）和伸缩比例（flex），处理"左边固定宽、右边自适应"这种需求，比任何老办法都干净。

Grid 负责二维，行和列同时控制。整页的三栏布局、卡片墙、杂志式的图文错落排版，用 Grid 写出来的代码量是 Flex 的三分之一，而且结构在 CSS 里看得见。举个具体对比：一个 12 列的栅格系统，用 Flex 要嵌套两层容器加百分比计算，用 Grid 就是grid-template-columns: repeat(12, 1fr)加grid-column: span 4，语义直白。

我的分工原则很简单：页面大结构用 Grid，组件内部用 Flex，纯文本流交给文档流。三层各司其职，样式表不会打架。

1.3 把设计令牌提到最前面，是为了三个月后的自己

"设计令牌"这个词听着玄，说白了就是把颜色、字号、间距、圆角、阴影这些原子值抽成 CSS 自定义属性，集中放在一个:root里。

我最初不做这一步，觉得多写一层变量是浪费时间，直接在样式里写#2c3e50、16px。结果项目做了半年，产品说要支持深色模式，我改了两天，还漏了三处硬编码。从那以后，第一件事永远是建变量层。

变量层带来的好处不只是换肤。更实际的是约束：当你只有--space-1到--space-8这八个间距可选时，你根本没机会写出padding: 13px这种值，一致性是被强制保证的。另外，变量名本身就是文档，后来接手的人看--text-body就知道这是正文色，不用去猜#4a4a4a是干嘛的。

这一步还有个小细节值得说：变量命名我倾向按语义而不是按视觉。写--color-primary而不是--color-blue，写--font-size-heading-2而不是--font-size-28。因为视觉值会变，语义不会。品牌色从蓝换成绿的时候，我只需要改变量的值，不用去全局搜blue。

2. 核心细节解析：字号、行高、间距的量化方法

2.1 字号阶梯怎么定：用比例，不要拍脑袋

字号不能一个个单独定，要用等比数列推导，这叫模块化比例。常见的比例有 1.125（温和）、1.2（常用）、1.25（明显）、1.333（强烈）。选哪个取决于内容的调性——资讯类页面层级不需要太夸张，1.2 到 1.25 就够；营销落地页需要强对比，可以上 1.333。

我一般以 16px 为基准，用 1.25 往上推，同时把结果取整到 4 的倍数，方便和间距网格对齐：

取整这一步很关键。31.25px 这种值在 1.5 倍屏上会渲染成 46.875 物理像素，浏览器做亚像素抗锯齿，边缘会发虚。取到 30px 之后，1 倍屏 30、1.5 倍屏 45、2 倍屏 60，全是整数，字口干净。

往下走的两档要克制。小于 12px 的中文在手机上基本没法读，我见过不少页面把辅助文字设成 10px，那是把信息藏起来不让人看。真需要弱化，靠颜色降低对比度比缩小字号更合适。

还有一个容易被忽略的点：字号阶梯最好控制在 5 到 6 档。超过 8 档，层级就乱了，读者反而分不清主次。我做页面时经常删档，把"差不多大"的两档合并掉，页面立刻清爽。

2.2 行高的取值逻辑，以及那次"差 0.4 就差很多"的经历

行高不是凭感觉给的，它跟字号、字面大小、行长都有关系。核心公式可以这样理解：

行盒高度 = font-size × line-height 视觉行距 = 行盒高度 - 字面高度（约等于 font-size × 0.85 到 0.9）

以 16px 正文为例，line-height: 1.5时行盒是 24px，字面高约 14px，视觉行距 10px；line-height: 1.75时行盒 28px，视觉行距 14px。后者明显更透气。

中文和西文的取值习惯不一样。西文小写字母有上下伸展的 ascender/descender，字体自身留白较多，行高 1.4 到 1.5 就够。中文是方块字，字面几乎占满字身框，字体自带留白少，行高低于 1.6 就会显得密不透风。我的经验值：中文正文 1.7 到 1.8，西文正文 1.5 到 1.6，中英混排取 1.75 折中。

标题反过来，行高要小。大字号本身视觉重量大，行高按比例给会显得散，一般取1.2 到 1.3。38px 的标题配 1.25 行高，行盒 47.5px，两行标题挨得紧凑，形成视觉块。

这里还有个取整的技巧。16 × 1.5 = 24，正好是 8 的 3 倍；16 × 1.75 = 28，不是 8 的倍数。要不要为了网格牺牲最佳行高？我的答案是不要。行高的体验权重远高于网格对齐，强行把行高凑成 24 或 32，要么太挤要么太散。网格是给间距用的，行高按可读性来，两者不冲突。

提示：line-height一定要带单位写倍数（如 1.75），不要写死像素。带单位的倍数会在子元素继承时按各自的字号重新计算，写死像素则会被子元素（比如突然变小的图注）继承成灾难性的行高。

2.3 行长与容器宽度：一行到底放多少字

这是排版里最被低估的参数。行长太长，眼睛从行尾折回行首时容易串行；行长太短，视线频繁跳转，阅读节奏被打断。西文的经典推荐是45 到 75 个字符，中文因为字符信息密度高，28 到 40 个汉字比较舒服。

换算成容器宽度就很好算了。中文正文 16px，按 34 字算：

34 × 16px = 544px

再加上左右各 24px 的内边距，内容区宽度约 592px。实际项目里我一般取640px 到 720px，对应 35 到 40 个汉字，留一点余量。

这个数字怎么用？给正文容器设max-width，而不是设固定宽度：

.prose { max-width: 42rem; /* 672px，约 42 个汉字 */ margin-inline: auto; /* 居中 */ padding-inline: 1.5rem;/* 小屏留白，防止贴边 */ }

max-width配margin-inline: auto是黄金组合。宽屏时内容居中，两侧留白自然形成"阅读呼吸区"；窄屏时容器撑满，靠 padding 保证不贴边。用px还是rem？我倾向rem，用户改了浏览器默认字号，容器跟着缩放，不破坏行长。

还有一层：不同板块的内容宽度可以不同。正文窄一点（672px），图片和图库宽一点（最多到 1000px），全宽区块（比如横幅）可以突破容器。这种"窄正文 + 宽媒体"的节奏变化，比整页一个宽度要有呼吸感。实现上给媒体元素一个负的margin-inline或者用width: min(1000px, 100%)加居中即可。

2.4 8px 间距网格与段落节奏的实操

间距网格的价值在于建立层级感知。人对距离的判断是相对的，两段 12px 和两段 16px 单独看没区别，但放在一起，"标题到正文 8px、正文到正文 24px、段落到段落 32px"这种递进，眼睛立刻知道哪块是一组的。

我的间距令牌序列是：

为什么留一个 4px？因为"图标和文字之间"这种距离，8px 太松，0 又太挤，4px 恰好。这个 4 是 8 的一半，属于半档，允许存在但不要滥用。

实际排段落时有个陷阱：别同时用段间距和首行缩进。中文印刷传统是首行缩进两个字符，网页上更常见的是段间距。两样一起用，段落开头既缩进又有空隙，读起来像中间被砍了一刀。我一般选段间距，因为网页内容经常是动态渲染的，段间距在富文本编辑器里表现更稳定。

另外，margin在垂直方向会合并（margin collapse），两个 24px 的 margin 相邻只产生 24px 而不是 48px。这个特性用好了省事，用不好就是"我明明设了 24px 怎么没生效"。我的做法是：垂直间距统一由margin-block-start单向控制，避免双向设置，也避免合并带来的不确定性。

2.5 中英混排、数字与标点的细节处理

中文页面里永远有英文单词、代码片段、数字。处理不好，一行字里会出现忽大忽小的空隙，视觉上像被撕开。

第一个要处理的是中西文之间的自动间距。浏览器默认会在中西文交界处加一点空隙，但这个空隙大小由字体决定，不可控。想让间距统一，可以手动插 （窄空格），但内容一多就疯了。更实际的办法是选一个中西文兼容好的字体栈，让系统字体自己处理。

第二个是数字对齐。表格里的数字、统计面板里的数值，如果用的是比例数字（proportional numerals），每个数字宽度不同，"1"占的位比"8"窄，一列数字排下来眼睛找不到位置。加一行：

.numeric, table td { font-variant-numeric: tabular-nums; }

等宽数字之后，小数点自然对齐，扫一眼就能比较大小。

第三个是标点。中文标点是全角，占一个汉字宽；行内被强制断行时，句号逗号不能出现在行首，这叫"避头尾"。CSS 里的line-break: strict或word-break: normal配合浏览器的默认行为基本能处理。但有个常见问题：一个长英文单词或者 URL 撑破了容器，导致横向滚动条。这时候要用：

.prose { overflow-wrap: break-word; /* 长单词强制断行 */ word-break: normal; /* 保持中文避头尾规则 */ }

注意不要用word-break: break-all，那会让中文也能在任意字符间断开，虽然不溢出，但断行位置变得随机，读起来别扭。overflow-wrap: break-word只在必要时才断，是更克制的方案。

还有字距。中文正文不要加letter-spacing，加了字会显得松散断裂。只有两种情况需要动：一是大标题（30px 以上），可以收-0.02em让字更紧凑有力；二是全大写英文标签，加0.05em因为大写字母本身排列偏紧。这两条我用了很多年，几乎没出过错。

3. 实操过程：从零搭一套可复用的排版骨架

3.1 目录结构与基础重置

先看整体文件组织。排版相关的东西我从来不分得太细，五个文件足够：

/styles tokens.css /* 变量：颜色、字号、间距、圆角 */ reset.css /* 重置：清除默认样式差异 */ base.css /* 基础：html/body/标题/段落/列表 */ layout.css /* 布局：容器、栅格、板块 */ components.css /* 组件：卡片、表格、代码块、图注 */

reset.css我不用那些几百行的通用重置库，只处理真正影响排版差异的几条：

*, *::before, *::after { box-sizing: border-box; } body, h1, h2, h3, h4, p, figure, blockquote, dl, dd { margin: 0; } ul, ol { margin: 0; padding: 0; list-style: none; } img, picture, video { display: block; max-width: 100%; height: auto; }

box-sizing: border-box是第一位的。默认的content-box下，设了width: 100%再加 24px 内边距，元素实际宽度变成 100% + 48px，撑破容器。这个坑我踩过不止一次，每次都是"怎么突然横向滚动了"，查半天发现是内边距。

img { display: block }也很关键。图片默认是行内元素，按基线对齐，下面会留出约 3 到 5px 的缝隙，这是因为行内元素的基线下要留出字母降部空间。改成块级，缝隙消失。

注意：list-style: none会带来一个副作用——在部分浏览器里，<ul>可能失去隐式的列表语义（无障碍读屏软件不再播报条目数量）。如果列表内容有语义价值，用role="list"补回来。

3.2 令牌层与容器宽度的具体写法

变量层我是这么写的，值都在注释里说明用途，方便后来人（包括三个月后的自己）快速上手：

:root { /* 字号阶梯 */ --fs-caption: 0.8125rem; /* 13px */ --fs-body: 1rem; /* 16px */ --fs-h4: 1.25rem; /* 20px */ --fs-h3: 1.5rem; /* 24px */ --fs-h2: 1.875rem; /* 30px */ --fs-h1: 2.375rem; /* 38px */ /* 行高 */ --lh-tight: 1.25; --lh-body: 1.75; /* 间距 */ --space-1: 0.25rem; --space-2: 0.5rem; --space-3: 0.75rem; --space-4: 1rem; --space-5: 1.5rem; --space-6: 2rem; --space-7: 3rem; --space-8: 4rem; /* 宽度 */ --width-prose: 42rem; --width-wide: 60rem; }

用rem还是px？变量里我全用rem，因为一旦用户把浏览器默认字号调大（部分用户确实会调到 20px），px写死的值纹丝不动，界面等于没响应无障碍设置。rem会跟着缩放。代价是换算时要在脑子里除以 16，写习惯了就好。

容器分三档，这是版式节奏的基础：

.wrap { width: 100%; max-width: var(--width-wide); margin-inline: auto; padding-inline: var(--space-5); } .prose { max-width: var(--width-prose); margin-inline: auto; }

.wrap管全宽板块（60rem ≈ 960px），.prose管正文（42rem ≈ 672px）。两个容器嵌套使用，宽板块里嵌窄正文，视觉上就有了"宽—窄—宽"的节奏。

3.3 正文区排版的具体实现

正文样式是整页最该细调的部分，我把几个关键点拆开说。

.prose { font-size: var(--fs-body); line-height: var(--lh-body); color: #2b2b2b; text-align: start; } .prose p { margin-block: 0 var(--space-5); } .prose p + p { margin-block-start: var(--space-5); }

text-align: start而不是justify，这是血泪教训。两端对齐在中文字体里看起来很美，但最后一行的处理和标点挤压常常出问题，尤其是含有英文单词或长数字的段落，词间距会被拉得忽大忽小，出现"河流"（rivers），读者视线顺着空白往下滑。左对齐的右边缘参差确实不够整齐，但可读性稳定得多。

标题的写法要注意两件事：上方间距必须大于下方间距，这样标题才会"归属"于它下面的内容。

.prose h2 { font-size: var(--fs-h2); line-height: var(--lh-tight); letter-spacing: -0.02em; margin-block: var(--space-8) var(--space-4); } .prose h3 { font-size: var(--fs-h3); line-height: var(--lh-tight); margin-block: var(--space-7) var(--space-3); }

margin-block: 64px 16px，上下比 4:1，眼睛很自然地把标题和下面那段文字归为一组。反过来如果上下一样，标题就像飘在两段之间，归属不明确。这是排版里最容易被忽略、效果最直接的一条。

段落之间用p + p相邻选择器而不是给所有 p 加下边距，是为了避免最后一个段落多出一段空隙，影响和后面元素的衔接。

3.4 响应式：断点选择与流式字号

断点我不按机型设，按内容什么时候变难看设。实际就三个：

字号在小屏上要不要缩？我试过缩到 15px，实测阅读体验下降明显，尤其是中文字。所以正文保持 16px 不缩，缩的是标题和间距：

@media (max-width: 480px) { :root { --fs-h1: 1.75rem; /* 38 → 28 */ --fs-h2: 1.5rem; /* 30 → 24 */ --space-7: 2rem; /* 48 → 32 */ --space-8: 2.5rem; /* 64 → 40 */ } }

用变量覆盖而不是逐条写媒体查询，好处是改动集中在一处，不会漏掉某个组件。

更优雅的方案是clamp()，一行搞定流式字号，省掉断点：

.prose h1 { font-size: clamp(1.75rem, 1.25rem + 2.5vw, 2.375rem); }

拆开算：最小值 28px（小屏），首选值1.25rem + 2.5vw（20px + 视口宽的 2.5%），最大值 38px（大屏）。视口 320px 时首选值是 20 + 8 = 28px，刚好触底；视口 720px 时是 20 + 18 = 38px，触顶。中间平滑插值。这种写法的好处是没有跳变，坏处是可读性差，半年后自己都要拿计算器算一遍，所以我只在标题上用，正文老老实实固定值。

移动端还有一个必须处理的：100vh。老写法height: 100vh在手机浏览器上会算进地址栏高度，页面底部被裁掉一块。现在用100svh（small viewport height），取地址栏展开时的最小高度，内容不会被裁。兼容性查一下，这两年主流浏览器都支持了。

3.5 图文混排、表格与代码块的专门处理

图片。正文配图最容易出问题的不是尺寸，是节奏。我的处理是图片居中、上下留足间距、图注字号降两档：

.prose figure { margin-block: var(--space-6); } .prose figure img { margin-inline: auto; border-radius: 4px; } .prose figcaption { margin-block-start: var(--space-2); font-size: var(--fs-caption); line-height: 1.5; color: #6b6b6b; text-align: center; }

图注用 13px 加灰色，是"可读但退后"的层次。如果图注和正文一样大一样黑，读者会把它当正文读，遇到下一段时产生断裂感。

表格。表格撑破容器是老问题。核心一行table-layout: fixed，让列宽按第一行分配，不再由内容决定：

.prose table { width: 100%; table-layout: fixed; border-collapse: collapse; font-size: 0.9375rem; /* 15px，比正文小一档 */ } .prose th, .prose td { padding: var(--space-3) var(--space-4); border-bottom: 1px solid #e6e6e6; text-align: start; overflow-wrap: break-word; } .prose tbody tr:nth-child(even) { background: #fafafa; }

border-collapse: collapse让相邻单元格共用一条边框，否则每格四边都有线，看起来像网格纸，密得慌。斑马纹用nth-child(even)加极浅底色，比全边框表格轻很多。窄屏下表格还是可能溢出，外面套一层overflow-x: auto的容器让它横向滚动，比压缩字号或者隐藏列都靠谱。

代码块。代码的字号要比正文小一档（15px 或 14px），因为等宽字符视觉上比中文大；行高 1.5 就够，代码的行间不需要那么多呼吸；必须允许横向滚动：

.prose pre { margin-block: var(--space-5); padding: var(--space-4); overflow-x: auto; font-family: ui-monospace, "SFMono-Regular", Menlo, Consolas, monospace; font-size: 0.875rem; line-height: 1.6; background: #f5f5f5; border-radius: 6px; } .prose :not(pre) > code { padding: 0.15em 0.4em; font-size: 0.9em; background: #f0f0f0; border-radius: 3px; }

行内代码的font-size: 0.9em是相对值，会跟着所在段落的字号走，不会出现正文 16px 而代码 14px 的突兀落差。padding用 em 同理。

4. 常见问题与排查技巧实录

4.1 问题速查表

排版问题大多有固定套路，我把这几年遇到频率最高的整理成表，遇到时先对号入座：

4.2 排查思路：从外到内，逐层收敛

新人排查排版问题往往是"哪儿不对点哪儿"，打开开发者工具乱改一通，改好了也不知道为什么好。我的习惯是固定顺序，从外到内。

第一步看容器宽度。开发者工具里选中元素，看盒模型面板的宽度是不是等于预期。如果超出父容器，问题在宽度计算上。这时候依次怀疑：box-sizing是不是content-box、有没有写死width加padding、有没有min-width卡住。

第二步看外边距合并。如果两个块的间距不是简单的相加，八成是合并了。判断方法很简单：给其中一个加padding: 1px或overflow: hidden，合并被阻断，间距立刻变化，那就确认是合并问题。解决靠统一的间距策略，不是逐个margin调数值。

第三步看字体度量。同一段文字在16px/1.75下，不同字体渲染出的实际高度能差 2 到 3px，因为每种字体的 ascent/descent 不同。如果两个元素明明设了相同行高却对不齐，那基本是字体栈不一致，某个元素回退到了别的字体。查font-family有没有拼错，或者有没有在某个组件里被覆盖。

第四步才是微调具体数值。前面三步没确认就调数值，等于在错误的地基上刷墙。

提示：Chrome 开发者工具的"Layout"面板可以高亮显示网格和行盒，调排版时打开它，能直观看到每行的实际高度和基线位置，比反复截图比对高效得多。

4.3 几个我踩过、并且在文档里找不到答案的坑

坑一：rem遇上浏览器最小字号限制。我给图注设了0.8125rem（13px），测试时正常。但有用户把浏览器最小字号设成了 16px，所有小于 16px 的文字被强制放大，图注瞬间和正文一样大，视觉层级全塌。这个问题没法完全解决，因为最小字号是浏览器的用户设置。缓解办法是：关键信息不要依赖字号差异来区分层级，配合颜色、粗细、位置一起用；同时避免用小于 12px 的字号，被强制放大的幅度会小一些。

坑二：gap和margin混用导致间距翻倍。早期我用 flex 布局时习惯给子元素加margin-right，后来又改用gap，两样同时存在，间距变成 24px + 16px = 40px，怎么调都不对。现在的铁律是：用了 flex 或 grid 就只用 gap，子元素不写任何方向性 margin。这条规则我贴在便签上贴了小半年。

坑三：中文字体的font-weight: 500经常不生效。想给某段文字稍微加粗一点，设了 500，结果和 400 长得一模一样。原因是大多数中文字体只有 Regular 和 Bold 两个字重，浏览器遇到 500 时会就近映射——有的映射到 400，有的映射到 700，跨浏览器表现还不一致。解决办法是要么用 400，要么直接 700，中间的 500、600 在中文环境里基本不可靠。西文字体支持多字重的多，但混排时也要小心，同一行里中英文粗细不一致会很明显。

坑四：letter-spacing加到最后一个字上，居中会偏。给标题加letter-spacing: 0.05em后，每个字符右边都多出一点空隙，包括最后一个字。文字块整体看起来左轻右重，居中时明显偏左。修法是加margin-inline-end: -0.05em把多余的空隙抵消掉。这个技巧我用了很多次，几乎没人提，但效果肉眼可见。

坑五：line-height写在body上，表单控件不继承。input、button、select这些表单控件默认不继承父级的字体和行高，会用自己的默认值。结果正文行高 1.75，输入框里文字挤成 1.2，看着非常割裂。统一处理：

input, button, select, textarea { font: inherit; line-height: inherit; }

font: inherit一行把字体族、字号、字重、行高全部继承过来，是最省事的写法。

5. 排版参数的验证与迭代方法

5.1 用对比而非绝对值来判断好坏

排版参数没有绝对正确值，只有相对合适的值。我判断一套参数好不好，用的是并排对比：同一段文字，用两组参数各渲染一份，并排放在一起，扫一眼就知道哪个更舒服。

具体做法是在页面上放一个临时调试面板，用滑块调--fs-body和--lh-body，实时看效果。调的时候不要盯着一句话看，要看一整段，而且要把视线从屏幕前 30cm 移到 60cm 处快速扫读——这个距离下，如果段落能顺畅地读下来不卡顿，参数就对了。眼睛贴近屏幕逐字看，任何参数都"还行"，因为注意力在字上不在节奏上。

实测下来的经验：正文行高从 1.5 调到 1.75，感受是"从能读变舒服"；从 1.75 调到 1.9，感受是"变松了但没更好"。所以 1.75 附近是甜点区。段落间距从 16px 到 24px 是明显改善，24px 到 32px 就没那么大差别了，这时候要考虑整体页面长度，别让间距把页面拉得太长。

5.2 对照可读性标准做底线校验

有几个客观指标可以当底线用，不追求满分，但不能低于线。

第一个是对比度。正文文字与背景的对比度，业内推荐不低于4.5:1；18px 以上的大字号可以放宽到 3:1。深灰字配白底是最常见组合，#2b2b2b配#ffffff的对比度约 13.6:1，非常充足；#6b6b6b配白底约 5.7:1，做图注够用；#999999配白底只有 2.8:1，做辅助文字勉强，做正文绝对不行。很多人喜欢用浅灰做"高级感"，实际是拿可读性换观感。

第二个是行长上限。前面算过，中文 40 字以内。超出这个范围，眼睛回到行首的定位成本急剧上升。有些页面在宽屏上正文拉满整个 1440px 宽度，一行 80 多个字，读两行就晕。

第三个是行数下限。这一点常被忽略：一个段落如果只有一行，且长度不足行长的 60%，那它和上下文的视觉关系会很尴尬，看着像被孤立的标签。处理办法是控制内容断句，或者用text-wrap: pretty让浏览器优化尾行——这个属性较新，支持度还不够，但配上fallback不影响老浏览器。

5.3 排版规范的落地方式

一个人做项目，规范在心里就行；两个人以上，就必须写下来，否则三个月后代码里会出现五种间距值。

我实践下来最有效的落地方式不是写一份几十页的文档，而是把规范变成代码里的约束。具体三条：

第一，间距只能通过 CSS 变量使用，代码审查时看到padding: 13px直接打回。这一条执行下去，一致性基本就有保证了。

第二，建立一页"样式预览页"，把所有标题层级、段落、列表、表格、代码块、图注的实际渲染效果集中展示。任何人改动了基础样式，打开这一页就能看到全局影响，比翻代码快十倍。

第三，新组件开发时，先问一句"这个能不能用现有的字号和间距组合拼出来"。九成情况下能。剩下那一成确实需要新值的，才允许扩展变量——并且要写注释说明为什么现有值不够用。这个流程能有效防止令牌无限膨胀。

我自己的体会是，排版规范真正的价值不在于"统一好看"，而在于降低决策成本。当你不需要每次都思考"这里该给多少间距"，而是直接从 4、8、12、16、24、32、48、64 里挑一个，做页面的速度会快很多，而且做出来的东西质量下限被抬高了。至于上限，那还是得靠审美和反复对比，工具帮不上忙。