HTML文本格式化靠语义化标签实现：<strong>表重要性，<em>表语气强调，<mark>表上下文高亮，<small>表附属细则，<sub>/<sup>用于上标下标；<b>和<i>有特定语义，非单纯加粗斜体；样式应由CSS控制，HTML只表达含义。
HTML 文本格式化不是靠“教程”实现的，而是靠正确使用语义化标签——用错标签（比如滥用 <div> 或 <b>）会导致可访问性崩坏、SEO 降权，甚至被现代框架警告。
哪些标签算真正意义上的文本格式化
浏览器默认样式只是表象，真正的格式化是语义表达：<strong> 表示重要性提升，<em> 表示语气强调，<mark> 标记上下文相关高亮，<small> 表示附属细则（如版权、免责声明），<sub>/<sup> 用于化学式或数学上标下标。
常见错误现象：<b> 和 <i> 被当成“加粗/斜体开关”滥用，但它们没有语义——<b> 仅表示“不带语气的突出”，<i> 表示“不同语调、外语词、技术术语等”，不是视觉样式替代品。
- 使用场景：写文档注释用
<small>，不是font-size: 12px；标注音标或拉丁学名用<i>，不是<em> - 参数差异：这些标签都不接受
style属性作为“格式化手段”——样式应由 CSS 控制，HTML 只负责“这是什么” - 兼容性影响：所有上述标签在 IE9+ 和所有现代浏览器中行为一致；但若用
<font>（已废弃）或内联style="font-weight:bold"，会被 Lighthouse 标为“非语义化”
为什么不能用 CSS 替代 HTML 格式化标签
CSS 控制“怎么显示”，HTML 告诉屏幕阅读器、搜索引擎、代码分析工具“这是什么”。两者职责不能混。
立即学习“前端免费学习笔记（深入）”；
常见错误现象：用 <span class="highlight"> 替代 <mark>，结果语音朗读时不会提示“此处高亮”，搜索引擎也不识别该内容为上下文关键片段。
- 使用场景：用户搜索关键词高亮 → 用
<mark>；强调操作后果（如“删除后不可恢复”）→ 用<strong>；不是为了“看起来更重”才选标签 - 性能影响：无直接性能损耗，但语义错误会增加辅助技术解析负担，间接拖慢无障碍渲染
- 可访问性陷阱：仅靠 CSS 改变颜色/粗细，对色觉障碍用户无效；而
<strong>会被 TalkBack/VoiceOver 主动加重语音语调
遇到富文本编辑器输出的混乱 HTML 怎么办
从 contenteditable 或第三方编辑器（如 TinyMCE、Quill）粘贴进来的 HTML 常含冗余 <font>、嵌套 <span style="...">、甚至 <b><u><i> 套三层——这不是格式化，是样式污染。
实操建议：服务端或前端做清洗，优先保留语义标签，剥离纯表现标签：
const cleanText = htmlString .replace(/<font[^>]*>/gi, '') .replace(/<\/font>/gi, '') .replace(/<span[^>]*style=["'].*?["'][^>]*>/gi, '') .replace(/<\/span>/gi, '') .replace(/<b>/gi, '<strong>') .replace(/<\/b>/gi, '</strong>') .replace(/<i>/gi, '<em>') .replace(/<\/i>/gi, '</em>');
- 不要信任编辑器默认输出：Quill 默认用
<strong>，但 TinyMCE 可能配成<b>，需统一归一化 - 警惕
<u>：HTML5 中它表示“非链接的下划线文本”，语义极弱，多数场景应改用 CSStext-decoration，而非保留标签 - 注意换行：编辑器常把回车转成
<br>，但段落逻辑应由<p>承载；纯换行不是格式化，是结构缺失
最易被忽略的一点：格式化标签必须嵌套在块级容器里。单独丢一个 <em>Hello</em> 在 <body> 下，虽然能渲染，但违反 HTML 内容模型——它必须是 <p>、<div>、<section> 等的子元素。否则，某些 SSR 框架或校验工具会静默修正或报 warning。
