聊pre这个标签我估计不少同行的态度是“知道但没认真研究过”。它是 HTML 里最早一批规范化的元素每天在文档站、后台管理界面、日志查看器、在线编辑器里被使用但真正把它用对、用稳的人并不多。我见过上线后被长代码行撑破布局的详情页也见过复制按钮复制出来全是行号的事故还见过因为一个换行符对不齐导致运维照着文档敲命令敲错的情况。这篇就把pre预格式文本这件事讲清楚它到底负责什么、浏览器给它加了哪些默认样式、white-space的几个取值怎么选、从源码到渲染中间有哪些容易出错的地方以及怎么搭一套能上线、能复制、能滚动的预格式文本渲染方案。不管你是刚学 HTML 的新手还是写过几年业务代码、正在处理富文本或文档渲染的老手下面这些内容都能直接拿去用。1. 先把pre摆正位置它到底管什么、不管什么1.1 浏览器默认样式拆解两个属性各司其职理解pre最快的方式是把浏览器的默认样式表拆开看。绝大多数浏览器给pre只加了三样东西white-space: pre、等宽字体族、一点点外边距。前两个才是关键而且它们是互相独立的——这一点很多人没意识到导致在使用时经常把两件事混为一谈。white-space: pre干的事情是源码里的连续空格全部原样保留源码里的换行符原样渲染成换行并且不自动换行。也就是说一行有多长它就多长超出容器就溢出。等宽字体族负责的是“每个字符占据相同的水平宽度”这样你用空格拼出来的对齐关系才能在屏幕上成立。把这两个拆开来看你会发现单独用哪一个都是合法的而且各自有明确的场景。只想让一段文字用等宽字体显示比如展示一段订单号、密钥串、机器码完全不需要保留空白那就只加font-family: monospace不要碰white-space。反过来想让一段文本保留作者写的换行、但不需要等宽比如一首诗、一段地址、一段从聊天框里粘出来的多行文本那就只加white-space: pre-wrap字体保持默认。提示pre的默认margin是1em 0上下都有间距且这个1em是基于pre自身字号计算的。如果你把pre的字号改成 13px外边距也跟着变成 13px。这一点在混排场景下经常造成“怎么间距和别的段落不一样”的困惑。我个人的经验是在项目里永远先把pre的margin归零然后由外层容器或者统一的排版类来控制间距。原因很实际pre的默认 margin 会随着字号变化当你的代码块字号和小节标题字号不一致时视觉节奏就乱了。统一归零之后间距只有一个来源改起来也只需要改一处。1.2 语义层面的取舍什么时候该用pre什么时候只是想要等宽字pre在语义上表达的是“这段内容的排版是作者刻意安排的这些空格和换行是有意义的信息不能丢”。这句话听着抽象落到具体判断上其实很简单如果你把这段内容里的空格和换行全部折叠掉信息会不会丢失会丢失就该用pre不会丢失就只是视觉上想要等宽效果。按这个标准代码片段、配置文件、命令行输出、日志、ASCII 流程图、目录树、代码对比、数学公式的纯文本排版都属于该用pre的场景。而像订单号、哈希值、短标识符折叠空白不影响任何信息只是希望字符宽度一致便于人工比对那用 CSS 控制等宽就够了。反面案例里最典型的是拿pre做页面布局。早年没有 Flexbox 和 Grid 的时候确实有人用pre加一堆空格把内容“摆”到指定位置。这种做法的维护成本很高字号一改、字体一换、屏幕一窄整个布局就会崩而且语义上完全错误——屏幕阅读器会把那一堆空格逐个读出来。现在没有任何理由再这么干。还有一个容易被忽略的取舍表格化的数据该用table而不是pre。我见过有人为了让对齐“绝对精确”把本来应该是表格的数据用空格拼成pre。视觉上是齐了但语义丢了无障碍工具读不出来也没法做排序。对齐需求用table-layout: fixed加text-align就能解决没必要退回到纯文本。1.3pre与code、samp、kbd的搭配关系最常见的组合是precode嵌套。这两个元素分工很清楚pre负责排版层面“保留空白”code负责语义层面“这是一段计算机代码”。单独用code是行内代码比如在正文里提到Array.prototype.map这种。当代码超过一行、需要保留缩进的时候就用pre包起来。这个嵌套顺序不能反。code里再包pre在语法上虽然能解析但语义很奇怪而且code默认是行内元素里面塞一个块级的pre会让排版行为变得不可预期。正确的是pre在外、code在内。除了code还有两个相关元素值得记住samp表示程序的输出结果kbd表示用户的键盘输入。它们经常和pre一起出现比如展示一段终端操作记录precodekbdnpm run build/kbd sampBuild completed in 3.42s/samp/code/pre这种写法在语义上非常清晰哪部分是用户敲的哪部分是程序吐出来的。实际项目里未必每个团队都这么讲究但至少要知道这几个元素是存在的别一律用span加类名糊过去。2. 四个white-space值的实测对比与选型逻辑2.1 用一张表把pre/pre-wrap/pre-line/normal的差异说透white-space这个属性看起来选项多其实只要抓住三个维度就能理清空格折不折叠、源码换行符认不认、超长行自动不自动折。我把几个常用取值整理成表这是我每次带新人都要讲一遍的东西取值连续空格源码换行符超长行自动换行典型用途normal折叠成一个忽略是普通正文nowrap折叠成一个忽略否单行省略号文本pre原样保留保留否短代码、必须精确对齐的文本pre-wrap原样保留保留是长代码、终端日志、移动端首选pre-line折叠成一个保留是用户输入的留言、多行描述break-spaces原样保留保留是且行尾空格也占位需要严格复现排版的艺术文本这里有几个点值得单独拎出来说。pre和pre-wrap的差别只有“超长行是否自动折”但就是这一条决定了移动端体验的生死。pre-line是最容易被误用的一个它保留换行、但会把连续空格折叠成一个所以拿来展示代码会丢失所有缩进——看起来每行内容都在换行但缩进层次全没了代码结构反而更难读。break-spaces是相对新的取值很多人没注意过。它和pre-wrap的区别在于pre-wrap在计算折行时行尾的一串空格会被“悬挂”处理不占用行末宽度而break-spaces让每个空格都实实在在占位并且允许在空格处断行。什么时候需要它比如你用空格拼了一个 ASCII 表格或者字符画希望每一行的宽度绝对一致用break-spaces更稳。2.2 为什么长代码行是pre最大的事故源实际算一下很多人以为代码块溢出的问题是“看起来不美观”实际上它直接导致功能不可用。我们来算一笔账。假设移动端视口宽度 375px代码块的padding是左右各 16px那么可用内容宽度是 343px。等宽字体在 13px 字号下单个字符的水平宽度大约是0.6em也就是 7.8px 左右不同字体略有差异这里取常见值。那么一行能容纳的字符数是343 ÷ 7.8 ≈ 44 个字符44 个字符是什么概念一个稍长的变量名加上几个点号就快到了。而实际业务里的配置行、SQL 语句、长 URL、JSON 里嵌套的对象随便一行 80 到 120 个字符很正常。也就是说在手机上超过一半的行需要横向滚动才能看全。横向滚动本身不是罪问题在于它和页面的纵向滚动是冲突的。手指在代码块上竖直滑动浏览器有时会判断成横向滚动意图导致页面卡住不动更糟的是滚动到代码块尽头继续滑滚动会“传染”给父容器整个页面突然跳一下。这个体验非常糟糕用户说不清哪里不对但就是觉得页面很别扭。所以我的选型规则很明确代码块的默认值用pre-wrap只在明确知道内容行宽可控时才用pre。这个默认值的代价是长行会被折行视觉上缩进层次会断掉但换来的是移动端不需要横向滚动整体体验更稳。如果确实需要精确对齐比如展示对齐的表格型日志、字符画再用pre配合横向滚动并且做好滚动容器的处理。2.3 我的默认配置模板pre 全局兜底我把线上项目里用得最稳的一套基础样式贴出来这段代码几乎每个项目都会带一份pre { margin: 0; padding: 16px 20px; font-family: ui-monospace, SFMono-Regular, monospace; font-size: 13px; line-height: 1.7; tab-size: 4; white-space: pre-wrap; overflow-wrap: anywhere; overflow-x: auto; overscroll-behavior-x: contain; background: #f7f8fa; border-radius: 6px; color: #24292f; } pre code { font: inherit; white-space: inherit; background: none; padding: 0; }逐条解释一下设计意图。ui-monospace是系统自带的等宽字体关键字能拿到当前平台最合适的等宽字体后面跟两个具体字体做兜底最后以monospace收尾保证任何环境下都有等宽效果。line-height给到 1.7 而不是 1.5是因为代码行和行之间如果没有足够留白密集的括号和分号会糊成一片读起来很累。tab-size: 4是为了让源码里的制表符按 4 个字符宽度渲染。有些浏览器默认是 8导致同样一份代码在不同环境下缩进宽度差一倍这个问题后面还会细说。overflow-wrap: anywhere配合pre-wrap使用意义是当一行里出现一个特别长的、没有空格的连续串比如超长的 URL、Base64 串、压缩后的 JSONpre-wrap默认只在空格处折行遇到这种串就会溢出。加上anywhere之后允许在任意字符间断开保证绝不溢出。这是个兜底正常代码用不上但一旦遇到就是救命。overscroll-behavior-x: contain的作用是阻止横向滚动的“滚动链”传导当代码块横向滚到尽头继续滑动不会带动页面或者父容器。这个属性在一些浏览器上支持情况不完全一致但作为增强项没有副作用。3. 从 HTML 源码到渲染pre的解析细节与踩坑3.1 那个“吃掉一个换行”的规范行为这是pre最容易被误解的一个特性。HTML 解析规范里明确规定pre开始标签之后紧跟的单个换行符会被解析器忽略。也就是说下面这段代码pre 第一行 第二行/pre渲染出来的第一行是“第一行”前面没有空行尽管源码里pre和“第一行”之间确实有一个换行。这个规则不是 bug而是规范为了照顾实际写作习惯做的补偿。因为在手写 HTML 的时候为了让源码看起来整洁几乎所有人都会在pre后面换行再写内容。如果这个换行被原样保留每个代码块顶部都会多一个空白行非常难看。规范替你把这个换行抹掉了。坑在哪里坑在你有时候真的想要开头有一个空行。比如你要展示的是一段内容本身就带前置空行的文本或者你在做差异对比、需要严格对齐行号。这时候写一个换行不够得写两个。或者用字符引用#10;代替字面换行——字符引用不会被这条规则吞掉。更隐蔽的坑在服务端渲染。假设后端把一段文本 trim 过再塞进模板pre{{ content }}/pre这种写法trim 已经去掉了首尾换行问题不大。但如果后端逻辑是先拼接模板字符串再输出拼接过程中多了一个换行那这个换行会被吞反而“看起来正常”一旦某天拼接逻辑改了少了一个换行多余的空白行就冒出来了排查起来很费劲。还有一条必须记住这条规则只作用于 HTML 解析阶段。如果你是用脚本给pre设置textContent那这个“吞换行”的行为不会发生设置什么就是什么。这也是为什么前后端渲染同一个文本偶尔会出现一行差异的原因。3.2 制表符宽度tab-size与缩进对齐代码里的缩进有两种来源空格和制表符。空格是确定的一个空格就是一个字符宽度。制表符是个“相对宽度”的概念它表示“对齐到下一个制表位”而这个制表位间隔在不同环境下可能是 4、8也可能被主题覆盖。浏览器对tab-size的默认值并不完全统一常见的默认是 8。这意味着如果一份代码用制表符缩进在默认环境下会显得缩进特别宽。更麻烦的是混用一部分行用 4 个空格、一部分行用 1 个制表符视觉宽度能不能对上完全取决于tab-size的值。我的做法很简单粗暴pre上统一写tab-size: 4同时在项目规范里要求所有代码类内容一律用空格缩进禁止制表符。只靠 CSS 解决不了混用问题必须从源头上统一。如果内容来自用户输入或者第三方那就得在服务端做一次规范化把制表符按固定列宽展开成空格。这一步看着多余但能省掉后面无穷的对齐争议。还有一种情况要留意文本经过某些编辑器或格式化工具处理时制表符会被自动替换成空格或者反过来空格被压成制表符。如果这份内容是需要精确对齐的比如字符画任何一次“自动格式化”都是灾难。这类内容我一般建议直接以纯文本文件形式存放渲染时原样输出中间不做任何处理。3.3 HTML 实体转义为什么手工写pre一定会翻车pre里的内容依然要经过 HTML 解析器。这意味着如果你要展示的是div classbox直接写进去会被当成真的 div 标签解析渲染结果里这段字符就消失了或者变成一个空的盒子。正确的写法是转义尖括号lt;div classboxgt;。同时本身也要转义成amp;否则lt;这个字面量想显示成lt;就做不到——解析器会先把lt;变成然后再走一轮逻辑结果就乱了。手工写这些转义写十个还行写一百个必然出错。所以正确的做法是让模板引擎或者服务端逻辑自动处理。主流模板引擎默认都会对变量输出做 HTML 转义pre{{ code }}/pre这种写法就能得到正确结果。但有两个例外要警惕一是有人为了“保留格式”手动关了自动转义那就等于把所有输入都当成 HTML安全性和正确性双双出问题二是内容经过了富文本编辑器的处理编辑器可能已经做过一层转义你再转一次就会变成双重转义用户看到的是amp;lt;这种字符串。我遇到过最典型的一个案例是后台评论功能里支持代码块用户输入T泛型写法保存后显示成了空白。排查下来是前端提交时做了一次转义后端入库前又做了一次解码渲染时再转义中间某一步把T当成标签处理掉了。结论是转义这件事只能在一个明确的位置做一次并且要有测试用例覆盖。别指望靠“多转几次更安全”来兜底那只会制造更隐蔽的 bug。3.4 空白、nbsp;的误用与不可见字符新手在pre里最常犯的错是怕空格“不够”于是用nbsp;来凑。这个做法在pre里完全没必要因为空格本来就是原样保留的更糟的是nbsp;渲染出来的是不换行空格U00A0它和普通空格U0020是两个不同字符。用户在页面上选中、复制拿到的是 U00A0粘到别处可能报错、可能被当成非法字符、可能看起来一样但比对失败。我见过一个典型的实际问题页面上的命令行示例用nbsp;做了缩进运维人员照着复制粘贴执行命令直接报“找不到命令”。原因是复制出来的字符中间混了不换行空格。这种 bug 用户根本想不到开发也很难复现因为在自己电脑上可能表现正常。同样的隐患还包括全角空格、零宽字符、从网页复制来的软连字符。这些字符肉眼不可见或者看起来和普通空格一模一样但对程序来说完全不同。处理原则是渲染代码或命令的容器入口处就应该做字符规范化把 U00A0 换成普通空格删掉零宽字符全角空格换成半角。这个处理放在服务端渲染之前做一次比事后排查成本低得多。还有一个更隐蔽的问题部分编辑器和代码托管工具会默认去掉行尾空格。而如果在做表格对齐时依赖了行尾空格这些空格被删掉后对齐就崩了。所以我的建议是需要对齐的地方不要依赖行尾空格尽量用表格元素或者 CSS 布局来实现。4. 实操搭一套可复制、能上线的预格式文本渲染方案4.1 结构化 HTML 骨架与最小 CSS先把结构定下来。我推荐的结构是外层一个容器负责视觉样式和滚动里面一个pre再里面一个code代码内容全部在code里div classcode-block>.code-block { border: 1px solid #e3e6ea; border-radius: 8px; overflow: hidden; background: #f7f8fa; } .code-block__head { display: flex; align-items: center; justify-content: space-between; padding: 6px 12px; font-size: 12px; background: #eef0f3; border-bottom: 1px solid #e3e6ea; } .code-block__pre { margin: 0; padding: 14px 16px; font-size: 13px; line-height: 1.7; tab-size: 4; white-space: pre-wrap; overflow-wrap: anywhere; overflow-x: auto; overscroll-behavior-x: contain; } .code-block__pre code { font-family: inherit; white-space: inherit; background: none; padding: 0; }注意code上写了white-space: inherit。这一步很容易漏。code元素自身在某些样式重置里会带上white-space: nowrap之类的东西一旦继承链断了pre上的pre-wrap到不了真正承载文本的元素长行还是会溢出。显式继承一下代价为零。还有一个细节.code-block用了overflow: hidden配合圆角。这会让滚动条出现在内层的pre上圆角不会被滚动条切掉视觉上干净很多。但要注意overflow: hidden不要加到pre上否则超长内容会被直接裁掉而不是滚动用户就永远看不到后面的内容了。4.2 长行、滚动条与移动端的处理如果内容类型决定了必须用white-space: pre比如对齐的日志、字符画、需要精确缩进的配置文件那就要认真处理滚动容器。第一件事是让容器可聚焦。一个可横向滚动的区域如果只能用鼠标拖拽或者触屏滑动纯键盘用户就没法操作。给滚动容器加上tabindex0它就能通过 Tab 键聚焦接着用方向键滚动。同时补上roleregion和aria-label让屏幕阅读器知道这是一块独立区域而不是莫名其妙的一串内容pre tabindex0 roleregion aria-label配置示例可横向滚动code.../code/pre第二件事是给出“还有内容”的视觉提示。默认滚动条在部分系统上会被设置成自动隐藏用户根本不知道右边还有内容。一个常用做法是在容器两侧加渐变遮罩滚动到边缘时遮罩淡出。实现上可以用background-attachment: local配合两层背景也可以简单地常驻一个淡渐变。我倾向常驻渐变因为在移动端判断滚动位置的兼容性处理比较琐碎而常驻渐变的视觉成本很低。第三件事是控制最小宽度。有些场景你其实不希望代码块被压得太窄——比如对比代码差异宽度太小反而看不懂。这种情况下可以给pre加min-width配合外层overflow-x: auto让整个块在窄屏上横向滚动而不是把每行都折成碎片。这个取舍没有标准答案我的判断依据是如果折行后每个逻辑单位的连贯性被破坏比如一行一个完整的语句就让它横向滚动如果折行后依然能读比如一段自然语言日志就让它折。4.3 复制按钮与选区行为复制按钮看起来简单真做起来坑不少。核心逻辑其实只有几行document.querySelectorAll([data-copy-target]).forEach((btn) { btn.addEventListener(click, async () { const target document.getElementById(btn.dataset.copyTarget); if (!target) return; const text (target.textContent || ).replace(/\n$/, ); try { await navigator.clipboard.writeText(text); btn.textContent 已复制; setTimeout(() { btn.textContent 复制; }, 1500); } catch (err) { fallbackCopy(text); btn.textContent 已复制; setTimeout(() { btn.textContent 复制; }, 1500); } }); }); function fallbackCopy(text) { const ta document.createElement(textarea); ta.value text; ta.setAttribute(readonly, ); ta.style.position fixed; ta.style.top -9999px; document.body.appendChild(ta); ta.select(); document.execCommand(copy); document.body.removeChild(ta); }几个细节值得展开。第一末尾的换行要去掉。HTML 源码里code结束标签前通常有一个换行textContent会把它带上复制出来的文本结尾多一个空行粘到终端里可能会直接触发执行或者多一个空行体验很差。用正则把末尾连续换行删掉是稳妥做法。第二剪贴板接口在部分环境下不可用必须准备降级方案。降级方案用临时 textarea 加上旧的复制命令虽然这个命令已经在被淘汰但在过渡期仍然是最可靠的兜底。注意 textarea 要设置readonly并移出可视区否则在移动端会弹出键盘、页面会跳。第三也是最关键的一点如果做了行号或者语法高亮复制源必须是原始文本而不是渲染后的 DOM 文本。语法高亮一般只插入spantextContent取出来还是原文问题不大。但如果行号是插在code内部的元素textContent就会把行号数字一起带进去。我见过复制出来每行前面都带“12 34 56”的事故就是行号方案没选对。第四选区行为要处理一下。用户在代码块里拖选时如果跨行选择经常会不小心选到行号或者复制按钮。可以在行号和按钮上加user-select: none让它们不参与选区。4.4 语法高亮的接入顺序与常见冲突高亮的接入顺序必须想清楚先做转义再做高亮。转义是安全边界保证任何用户输入都不会被当成 HTML 执行高亮是视觉增强它读的是已经安全的文本输出的是自己构造的span结构。如果顺序反了先高亮再转义那高亮生成的span标签会被一并转义页面上就会出现一堆标签文本。如果干脆不转义直接高亮那就是把未经处理的用户输入塞进innerHTML安全问题立刻出现。高亮脚本通常靠关键字匹配生成 DOM它自己会处理文本与标签的转换。这里有个隐藏风险高亮脚本对某些字符的处理不一定和浏览器完全一致比如连续的空格、制表符、行尾空白。我在实际项目里遇到过一份缩进用了混合制表符的内容高亮后视觉缩进变了但textContent取出来还是原样导致“看到的”和“复制的”不一致。后来统一在入口把所有制表符展开成空格这个问题就消失了。另一个冲突点是样式覆盖。高亮脚本会给你一堆类名这些类名通常只设置了颜色。如果你的pre code里写了font: inherit之类的规则可能会把高亮脚本设置的字体样式一并覆盖掉导致某些语言的斜体注释变成正体。解决办法是把你自己的code样式规则写得窄一点只控制布局相关的属性颜色和字体样式留给高亮主题。4.5 行号方案伪元素、表格、DOM 三种做法的取舍行号是代码块里最容易做出问题的功能。我把常见做法列出来对比方案实现要点复制安全折行表现适用场景伪元素计数器每行拆成块级元素用::beforecounter安全伪元素内容不进textContent折行后行号只标在第一行短代码、行数固定独立行号列左侧一列数字右侧代码区两区同步滚动安全行号不在代码 DOM 内折行不影响行号对齐中等长度代码DOM 插入数字脚本在每行前插入span不安全除非过滤需要额外处理快速原型伪元素计数器是最简洁的但有个硬伤折行的时候一个逻辑行被折成三行物理行行号只出现在第一行的位置视觉上会显得行号和代码错位。如果你的代码块用pre-wrap这个方案就不太合适。独立行号列解决了折行问题。实现上用一个 flex 或者 grid 容器左边是行号列右边是代码区。难点在于滚动同步代码区横向滚动时行号列不能跟着动纵向滚动时两者必须一起动。我的做法是把纵向滚动交给外层容器代码区只负责横向滚动这样行号列和外层容器一起纵向移动天然同步不需要写任何监听代码。这个思路比“监听 scroll 事件同步两侧”简单太多而且不会有性能问题。DOM 插入数字这个方案我一般不推荐除非只是内部工具。因为它污染了代码区 DOM复制时必须额外过滤而且一旦代码内容里有特殊结构比如嵌套的span清理逻辑就会变得很脆弱。行号本质上是个视觉辅助不该混进内容里。还有一个折中方案值得提干脆不做行号。很多文档站的代码块只有十几行读者根本不需要行号定位。我在自己的项目里就长期不加行号只在特别长的日志展示里才加。少一个功能就少一堆问题这个投入产出比很划算。5. 常见问题与排查技巧实录5.1 一份速查表我把这些年遇到的pre相关问题整理成表排查时可以直接对照现象找原因现象可能原因排查方式修复方向开头莫名多一个空行内容后有多个换行或脚本设置textContent时带上打印textContent的字符码裁剪首尾换行或统一入口处理缩进参差不齐制表符与空格混用tab-size不一致把不可见字符显示出来检查统一展开为空格设tab-size长行撑破容器white-space: pre且未设横向滚动检查计算宽度与行字符数改pre-wrap或加overflow-x复制结果多出行号行号插在代码 DOM 内检查textContent结构换伪元素或独立列方案复制结果多出空行结束标签前的换行未清理打印复制文本末尾字符正则清理末尾换行代码里的标签消失尖括号未转义被当标签解析查看源码与渲染 DOM模板层统一自动转义显示成双重转义字符转义执行了两次搜索amp;lt;之类字符串收敛到单一转义点空档被替换成奇怪字符使用了不换行空格或全角空格用字符码检查入口做字符规范化手机端页面滑动卡顿横向滚动传导到页面观察滚动边界行为加overscroll-behavior-x键盘无法滚动代码块滚动容器不可聚焦按 Tab 键测试加tabindex与aria-label5.2 几个容易被误判的案例有个问题我印象很深。某次页面上的代码块在桌面端看着完全正常到了移动端就变成一条极窄的长条几乎只有一两个字符宽。第一反应是宽度计算错了查了半天width、max-width、flex都没问题。最后发现是父容器用了 flex 布局而pre作为 flex 子项的默认min-width是auto它会根据内容撑开到内容宽度但同时flex-shrink又把它压回去了两边一打架宽度就变成很小。解决办法是给pre加min-width: 0。这个坑的启发是pre在 flex 或 grid 容器里表现会和平常不一样。它的内容尺寸是固定的不会像普通文本那样自动收缩。凡是把代码块放进弹性布局的地方都要检查min-width和overflow的配合。第二个案例是多行文本的末尾换行问题。用户提交一段留言前端用pre-line展示。用户发现在输入框里敲了两个连续换行展示出来变成一个。原因是pre-line保留每个换行符但连续两个换行渲染出来是两个空行间距视觉上好像没区别——实际上不是丢了而是行高的视觉密度让人误判。这类问题的处理方式是加上显式的段落分隔样式或者干脆改成pre-wrap并保留全部空白让视觉表现和输入完全一致。第三个案例和打印有关。代码块在屏幕上用横向滚动没问题但用户打印的时候横向滚动的部分全部被裁掉打印出来只剩左边一截。这类问题必须用打印媒体查询单独处理media print { pre { white-space: pre-wrap; overflow-x: visible; border: 1px solid #ccc; page-break-inside: avoid; } }page-break-inside: avoid是为了尽量不让代码块被分页切在两页中间读起来会舒服很多。这个属性在不同环境下的支持度有差异但作为增强项没有副作用。5.3 无障碍场景的补充pre对屏幕阅读器的表现有个特点它会逐字符朗读包括标点符号和缩进空格。这在代码场景下是必要的——用户需要知道每一层括号在哪。但如果代码块很长逐字符朗读会非常漫长。比较务实的处理方式有两个。一是给代码块提供一个简短的可访问名称让用户先知道这是什么再决定要不要细读。二是对于超过一定长度的代码考虑提供一个“跳过长代码”的锚点或者在旁边配一段自然语言的说明把关键信息用普通文本讲一遍。这不是让pre变得可有可无而是承认它的朗读成本用辅助手段弥补。还有一个细节pre的横向滚动容器加上tabindex0之后键盘 Tab 序列里会多出一个停留点。这个停留点本身是有价值的可以用方向键滚动看完整内容但如果页面上有二十个代码块Tab 键就会被这二十个停留点打断导航体验变差。这种场景下我一般只给“确实需要横向滚动”的代码块加tabindex短代码块不加把数量控制在合理范围内。关于pre的默认样式重置还有一条经验可以分享。新项目初始化样式的时候很多人会写* { margin: 0; padding: 0; }这会把pre的默认间距也清掉然后靠自己的类名重新加。这个做法本身没问题但它顺带着把pre的white-space: pre也一起忽略了——因为很多人重置时会顺手写* { white-space: normal; }或者在有 reset 的情况下给pre设了别的值。我见过最离谱的一次是全局样式表里有一条pre { white-space: pre-line; }据说是“为了移动端不溢出”结果整个文档站的代码缩进全部消失谁都没看出来是什么时候坏的。这类全局性的样式覆盖最好在评审时专门盯一下测试用例里也应该有一条“代码块缩进是否保留”的检查项。再补一个容易被忽视的点pre里的链接。如果代码或输出文本里包含 URL有些渲染逻辑会自动转成可点击的链接。这在展示代码时是灾难——本来应该原样显示的字符串变成了可点击元素复制的时候拿到的是链接文本没错但如果链接被加了下划线、颜色代码块的视觉一致性就破坏了。我的做法是代码块内一律不自动链接化只有正文里的纯文本才做自动链接。这个规则要写在渲染配置里别依赖人工判断。最后说一个我自己的使用习惯。凡是写pre的地方我都会在边上顺手加一条注释标明这段代码是不是需要精确对齐、为什么选pre还是pre-wrap。这看着像是多余的但半年后别人或者自己改样式时这条注释能直接说明当时的取舍逻辑比翻提交记录快得多。代码块这类“看起来只是样式”的东西实际承载了很多隐式的信息约束把约束写下来是成本最低的维护手段。