button的type属性是局部属性而非全局属性，必须显式声明：不写时Chrome/Firefox在form内默认submit，易致意外提交；Safari行为不一致；仅type="button"完全静默无副作用。
button 元素天然支持全部 HTML 全局属性，但不是所有属性都“安全可用”——有些会引发意外行为，有些需配合其他属性才生效，有些在表单上下文中会被浏览器悄悄覆盖。
为什么 type 不是全局属性，却必须显式写？
很多人误以为 type 是全局属性，其实它是 button 的**局部属性**。不写 type 时，Chrome/Firefox 默认为 submit，Safari 却可能按 DOM 位置或表单状态推断，导致点一下按钮就意外提交表单。这不是 bug，是规范留的坑。
- 始终显式声明：
<button type="button">取消</button>，哪怕你只是想放个纯交互按钮 - 在表单内嵌
button时，type="submit"和type="reset"会触发原生表单行为，无需 JS -
type="button"是唯一真正“无副作用”的选项；漏写它，等于把控制权交给了浏览器实现细节
contenteditable 加在 button 上会发生什么？
语法上合法，但行为极不稳定：Chrome 允许编辑按钮文字，但焦点管理错乱；Firefox 可能直接忽略；Safari 会禁用点击事件。更关键的是，WCAG 明确反对可编辑按钮——它破坏了“按钮 = 触发动作”的语义契约。
- 不要对
button设置contenteditable="true"，哪怕只是临时调试 - 真要动态改按钮文案，用 JS 操作
textContent或innerText，保持语义纯净 - 若需富文本按钮（比如带图标+高亮词），用
<div role="button">替代，并手动补全tabindex="0"和onclick处理
accesskey 和 tabindex 在按钮上怎么配才不翻车？
accesskey 的快捷键组合因浏览器和系统而异（比如 Chrome Win 是 Alt+S，Mac 是 Ctrl+Alt+S），而 tabindex 若设为正数（如 tabindex="5"），会打乱屏幕阅读器的自然阅读流。
立即学习“前端免费学习笔记（深入）”；
- 优先用
tabindex="0"：让按钮按 DOM 顺序进入 Tab 流，兼容性最好 -
accesskey值尽量避开系统级快捷键（如a、f、h），选冷门字母如z、x - 加
title提示快捷键，比如：<button accesskey="z" title="保存 (Alt+Z)">保存</button> - 测试时务必在真实键盘+屏幕阅读器下验证，不能只靠鼠标点
最常被忽略的一点：button 的 disabled 状态会完全屏蔽所有全局属性的效果——包括 accesskey、tabindex、title 都失效。如果需要“视觉禁用但保留提示”，得用 aria-disabled="true" + CSS 控制样式，而不是原生 disabled。
