打开12306的网页订票页面，车次列表里的字体字体突然变得又粗又扁，像被横向拉伸过一样。异常数字“G”和“D”挤在一起，网页出发时间“08:25”的字体冒号几乎贴到了前一位数字上。这不是异常我第一次遇到这种情况，但每次碰到都让人心里咯噔一下——毕竟买票这事，网页差一个字都可能看错车次。字体

我用的异常浏览器是Chrome，版本不算旧，网页系统是字体Windows 11。按F12打开开发者工具，异常查看网络请求，网页发现字体文件加载正常，字体没有404。异常问题出在CSS上。12306的样式表里定义了一组自定义字体，通过@font-face引入，字体文件是woff2格式。正常情况下，浏览器会优先使用这套字体来渲染车次、时间、座位类型等关键信息。但有时候，这套字体没生效，浏览器回退到了系统默认的宋体或微软雅黑，而12306的布局又是按自定义字体的字宽来设计的，结果就是文字被挤压或拉伸，行高错乱。

具体来说，车次列表那一栏的宽度是固定的。自定义字体里，每个数字和字母的宽度都经过精确计算，刚好能塞进那个格子。一旦回退到系统字体，数字“1”比自定义字体里的“1”宽了不少，于是“G1234”这种车次就会溢出，或者被强制压缩。更麻烦的是时间列，“08:25”里的冒号在系统字体下占位更宽，导致整个时间串换行或者被截断。我就亲眼见过有人因为字体渲染问题，把“12:05”看成了“12:45”，差点买错票。

为什么字体文件会加载失败？我抓了几次包，发现有两种情况。一种是网络问题，12306的字体文件放在CDN上，某些地区或者某些时段CDN节点响应慢，字体文件加载超时，浏览器等不及就直接用默认字体渲染了。另一种更隐蔽——浏览器缓存。12306的字体文件带版本号，比如font.woff2?v=20231201。如果浏览器缓存了旧版本，而服务端更新了字体文件但没改版本号，浏览器就会继续用旧字体，新页面布局对不上，字体就乱了。我遇到过一回，强制刷新（Ctrl+F5）之后字体立刻恢复正常，说明就是缓存问题。

还有个小细节：12306的页面用了font-display: swap。这个CSS属性告诉浏览器，先用系统字体把文字显示出来，等自定义字体加载完了再替换。想法是好的，避免白屏。但swap模式下，如果自定义字体加载失败或者特别慢，页面就会一直用系统字体渲染，而布局已经按自定义字体的尺寸算好了，结果就是文字错位。改成font-display: block会先隐藏文字，等字体加载完再显示，但那样又会有短暂的白块。12306选了swap，牺牲了字体一致性来换加载速度。

普通用户遇到这种情况怎么办？最简单的办法是强制刷新，Ctrl+F5或者Shift+F5，绕开缓存重新拉取所有资源。如果还不行，换个浏览器试试，Edge和Firefox对字体回退的处理略有不同，有时候能歪打正着。再不行就清一下浏览器缓存，特别是“缓存的图片和文件”那一项。我试过用无痕模式打开12306，字体问题从来没出现过，因为无痕模式不读本地缓存。所以如果你经常遇到字体异常，不妨用无痕窗口买票。

12306这边其实可以做得更好。给字体文件加个内容哈希，比如font.abc123.woff2，内容变了哈希就变，浏览器缓存自然失效。或者干脆把关键数字用SVG图片代替，虽然土但绝对稳定。再不然，把布局改成弹性宽度，别把列宽写死，系统字体宽一点也能自适应。不过话说回来，12306的流量那么大，任何改动都得慎之又慎，字体这种小事，估计排不上优先级。只能我们自己多留个心眼，买票前先确认一下字体显示是否正常，别因为一个冒号看错时间。