html中accesskey仅聚焦不触发操作，真正快捷键需用keydown监听并手动处理；必须考虑组合键判断、默认行为拦截、输入框排除、焦点管理及可访问性。
HTML 本身没有“按快捷键就执行操作”的原生机制，accesskey 只能聚焦元素，不能触发点击；真要实现 Ctrl+S 保存、/ 打开帮助这类行为，必须用 document.addEventListener('keydown') 监听并手动处理。
为什么 accesskey 按了没反应？
accesskey 的设计目标是辅助导航，不是执行动作：它只把焦点移到元素上，不触发 click 事件。用户还得再按 Enter 或 Space —— 这和“快捷键直触功能”的预期完全不符。
- 不同系统触发组合差异大：
accesskey="s"在 Windows 是 Alt+S，macOS 是 Ctrl+Option+S，Firefox 有时还要加 Shift - 浏览器默认快捷键会拦截：比如 Alt+S 在 Chrome 中可能跳转到地址栏，你的按钮根本收不到事件
- 非可聚焦元素无效：
<div>、<code><span></span>默认不响应accesskey，除非加tabindex="0" - 用户根本不知道快捷键存在：没有视觉提示、无键盘反馈、不暴露在屏幕阅读器中
- 必须用
keydown，不是keypress（后者不识别修饰键，且已被标准弃用） - 判断组合键优先用布尔属性：
if (e.ctrlKey && e.key === 's')，而不是e.code === 'KeyS'（物理键位在 AZERTY 或 Dvorak 布局下会错位） - 加
e.preventDefault()阻止浏览器默认行为，但仅对明确注册的快捷键做——比如 Ctrl+T 就不该拦，拦了也没用 - 先排除输入场景：
if (e.target.tagName === 'INPUT' || e.target.tagName === 'TEXTAREA') return，避免打断用户打字 - 确保目标元素可聚焦：给
<button></button>加tabindex="0"不必要（它原生可聚焦），但给<div role="button"> 就必须加 <li>调用 <code>.click()前，先.focus()—— 这能让屏幕阅读器播报状态变化，也方便用户后续用 Enter/Space 重复操作 - 如果快捷键对应的是“打开帮助面板”，建议用
<dialog></dialog>元素，调用dialog.showModal()，它自带 Esc 关闭、焦点锁定和无障碍语义 - 避免在
<input>上直接绑定快捷键逻辑——焦点不在它身上时就失效；应始终监听document级 - 绝对避开：
Ctrl+T、Ctrl+W、Ctrl+R、F5、F12、Alt+Tab（macOS 是Cmd+Tab） - 慎用
Ctrl+S：虽然常见，但部分浏览器仍会弹出“另存为”对话框，e.preventDefault()在某些版本中无法完全阻止 - 推荐组合：
Ctrl+/（打开帮助）、Ctrl+K（聚焦搜索）、Esc（关闭模态框）——这些冲突少、语义清晰、用户已有认知 - 移动端软键盘无
/键，硬绑定会失效；用<details><summary></summary></details>实现的帮助面板天然兼容触屏
怎么用 keydown 实现真正可用的快捷键？
全局监听是最常用方式，但细节决定是否稳定可用。别用已废弃的 keypress，也别只靠 e.key 判断组合键。
anything-to-html
下载
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
如何让快捷键触发按钮点击？
监听到快捷键后，不能只调用 click() 了事。要考虑语义、焦点流和可访问性。
哪些快捷键组合该避开？
不是所有组合都能安全劫持。有些被浏览器强占，有些触发安全限制，硬拦会失败或引发异常。
最易被忽略的一点：快捷键不是加完监听就完事了。它必须和焦点管理、视觉反馈、可访问性角色（如 role="button"）、以及用户当前上下文（是否在输入框里）联动起来，否则就是半截功能。
