别再用 <big> 标签调字体了，这坑填起来比修 Bug 还累

很多刚入行的前端同学，或者接手老旧项目的运维，常会在代码里撞见 <big> 标签。有时候是为了让标题醒目点，有时候是看到旧文档里这么写，便顺手照搬。直觉告诉你，这好像挺方便，不用去翻样式表，直接在文本上就能把字变大。但说实话，这种“方便”是带毒的，埋下的雷比省下的那点时间多得多。

在当前的 Web 标准体系里，<big> 早就被标记为已废弃（Deprecated）。HTML4.01 时它就开始过时，到了 HTML5 更是直接被移除。这意味着主流浏览器虽然为了兼容旧网页还能勉强渲染，但在未来的更新中，行为完全不可控。你现在的“能用”，不代表半年后、一年后还能正常显示，更不代表在新版 iOS Safari 或安卓 WebView 里表现一致。

最大的隐患其实不在兼容性，而在维护成本。

想象一下，三年后你要优化页面的响应式布局。如果字号是通过内联的 <big> 控制的，你就得拿着全局搜索工具，一行行去翻哪里加了标签，手动去掉后再统一写进 CSS 文件。要是项目体量大，几百个页面里有零星的几个 <big>，排查下来耗费的人力成本，远远超过当初直接写一个 style="font-size: 1.2em;" 所花的时间。代码规范的意义就在于统一，把表现层交给样式控制，结构归结构，这才是长期主义的做法。

还有个容易被忽视的点是无障碍访问（Accessibility）。屏幕阅读器在处理语义化标签时有明确的逻辑，但像 <big> 这种纯表现型标签，往往会被忽略，或者导致阅读顺序混乱。对于视障用户来说，这可能意味着他们听到的内容大小感与实际视觉呈现脱节。如果你在做政府网站、教育平台或企业官网，这类细节直接关系到合规性，别让一个简单的标签成为验收时的扣分项。

真正解决字号问题，CSS 才是正解。

现在调整文字大小，核心思路应该是基于相对单位。比如用 rem 配合根元素基准值，既能保证全站比例协调，又能实现灵活的主题切换。遇到需要突出显示的段落，与其用 <big>，不如封装一个 .highlight-text 类名。这样不仅代码清爽，后续如果设计说要改成蓝色加粗，只需改一处样式，所有引用该类的地方自动生效。这种关注点分离的原则，才是现代前端的基石。

当然，现实情况复杂，有些遗留系统确实全是 <big> 标签。这时候该怎么办？迁移重于修补。

如果资源有限无法重构全部，至少要在新增需求时严格禁止引入新标签。同时，建立自动化工具扫描代码库，定期提醒团队清理旧标签。可以把“发现 <big> 标签”设定为 CI/CD 流水线上的一个报错阈值，一旦有人提交包含该标签的代码，构建直接失败。用流程倒逼习惯，比口头强调有效得多。

说到底，技术选型没有绝对的对错，只有适不适合当下的场景。但在 HTML 标签的使用上，标准早已给出了明确答案。凡是能用 CSS 解决的视觉效果，绝不回退到 HTML 结构去写。 这不仅是对浏览器标准的尊重，更是对未来维护者的负责。当你下次想敲下 <big> 这三个字母时，停一秒，想想那个可能在未来某个深夜等着你去填坑的自己，换个方式，路会走得顺畅很多。