做前端或者做文档排版的人几乎都会在某个时刻被同一个问题绊住这一段文字到底该用衬线字体还是无衬线字体界面上那行标题是不是该换成有“脚”的那一款长文档正文用宋体看着累还是用黑体看着累我最早接触衬线字体serif和无衬线字体sans-serif这个概念的时候是在调一份内网文档站的主题样式改了一晚上最后发现改来改去都是在跟这两个大类打交道。后来做后台系统、做官网、做出版级的电子文档甚至做 PPT这个问题反复出现慢慢也就攒下了一套自己的判断标准。这篇内容想解决的就是一个很具体的问题在真实的项目里怎么在衬线和无衬线之间做出不后悔的选择并且把它落到可执行的参数上。它不是字体史科普也不打算把排版理论讲全而是把这两类字体在结构、渲染、选型、参数、工程落地这几个层面上的差异摊开说清楚附带可以直接抄的 CSS 和踩过的坑。不管你是刚开始接触排版的前端还是做文档、做设计、写公众号的人看完至少能少纠结几次。1. 先把概念掰开serif 和 sans-serif 到底差在哪1.1 从笔画末端的“脚”说起衬线指的是字母主干笔画末端那些额外伸出来的装饰性短笔画中文里常叫“衬线”“装饰角”或者干脆叫“脚”。比如大写字母 I 的顶部和底部各有一横那就是衬线小写字母 n 的竖画顶部会往一侧撇出一小段那也是衬线。这类字体的源头是手写工具留下的痕迹——笔尖在笔画起收处的自然停顿、压笔、回锋被后来的铸字工艺保留并规范化最终固化成了形态。这个“脚”带来的直接影响是笔画末端形成了一个明确的收束节点。人眼在扫读一行文字时实际上不是在逐字识别而是靠字与字之间形成的轮廓节奏在快速跳跃。衬线的存在让每个字母的视觉边界更清楚行与行之间的水平引导线也更强。这是衬线字体被长期用于正文排版的底层原因跟美感关系不大跟阅读时的眼球运动路径关系很大。无衬线就是把这些末端装饰全部去掉只留主干。笔画粗细趋于均匀字形轮廓更接近几何形状。它的视觉特征可以概括为三个词干净、均质、边界模糊。干净和均质是优点边界模糊是代价——当字与字之间缺少明确收束的时候连续文本的识别速度会比衬线略慢一些但这个差距在字号够大、行距够宽的时候会迅速收窄。1.2 无衬线不是“没设计”是另一套骨架很多人对无衬线有个误解觉得它就是衬线体把脚砍掉。其实两者的骨架差异远比想象中大。衬线字体因为要容纳装饰角通常 x 高度小写字母 x 的高度相对保守字碗字母内部围合出来的空白形状偏椭圆无衬线为了在无装饰的状态下依然保持辨识度往往会把 x 高度做大字碗做得更方、更开放。x 高度变大意味着同样字号下小写字母看起来更大这直接决定了两种字体的视觉字号是不等价的。注意同一字号下把一段衬线体换成无衬线体视觉上会显得“变大变粗”了这不是错觉是 x 高度差异导致的。做换字体对比的时候必须同时看实际渲染效果不能只信数值。这个差异在中文语境里更明显。中文的宋体衬线类和黑体无衬线类同样 16px黑体看起来会比宋体大一圈因为黑体笔画更粗、字面率更高、字怀字内部的空白被压缩。我做过一个很粗糙的对照同一段说明文字宋体 16px 换成黑体 16px整段会显得挤把黑体降到 15px 才回到差不多的视觉密度。这就是为什么很多设计师在宋黑混排时会给黑体单独设一个更小的字号。1.3 中文语境的对应关系别照搬西文结论西文排版里讨论 serif / sans-serif对应的是一整套字母形态学中文的对应关系没有那么严格但大类是清楚的宋体、仿宋、楷体属于带装饰笔画的一侧黑体、圆体、更现代的等线类属于无装饰的一侧。宋体的横细竖粗、横画末端的小三角、转折处的顿角本质上就是中文的衬线黑体则是笔画粗细一致、末端平直本质上就是中文的无衬线。这里有个非常容易踩的坑西文衬线体在高分屏上表现优雅很多人就顺势认为中文也该用宋体做界面正文。实测下来宋体在屏幕上的表现远比西文衬线体脆弱。原因是宋体的横画非常细在低像素密度下横画宽度往往不足一个像素渲染器只能靠抗锯齿去“猜”结果就是横画发虚、发灰整段文字像蒙了一层雾。所以中文的屏幕正文绝大多数情况下还是黑体更稳宋体更适合大字号标题、印刷输出或者高 PPI 的阅读场景。2. 为什么会长成这两副样子介质决定了形态2.1 手写工具留下的肌肉记忆衬线的形态不是某个设计师拍脑袋定的而是工具决定的。西方传统书写用的是平头笔或羽毛笔笔尖有固定的角度和宽度落笔、行笔、收笔的压感变化天然会产生粗细对比和末端的喇叭口。这批形态被早期的活字铸造师原样复刻进铅字里就成了今天衬线字体的基本语法。中文这边更典型。雕版印刷时代的刻工用刻刀在木板上走线横画顺着木纹容易刻细竖画逆着纹理阻力大、刻出来就粗横画收刀的时候自然带出一个三角楷书里那些提按顿挫的笔意到了刻本里就被简化成了一套几何化的装饰。宋体本质上是一套“用刀复刻毛笔”的产物它的横细竖粗、起收顿角全部来自手工时代的效率妥协。理解了这一层就明白为什么宋体看着“古雅”因为它的每一笔都带着工具的记忆。2.2 铅字时代衬线是默认值在金属活字的几百年里衬线基本是唯一的选项。原因很实际铅字是凸版印刷字面凸起压到纸上时边缘会轻微外溢衬线的装饰角恰好能在压印时形成更清晰的边界让字迹不容易糊在一起。另外衬线在低精度印刷下也能维持字符之间的分离度油墨扩散的时候装饰角相当于给每个字加了一圈缓冲。无衬线在那个年代是异类。它被做出来主要是为了在远距离、大字号的场景里用比如招牌、海报、车票。那个年代的无衬线设计粗糙字重单一光学尺寸没做调整拿去排正文简直是灾难。所以“衬线适合正文”这条经验其实是铅字时代的介质条件写进集体记忆的。2.3 屏幕像素逼出来的无衬线复兴转折点出现在屏幕普及之后。早期的显示器像素密度低到离谱一个字符可能只有十几个像素高衬线的装饰角在这个尺度下根本没地方画勉强画出来也是一坨黑点会把字形糊死。同时早期的字体渲染用的是 hinting 加灰度抗锯齿细笔画非常容易断。这种情况下笔画均匀、结构简单的无衬线字体成了唯一可行解。这也是为什么界面设计领域几乎是毫不犹豫地全面倒向无衬线。界面上的文字普遍是小字号、短文本、高密度的标签和按钮可读性的第一诉求是“快速识别轮廓”而不是“长时间连续阅读的舒适度”。无衬线的均质笔画在小字号下更稳定不会出现某个字的局部糊成黑块的情况。2.4 高密度屏回归之后老问题又回来了现在的设备动辄两倍三倍像素密度一个字符能分到几十上百个物理像素理论上衬线的所有细节都能完整渲染出来了。于是行业内开始出现一轮“衬线回潮”长文阅读类产品重新捡起衬线体做正文。但这次回潮没那么彻底因为屏幕阅读的行为模式跟纸质阅读不一样——人们更多是跳读、扫读、碎片化阅读衬线那点“引导视线沿行扫描”的优势在跳读场景下发挥不出来。我个人的判断是衬线的优势确实随着屏幕密度提升被重新释放了但它需要一整套配合条件才能兑现包括足够的字号、足够的行距、合适的对比度、以及内容本身确实是长文。少任何一条衬线都可能变成负担。3. 选型逻辑什么场景该用哪一种3.1 长文正文衬线的优势是有前提的衬线字体做长文正文的优势核心在于水平方向的视觉引导。衬线的装饰角在字词之间形成了隐性的水平线让眼睛在换行的时候能更准确地找回下一行的起始位置降低串行的概率。这个效果在行宽较大的时候尤其明显——一行超过 40 个汉字的时候无衬线正文的串行率会明显上升。但这个优势有三个硬前提。第一是字号不能太小低于 15px 的中文宋体基本没法看第二是行距必须给足衬线的细节多行距紧了会显得非常拥挤第三是对比度要够浅灰色文字配白底衬线的细横画会直接消失。这三个条件同时满足衬线的长文表现确实优于无衬线缺一个衬线就会反过来拖累阅读。3.2 界面与短文本无衬线的统治区界面上的一切——按钮、标签、导航、表单、提示、表格——默认都该用无衬线。理由很朴素这些文字的存在目的是“被快速找到并识别”不是“被慢慢读完”。无衬线的结构简单在小字号下轮廓稳定不会因为渲染精度不足而变形同时它的字重选择跨度大同一款字体可以从极细到极粗方便建立层级。还有个容易被忽略的点界面文字的字符集往往很杂中英文数字符号混在一起。无衬线字体的西文和数字部分通常设计得更规整跟中文混排时的视觉重量差距小。衬线字体里的西文斜体、数字跟中文宋体放一起经常会有“洋气过头”的割裂感需要额外调整。3.3 混排策略谁做标题、谁做正文混排是最高频的真实需求也是最容易搞砸的地方。常见的两种组合各有适用场景。第一种是衬线标题 无衬线正文。这是最稳的组合衬线标题负责气质和分量感无衬线正文负责清晰和效率。适合品牌感较强的官网、内容型产品的文章页、出版物配套的电子版。注意控制比例标题衬线的字重不要跳得太夸张否则会跟正文脱节。第二种是无衬线标题 衬线正文。这种组合在阅读类产品里更常见尤其适合内容本身篇幅长、需要长时间沉浸的场景。标题用无衬线是为了在同屏的信息层级里更突出正文用衬线是为了阅读舒适度。风险在于标题和正文的字重反差要处理好无衬线标题往往偏粗正文衬线偏细两者之间的过渡需要靠字号、颜色、间距去弥合。提示混排的成败往往不在字体本身而在“视觉重量是否衔接”。判断标准很简单——把页面缩小到 30%看标题和正文是不是还像同一个页面的东西如果标题像贴上去的就是没调好。3.4 一张对照表把结论钉死维度衬线宋体类无衬线黑体类字形特征笔画有粗细对比末端有装饰角笔画粗细均匀末端平直小字号屏幕表现细笔画易发虚需要高密度屏轮廓稳定16px 以下依然清晰长文连续阅读水平引导强串行率低需要更大行距补偿界面短文本不推荐密度一高就糊首选层级建立能力靠字重和字号跨度有限字重跨度大层级手段丰富气质倾向传统、正式、书面、克制现代、中性、工具感、直接典型场景书籍正文、长文专栏、正式文件、印刷品后台系统、App 界面、营销落地页、数据看板4. 参数联动字号、行高、字距不是独立的4.1 字号要和 x 高度对齐前面说过同字号下无衬线的视觉字号更大。做衬线到无衬线的切换时最稳妥的做法是先定视觉字号再反推字号数值。经验比例是这样的中文宋体换成黑体字号下调约 1px在 14~18px 区间内英文衬线换成无衬线字号下调约 0.5~1px或者直接按 x 高度的比值换算。换算方式很直接量出两款字体的 x 高度比值比如衬线体 x 高度 0.45em无衬线体 0.52em比值约 1.15那么无衬线的字号就该是衬线的 1/1.15 ≈ 0.87 倍。这个数在实际项目里很少精确算但知道有这么个比例调的时候心里有底。4.2 行高的计算逻辑行高不是拍出来的数字是从字号和字体的垂直度量推出来的。字体文件里有 ascender、descender、line gap 三个度量浏览器渲染line-height: normal的时候用的是这三者的组合而不同字体的这个组合值差别极大。这就是为什么同一个line-height: normal换字体之后行距会突然变化。我自己的做法是永远不用normal一律显式写数值长文正文按下面这个区间取/* 长文正文衬线体偏大无衬线体偏小 */ .article-serif { font-family: Georgia, Times New Roman, Songti SC, SimSun, serif; font-size: 17px; line-height: 1.75; /* 衬线细节多行距给足 */ } .article-sans { font-family: Helvetica Neue, Helvetica, Arial, PingFang SC, SimHei, sans-serif; font-size: 16px; line-height: 1.65; } /* 短文本区块行高收紧靠间距拉开层级 */ .title-sans { font-size: 28px; line-height: 1.25; letter-spacing: -0.01em; }具体的取值区间长文正文 1.6~1.8界面常规文本 1.4~1.55标题 1.1~1.3表格单元格 1.3~1.4。中文普遍比同场景西文再往上加 0.05~0.1因为汉字的字面率高同样的行高倍数下中文字与字之间的垂直间隙更小。4.3 字距的正负号规则字距letter-spacing有个反直觉的规律字号越大字距越该往负走字号越小字距越该往正走。原因是字体的默认字距是按常规字号调校的大字号下字形放大字与字之间的绝对空隙也被放大视觉上会显得松散需要收紧小字号下字的细节被压缩需要一点额外呼吸空间。英文的常用取值24px 以上的标题用 -0.01em 到 -0.02em12px 以下的辅助文字用 0.01em 到 0.02em中间区域保持 0。中文要谨慎得多汉字是方块字字距拉开会破坏词的整体感一般只在极小字号12px 以下时给 0.01em 左右的补偿正文一律不动。注意中文加 letter-spacing 之后标点符号尤其是全角逗号、句号、顿号的间距也会跟着变化容易出现标点后面空一大块的情况。做中文排版时字距调整要配合标点的视觉修正一起看不能只看汉字。4.4 中西文混排的字距修正中文和西文混排的时候两种语言的“字距感”是不一样的。中文每个字占满一个方块字与字之间天然有视觉间距西文的字母之间靠字偶距kerning微调紧凑得多。直接拼在一起中文会显得松散西文会显得拥挤整体节奏断裂。解决办法不是加字距而是给中西文交界处补间隙。CSS 里可以用text-spacing相关属性但目前兼容性还不统一更稳的做法是在构建阶段或者用脚本给中文和西文之间插入一个窄空格字符U2009约 1/4 汉字宽或者在样式里用word-spacing做轻微补偿。我在几个文档项目里都用过插空格这个方案效果比纯 CSS 稳代价是要处理富文本输入的情况。4.5 数字必须单独处理表格里的数字用衬线体的默认数字会变成“比例数字”——不同数字宽度不一样1 特别窄8 特别宽上下行对不齐看起来像筛子。这种场景必须切换到等宽数字。.table-cell { font-family: Georgia, Times New Roman, serif; font-variant-numeric: tabular-nums; /* 等宽数字 */ } /* 无衬线字体如果本身支持也可以用同一属性 */ .metric-value { font-family: Helvetica Neue, Arial, sans-serif; font-variant-numeric: tabular-nums; font-feature-settings: tnum 1; /* 兼容老写法的兜底 */ }这个细节在数据看板类项目里非常要命。我见过一个后台所有指标数字用衬线体渲染因为对不齐运营的同事一度以为数据有错位。5. 工程落地字体栈、加载和那堆没人写进文档的事5.1 字体栈的写法顺序字体栈的本质是一份回退清单顺序决定了优先级。写的时候要遵守三条规则先写具体字体后写通用族先写本机常见字体后写需要下载的字体中文字体要放在西文字体之后。:root { /* 衬线栈西文在前中文在后最后兜底通用族 */ --font-serif: Georgia, Times New Roman, Songti SC, SimSun, serif; /* 无衬线栈 */ --font-sans: Helvetica Neue, Helvetica, Arial, PingFang SC, Heiti SC, SimHei, system-ui, sans-serif; }为什么中文要放后面因为中文字体文件通常包含西文字形但设计质量普遍不如专业西文字体。把西文字体放前面浏览器在渲染西文字符时会优先用西文字体遇到汉字再回退到中文字体这样中西文各自用各自最优的字形。反过来写整段西文都会被中文字体里的西文字形接管通常更丑。提示system-ui放在无衬线栈的末尾很有用它会让浏览器直接取系统默认界面字体在移动端和桌面端都能拿到最“原生”的观感省掉一大堆适配。5.2 加载策略先看到字再看到对的字自定义字体必然带来加载问题。默认行为是字体没下载完之前文字不渲染FOIT用户会看到一片空白体验极差。现代做法是显式声明font-display。font-face { font-family: CustomSerif; src: url(/fonts/custom-serif.woff2) format(woff2); font-weight: 400; font-style: normal; font-display: swap; /* 先用回退字体渲染加载完再替换 */ unicode-range: U4E00-9FFF; /* 只对汉字生效西文走别的字体 */ }swap的代价是替换瞬间会有一次视觉跳变本来是无衬线突然变成衬线布局会抖。要缓解这个跳变可以用size-adjust和ascent-override这几个描述符去校准回退字体的度量让替换前后的行高和字宽尽量接近。font-face { font-family: FallbackSans; src: local(Arial); size-adjust: 96%; /* 横向缩放对齐字宽 */ ascent-override: 88%; descent-override: 12%; }这几个参数我是踩过坑才认真去看的。之前一个内容站的标题用自定义衬线体切换的瞬间会把整页往下顶 20 多像素用户能明显感觉到“跳”。加了度量校准之后跳动基本看不出来了。5.3 子集化中文字体不做子集就是灾难一款完整的简体中文字体动辄十几兆。直接丢到页面上等于给每个访客塞一个下载任务。必须做子集化——只保留页面实际用到的字符。静态页面可以在构建阶段扫描文本内容生成子集动态内容则按常用字表比如 3500 常用字 标点符号做基础子集再对超出的字符做运行时补加载。对衬线字体来说子集化还有一层额外收益衬线体的曲线复杂同样字符数下文件比无衬线大子集化之后的体积差异会更明显。5.4 可变字体一套文件解决字重问题衬线体做层级最难的地方是字重不够用常规体、粗体、细体往往只有两三档想做 550 这种中间值就得伪造。可变字体variable font能解决这个问题一个文件包含一个连续的字重轴font-weight可以填任意值。.headline { font-family: VarSerif, Georgia, serif; font-variation-settings: wght 560, opsz 32; }opsz是光学尺寸轴这个轴在衬线字体上价值极大——大字号时字形会变得更精致、笔画对比更强烈小字号时自动加粗笔画、放宽间距。这个逻辑本来就是活字时代的常规做法只是数字化之后丢失了一段时间现在又被捡回来了。6. 常见问题与排查实录实际项目里遇到的坑按频率从高到低排。现象大概率原因处理思路中文宋体横画发虚发灰低密度屏下细笔画不足 1 像素提升字号到 16px 以上或改用黑体换字体后整页行距突然变大变小用了line-height: normal字体垂直度量不同全部改成显式数值行高中西文混排节奏断裂中文松散西文紧凑交界处无间隙补偿交界处插窄空格或调word-spacing表格数字上下行对不齐用了比例数字开启tabular-nums字体替换瞬间页面跳动回退字体与目标字体度量差异大size-adjustascent-override校准某些字显示成方块子集里缺字或unicode-range划错检查子集字符表补常用字兜底标题看着“飘”字号大但字距没收紧大字号下给 -0.01em 到 -0.02em中文加字距后标点怪全角标点跟着位移中文正文不加字距只调字号和行距6.1 那个折腾我最久的问题宋体在移动端有个项目要做长文阅读页设计稿用的是宋体正文。桌面端效果很好到了移动端一部分设备上整段文字发灰、发虚像被水洗过。排查过程走了不少弯路先怀疑是字体文件问题换了两款情况依旧又怀疑是行高调了半天没用。最后才发现是渲染模式的问题在某些移动端的字体渲染策略下细笔画是被“均匀淡化”处理的而宋体的横画本来就细被这么一淡化就直接看不见了。解决方式是组合拳字号从 15px 提到 17px字重从 300 提到 400正文颜色从浅灰提到接近纯黑行高从 1.6 提到 1.8。四个参数一起动视觉效果才回到可接受的范围。这件事之后我就形成了一个习惯中文衬线体上屏幕永远先按最坏情况的渲染环境去调再往回优化而不是反过来。6.2 一个反直觉的发现衬线标题未必比无衬线高级刚入行的时候我有个执念觉得衬线等于“高级、有文化”凡是需要一点格调的地方就往上堆衬线。后来做了几个项目才反应过来衬线传递的是“传统、出版、正式”如果你的产品调性是轻快、工具化、效率优先衬线标题反而是错的。一个数据看板的顶部标题用衬线体看起来就像财务报表配了个诗集封面。判断方法很简单问自己这个页面希望用户是什么心态。如果是“慢慢读、认真看”衬线合适如果是“快速找到、马上操作”无衬线合适。这个判断比任何字体搭配理论都管用。6.3 几条实操心得不要在同一页面里用两款以上的正文字体。衬线正文和无衬线正文混着用除非有非常明确的区块划分否则读者会觉得页面散。混排时优先统一“视觉重量”而不是“字重数值”。衬线的 400 常常看起来比无衬线的 400 细需要靠字号和颜色去补。中文排版里行距的收益远大于字距。调不好就先把行距加 0.1比折腾字距有效得多。做字体回退测试的时候把系统字体全部禁用模拟自定义字体加载失败的情况看页面还能不能看。这个测试我每个项目都做抓出过好几次堆叠错乱。7. 最后聊聊我自己的取舍折腾这么些年我现在的默认策略已经比较固定了界面和后台上的一切用无衬线长文正文用衬线但只在高密度屏和足够字号的前提下启用标题按产品调性二选一绝不为气质牺牲可读性。中文场景下这个策略会更保守一点因为中文衬线在屏幕上的表现确实不如西文衬线稳需要更多的参数配合才敢用。还有一个越来越明显的趋势值得注意可变字体和光学尺寸轴的普及正在让“衬线还是无衬线”这个二选一变得没那么绝对。同一款可变字体可以在小字号时自动趋近无衬线的稳定感在大字号时释放衬线的细节。这条路走通了之后选型问题的重心会从“选哪一类”转移到“怎么把一款字体的参数区间用透”。我自己已经在两个项目里试过这套做法效果比换字体方案更可控代价是需要花时间把字体的轴调明白。如果你现在手头正卡在这个选择上我给的建议是先别纠结字体本身先把字号、行高、行宽、对比度这四个变量调到一个舒服的状态,再拿衬线和无衬线各跑一遍真实内容。很多时候纠结半天的问题会在真实文本铺上去的十分钟内自己给出答案。