用 <button> 而不是 <input type="button">
HTML 中标记“命令按钮”的标准方式是 <button> 元素，不是 <input type="button">。前者语义清晰、内容可嵌套、样式控制更直接；后者只能靠 value 属性显示文字，无法放图标或 <span> 等内联结构。
常见错误现象：<input type="button" value="提交"> 在需要加 SVG 图标或不同颜色文字时束手无策；点击后无明确焦点反馈（尤其在无障碍场景下）。
-
<button>默认type="submit"，表单里不写type容易意外触发表单提交 - 必须显式写
type="button"来避免默认行为，这是最常漏掉的点 -
<button>内容支持 HTML，比如<button><svg>...</svg> 保存</button>，而<input>只能靠伪元素或 JS 注入图标
按钮必须有明确的 type 属性
没写 type 的 <button> 在表单中会按浏览器默认行为处理：Chrome/Firefox/Safari 都当 submit，哪怕它只是个“取消”按钮。这不是兼容性问题，是规范定义的行为。
使用场景：模态框里的“关闭”按钮、工具栏上的“刷新”按钮、多步骤表单里的“上一步”——这些都不该触发提交。
立即学习“前端免费学习笔记（深入）”；
使用 PptxGenJS 和 Python 解析，将结构化的 HTML/CSS 幻灯片内容转换为原生、可编辑的 PowerPoint（.pptx）演示文稿。
- 纯操作按钮一律用
<button type="button"> - 表单主提交按钮用
<button type="submit">（比<input type="submit">更易样式化） - 禁止省略
type，尤其不要依赖“反正没包在<form>里就安全”——DOM 移动、Shadow DOM 或框架渲染可能改变上下文
禁用状态和可访问性不能只靠 disabled
disabled 确实让按钮不可点击、变灰、跳过 tab 键导航，但它同时会让屏幕阅读器完全忽略该元素。如果按钮是流程关键节点（比如“同意条款后启用下一步”），用户会丢失状态感知。
性能影响小，但体验断层明显：视觉上灰了，听觉上却消失了。
- 需要传达“暂时不可用但存在”的场景，改用
aria-disabled="true"+ CSS 控制样式（如opacity: 0.5; pointer-events: none;） -
disabled适合真正失效的操作，比如表单校验失败时锁住提交按钮 -
aria-disabled必须配合键盘事件拦截（onKeyDown拦截 Enter/Space），否则键盘用户仍可能误触
别用 <a> 模拟按钮
用 <a href="#" onclick="doSomething()">点击执行</a> 是典型反模式。它破坏语义、干扰键盘导航（Enter 触发后 URL 变成 #）、绕过按钮的原生 focus 状态管理。
错误信息示例：Warning: Failed prop type: Invalid aria-* attribute: aria-pressed is not supported on <a>（当你试图加 ARIA 状态时）。
- 任何触发 JavaScript 行为、不跳转页面的交互，优先选
<button type="button"> - 真要保留链接语义（比如“查看帮助”打开侧边栏），用
<button aria-expanded="true">+aria-controls，而不是退化成<a> - 框架里常见用
<Link>或<RouterLink>包按钮，这没问题；但别让<a>承担按钮逻辑
事情说清了就结束。最常被忽略的是 type 属性的缺失和 disabled 对无障碍的彻底屏蔽——这两个点不修，按钮就算长得再像，也不算真正可用。
