应使用语义化 <kbd> 元素显示键盘快捷键，如 <kbd>Ctrl</kbd>+<kbd>C</kbd>；避免用 <code> 或 <span> 替代，以保障无障碍支持、工具识别及跨平台兼容性。
HTML 里怎么正确显示键盘快捷键（比如 Ctrl+C）
用 <kbd> 元素，不是 <code>，也不是手写括号加粗。它专为“用户要按的键”设计，语义清晰、屏幕阅读器能识别、默认样式也合理（通常是等宽+浅灰背景+边框）。
常见错误是直接写 Ctrl+C 或用 <span> 加 CSS 模拟，结果语义丢失、无障碍支持失效、复制粘贴还可能带多余空格。
-
<kbd>Ctrl</kbd>+<kbd>C</kbd>—— 多个独立按键，用多个<kbd>套，中间用普通符号连接 -
<kbd>Cmd+Shift+T</kbd>—— macOS 场景下，Cmd是标准写法，别写Command或⌘（后者需额外字体支持） - 避免嵌套：
<kbd><kbd>F5</kbd></kbd>是错的，浏览器会降级处理，语义混乱
为什么不能用 <code> 或 <span> 替代 <kbd>
<code> 表示计算机代码片段，比如函数名、命令行输入；<kbd> 表示物理/逻辑按键操作——这是语义本质区别，不是样式问题。
实际影响比想象中大：
立即学习“前端免费学习笔记（深入）”；
- 读屏软件（如 NVDA、VoiceOver）遇到
<kbd>会明确读作“keyboard key”，而<code>可能读成“code block”或直接念字母 - 某些浏览器扩展（如快捷键管理工具）会主动扫描
<kbd>元素做索引，<span>完全不可见 - CSS 重置时，
kbd默认有font-family: ui-monospace, monospace，比手写font-family: 'SFMono-Regular'更兼容
跨平台快捷键写法要注意什么
Windows 和 macOS 键位不同，但 HTML 不强制区分——关键在文案是否准确传达操作意图，而不是迁就某系统。
推荐做法是按目标用户主平台写，必要时补充说明：
- 面向开发者文档：优先用
<kbd>Ctrl</kbd>+<kbd>Shift</kbd>+<kbd>R</kbd>（Windows/Linux 习惯），再加一句“macOS 用户请用<kbd>Cmd</kbd>+<kbd>Shift</kbd>+<kbd>R</kbd>”</li> <li>不要混写：<code><kbd>Ctrl / Cmd</kbd>+<kbd>C</kbd>
语义模糊，/不是按键，也不属于任何平台规范 - 功能键统一用大写缩写：
<kbd>Esc</kbd>、<kbd>Tab</kbd>、<kbd>Enter</kbd>（不是return或↵）
自定义样式时容易破坏的三个点
可以改 kdb 样式，但别动语义结构。最常踩的坑是：
- 去掉
border和background后，视觉上完全看不出是按键——用户扫读时失去线索 - 设
display: inline-flex但忘了align-items: center，导致多行文本（如<kbd>Alt</kbd><kbd>F4</kbd>）垂直错位 - 用
font-size: 0.85em太小，尤其在高 DPI 屏幕下，文字发虚且难以点击（移动端触摸热区不足）
真正需要定制时，建议只调整 padding、border-radius 和 background-color，保留默认 font-family 和 line-height。
语义正确的 <kbd> 很轻量，但一旦写错，修复成本远高于初期多打几个标签——尤其当文档被自动化工具抓取或集成进帮助系统时，错一处，全链路都受影响。
