Safari不显示\_下划线是符合HTML规范的正常行为，\_仅为普通字符；需用CSS text-decoration: underline 或语义化<u>标签实现跨浏览器一致下划线效果。
HTML中_下划线在Safari不显示？不是bug，是规范行为
Safari（包括iOS/iPadOS所有WebKit内核浏览器）默认不渲染纯文本中的_为下划线——这不是渲染错误，而是严格遵循HTML规范：HTML标准里_只是普通字符，没有语义或样式含义。其他浏览器（如Chrome）早期曾把_当视觉分隔符做兼容性渲染，但那是非标准行为，已被逐步移除。
常见错误现象：hello_world在Safari里显示为hello_world（无下划线），而旧版Chrome可能显示成hello_world（带下划线），让人误以为“Safari坏了”。
- 别指望
_自动变成下划线，它就是个ASCII下划线字符，和-、.地位一样 - 如果需要视觉下划线效果，必须用CSS：
text-decoration: underline，或语义化标签如<u>（注意：<u>在HTML5中已恢复语义，表示“非文本标注”，非装饰用途） - 若用于代码片段，应包裹在
<code>或<pre>中，并配font-family: monospace，此时_会正常显示为字符，而非被解释为样式
想让_在所有浏览器都“看起来像下划线”？用CSS控制最稳
依赖浏览器对_的私有渲染逻辑，等于绑死在某个版本的Chrome或Firefox上，Safari和新版Edge都会掉链子。真正跨浏览器一致的做法，是明确告诉浏览器“这里要下划线”。
使用场景：表单占位符提示（如user_name）、API字段名展示、控制台日志输出等需要强调分隔但又不想改语义结构的地方。
立即学习“前端免费学习笔记（深入）”；
- 直接加内联样式：
<span style="text-decoration: underline">user_name</span> - 更推荐用class：
<span class="field-key">user_name</span>，配合CSS：.field-key { text-decoration: underline; } - 避免用
<u>除非真有非文本标注需求（比如拼写纠错、专有名词注释），否则语义错位，还可能被屏幕阅读器误读 - 注意
text-decoration在行内元素中默认不跨换行，如需连续下划线，确保内容在同一个<span>里
_出现在URL、id或class里会影响Safari吗？完全不影响
这个担心多余。_在HTML属性值（如id="user_name"、class="form_input"）、URL路径（/api/v1/user_profile）、甚至CSS选择器（#user_name）中都是合法且被Safari完全支持的字符。
唯一要注意的是：不要把它和CSS类名连写搞混，比如.user_name在CSS里是选中class="user_name"，没问题；但.user_name_2不是“user_name加下划线”，而是完整类名——Safari和其他浏览器解析规则一致。
-
id和class中用_是安全的，比用-还少一层CSS转义顾虑（-在某些老工具链里可能被误当减号） - JavaScript中通过
document.getElementById("user_name")获取元素，Safari毫无问题 - URL里的
_不需要编码，encodeURI也不会动它，服务器端也能原样接收
为什么有些文档里_明明“看起来有下划线”？大概率是字体或编辑器渲染的假象
你在VS Code、Typora或某些PDF文档里看到foo_bar带下划线，那不是HTML渲染的结果，而是编辑器/排版引擎主动给_加了装饰样式（比如JetBrains系IDE默认高亮下划线变量），或是PDF字体内置了连字效果。一旦复制进HTML页面，这些修饰就没了。
这种“看起来有”但“实际没绑定样式”的情况，最容易在技术文档协作中引发误解——前端同学照着截图写HTML，结果发现Safari不认。
- 验证方法：右键“检查元素”，看
_是否被包裹在有text-decoration的标签里，或者是否应用了自定义字体特性（如font-variant-ligatures） - 真实项目中，所有样式必须显式声明，不能靠编辑器或预览器“帮忙渲染”
- 如果团队用Markdown生成文档，确认转换工具（如remark、markdown-it）没偷偷给
_加<u>或style
