<kbd> 是纯语义化展示标签，仅用于标记真实按键或组合键（如 <kbd>Ctrl</kbd> + <kbd>S</kbd>），不可交互、不触发事件、不收集输入；快捷键需用 keydown 监听，输入控件应使用 <input> 或 <textarea>。
kbd 标签不是用来接收输入的
<kbd> 不是 <input>，它不收集用户按键，也不触发任何事件——它只是语义化地「说：这里代表键盘操作」。很多人一看到「键盘」就下意识想用它做快捷键监听或表单控件，结果发现点不了、绑不了 onkeydown、也拿不到值。这是根本性误解。
-
<kbd>是纯展示标签，类似<code>或<samp>，只负责告诉浏览器和屏幕阅读器「这段文字模拟的是人按下的键」 - 真要做快捷键响应，得用 JavaScript 监听
keydown事件，配合event.key或event.code判断 - 想让用户输入？该用
<input type="text">或<textarea>，不是<kbd>
怎么写才符合语义又不出错
正确用法的核心就一条：只包裹真实、离散的按键或组合键名称，不包解释性文字，不包箭头/加号等符号（那些应放在 <kbd> 外面）。
- ✅ 正确：
<p>按 <kbd>Ctrl</kbd> + <kbd>S</kbd> 保存</p>（两个独立<kbd>，加号在外） - ❌ 错误：
<kbd>Ctrl + S</kbd>（把运算符塞进一个标签里，语义混乱，且无法单独样式化 Ctrl 和 S） - ❌ 错误：
<kbd>点击「保存」按钮</kbd>（这不是键盘输入，是鼠标操作） - 跨平台提示可并列写：
<kbd>Cmd</kbd> / <kbd>Ctrl</kbd>，别用括号或斜杠混在标签内
默认样式太朴素，但改法有坑
所有主流浏览器对 <kbd> 的默认处理只是设了 font-family: monospace，没边框、没背景、没圆角——看着跟普通文本几乎没区别。想让它像 macOS 或 VS Code 里那样“弹出式按键”，必须加 CSS，但要注意兼容性和可访问性。
anything-to-html
下载
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
- 推荐基础增强：
kdb { padding: 2px 4px; border: 1px solid #aaa; border-radius: 3px; background: #f5f5f5; font-size: 0.95em; } - 避免用
outline或强阴影干扰焦点逻辑——<kbd>本身不可聚焦，加tabindex属于滥用 - 别设
line-height: 1或过小padding，否则在高缩放比或 Windows 高对比度模式下文字会被裁切 - 如果项目已用 CSS 重置（如 normalize.css），检查是否意外清除了
kbd的font-family，需手动补回
和 code/samp/var 混用时的边界在哪
这四个短语标签常一起出现，但职责分明：<kbd> 是用户按的键，<code> 是程序代码，<samp> 是终端/程序输出，<var> 是变量名。混用会导致语义丢失，影响 SEO 和读屏器理解。
立即学习“前端免费学习笔记（深入）”；
- 命令行教程中：
<p>运行 <code>git commit -m "init"</code>，然后按 <kbd>Ctrl</kbd> + <kbd>D</kbd> 退出</p>（代码 vs 操作） - 错误日志场景：
<p>报错：<samp>TypeError: Cannot read property 'length' of undefined</samp></p>，别写成<kbd>TypeError...</kbd> - 数学公式里：
<p>斜率 = <var>m</var> = (<var>y</var><sub>2</sub> − <var>y</var><sub>1</sub>) / (<var>x</var><sub>2</sub> − <var>x</var><sub>1</sub>)</p>，这里绝不用<kbd>
<kbd>，需要显式配置插件或用 HTML 原生写法；还有就是自动化测试脚本常忽略这类语义标签，导致快捷键说明在 E2E 测试里成了「不可断言的纯文本」。 
