Chrome 120+、Firefox 115+ 对无语义的 <u> 标签发出“used without semantic purpose”警告，因HTML5规范要求其仅用于拼写错误、专有名词等需视觉区分但无结构语义的场景，误用会导致读屏障碍、SEO失效及样式抖动。
为什么 <u> 标签会被警告甚至报错
Chrome 120+、Firefox 115+ 已在控制台对无明确语义的 <u> 发出警告，提示“<u> used without semantic purpose”。这不是浏览器 bug，而是主动合规行为——HTML5 规范明确要求：只有当内容属于拼写错误、专有名词、技术术语等「语义中性但需视觉区分」场景时，才允许用 <u>。
常见误用现象：
-
<u>点击查看</u>→ 被读屏软件读作“拼写可疑”，用户困惑 -
<u>用户名</u>→ SEO 不识别为关键词，也不参与语义权重计算 - 服务端渲染（SSR）首屏闪现原生下划线，CSS 加载后又重绘，造成样式抖动
text-decoration: underline 的默认位置为什么总压着 g/y/p
这不是 CSS 写错了，是字体本身的 underline position 属性决定的。每个字体文件里都内置了这个数值，有些中文字体（如早期微软雅黑、思源黑体旧版）把下划线画得太低，刚好切过 descender 区域。
解决方式不是换字体，而是微调：
立即学习“前端免费学习笔记（深入）”；
- 现代浏览器（Chrome 89+、Firefox 70+、Safari 15.4+）直接加
text-underline-offset: 2px，从 1px 开始试 - 需要兼容 iOS 15.3 及更早版本？改用
border-bottom: 1px solid currentColor+padding-bottom: 2px - 绝对别用
text-shadow: 0 1px 0 currentColor模拟——复制时带阴影、高对比度模式下糊成一团
border-bottom 和 text-decoration 哪个更适合做链接下划线
如果目标是「可点击文本」，border-bottom 是更稳的选择，尤其在框架项目里：
-
<a href="#">链接</a>默认有text-decoration: underline，但 hover 时设text-decoration: none会清掉所有修饰（包括自定义颜色/粗细），必须显式重写整条规则 -
border-bottom支持border-radius、渐变色、hover 时只变色不消失，且不会被line-height或字体 descender 干扰 - Vue 的
<style scoped>下，text-decoration容易被父级样式穿透覆盖；border-bottom是独立盒模型属性，作用域更干净
React/Vue 里动态加下划线最容易漏哪一步
不是忘了加 class，而是忘了处理「未加载 CSS 时的降级表现」：
- SSR 或 hydration 前，DOM 已存在，若只靠 CSS 类控制下划线，首帧会无样式（白屏期）或回退到
<u>的原生下划线（闪烁） - Vue 中用
v-bind:class切换下划线状态时，若 class 名含连字符（如has-underline），需确保 CSS 文件已注入，否则 runtime 无法匹配 - React 使用 CSS-in-JS（如 Emotion）时，
text-decoration-line: underline在 SSR 环境可能被忽略，而border-bottom渲染更可靠
<u> 已经没法回答这个问题了。 
