标签语义上仅用于标记语义未明但需视觉区分的文本，如拼写错误、待定义术语或中文专名号，必须配合title或aria-label使用；技术上虽能加下划线，但非设计本意，且存在可访问性与兼容性风险。
<u></u> 标签现在**技术上能加下划线，但语义上不该这么用**——浏览器渲染那条线只是历史包袱，不是设计本意。
为什么 <u></u> 不该当“下划线工具”用
HTML5 明确把 <u></u> 定义为标记「语义未明但需视觉区分」的文本，比如拼写错误、待校对人名、中文专名号。它默认带下划线，纯属向后兼容，不是功能承诺：
- Chrome 120+ 已在控制台对无
title或aria-label的<u></u>发出警告 - 屏幕阅读器可能读作“拼写可疑”，哪怕你只是想标个重点词
- 用户看到下划线第一反应是“可点击”，尤其深色背景或低对比度下极易误操作
- CSS 重置时若漏掉
u { text-decoration: none; }，下划线会意外漏出
text-decoration: underline 的坑和绕过方式
这是最常被拿来替代 <u></u> 的 CSS 方案，但默认行为很不友好：
- 下划线位置偏低，会压到
g/y/p等字母的 descender，影响可读性 - 无法单独控制颜色、粗细、间距；
text-decoration-color和text-decoration-thickness在 Safari 15.4+ 才稳定支持 - iOS Safari 对
text-underline-offset支持滞后（iOS 15.4 才完全可用） - 推荐写法：
text-decoration: underline; text-underline-offset: 3px;（Chrome 89+/Firefox 84+ 可用）
真正可控的下划线：用 border-bottom
当你要确保下划线不压字、可调色、能 hover 变化、适配 SSR/框架作用域时，border-bottom 是更稳的选择：
Wechat Article Html
下载
将 Markdown 文章转换为微信公众号兼容的纯 HTML 格式。当用户要求"转成微信格式"、"生成公众号文章 HTML"、"排版到微信草稿箱"、"微信粘贴格式"时触发。输出带内联样式的纯 HTML，微信编辑器可直接渲染，无需额外适配。支持标题、段落、列表、粗体、行内代码、表格、引用块、代码块、配图的完整转换。
立即学习“前端免费学习笔记（深入）”；
- 完全避开 descender 冲突，靠
padding-bottom控制离文字距离 - 颜色、粗细、圆角、虚线全由 CSS 控制，且所有现代浏览器 100% 支持
- React/Vue 中不会被 scoped 样式意外覆盖，也避免伪类定位失效问题
- 注意加
display: inline-block防止撑满父容器宽度 - 示例：
.highlight { border-bottom: 1px solid #007bff; padding-bottom: 2px; display: inline-block; }
<u></u> 唯一合规的使用场景
只在你要表达「这段文字当前语义未定，但需要临时视觉提示」时才用，且必须附带说明：
- 法律文书里标出尚未定义的术语：
<u title="尚未在本协议中定义">服务范围</u> - 中文编辑稿中标人名专称：
<u aria-label="鲁迅，中国现代文学家">鲁迅</u> - 拼写检查反馈：
<u title="疑似拼写错误：'recieve' 应为 'receive'">recieve</u> - 关键点：没
title或aria-label的<u></u>，等于没传任何有效语义
最容易被忽略的是 contrast ratio：那条下划线本身不是颜色，它依赖文字色 + 背景色共同构成可读性。多数人只测文字色是否 ≥ 4.5:1，却忘了测那条线在背景上是否真的看得清。
