优先用 ，除非维护 IE8 以下系统；它支持嵌套 HTML、伪元素和语义化，但默认 type="submit" 易误提交；跳转应使用 伪装按钮而非 onclick；表单中 submit/reset/button 各司其职，不可混用。
按钮该用 <button></button> 还是 <input type="button">
优先用 <button></button>，除非你还在维护 IE8 以下的老系统。<button></button> 支持嵌套任意 HTML（比如图标、<span></span>、甚至 SVG），能用 ::before/::after 伪元素加样式，语义也更清晰。而 <input type="button"> 是个自闭合标签，只能靠 value 显示纯文本，没法加内联样式或子节点。
容易踩的坑：
-
<button></button>不写type属性时，默认是type="submit"—— 放在表单里会意外提交 -
<input type="button">的value是纯字符串，无法插入空格或换行，中文省略号得手动写… - 两者都支持
disabled，但<button disabled></button>会天然禁用所有子元素，<input>不会
<button></button> 跳转页面时为什么不该直接写 onclick="location.href=..."
因为这破坏了语义和可访问性：<button></button> 表达的是“执行操作”，不是“导航到某处”。屏幕阅读器会读作“按钮”，用户预期它触发 JS 或提交表单，而不是跳转；键盘用户按 Enter 或 Space 时行为也不同（<a></a> 支持两者，<button></button> 只响应 Space）。
真正该做的：用 <a href="/page"></a> + CSS 伪装成按钮。
立即学习“前端免费学习笔记（深入）”；
生成可在 deepbi 沙箱 iframe 内运行或作为独立文件运行的交互式 HTML 页面，使用 `window.deepbi` JS SDK 实现数据查询、空间管理、文件浏览及用户操作。当用户提出以下需求时启用该能力： - 创建 KPI 仪表盘、数据表格、文件浏览器、成员列表、管理页面； - 明确要求“转成 dhtml”、“转译成 HTML”、“把 XX 页面转成……”、“控制台页面”、“管理后台”、“DeepBI 页面迁移”； - 提及位于 `apps/console/src/featur
- 保留原生跳转能力（右键新标签页、复制链接、SEO 友好）
- 加
role="button"和tabindex="0"可让键盘用户聚焦并用Enter触发 - 别忘了加
rel="noopener"（外链时）防止安全漏洞
表单里 type="submit"、type="reset"、type="button" 的实际分工
三者不能混用，否则会出意料之外的行为。核心区别不在外观，而在浏览器默认动作：
-
type="submit"：触发表单提交（即使没写action，也会刷新当前页） -
type="reset"：把所有<input>、<select></select>、<textarea></textarea>恢复为初始值（注意：不是清空，是还原value或selected属性值） -
type="button"：彻底无默认行为，必须靠 JS 绑定事件才有用
常见错误：
- 忘记写
type，结果<button></button>在表单里成了隐式 submit - 用
type="button"去“模拟 submit”，却没手动收集表单数据、没阻止默认行为，导致页面刷新 - 重置按钮点了没反应？检查字段是否真有初始
value或selected属性（动态 JS 设置的不算）
什么时候非得用 <button></button> 而不是 <a></a>
只有两种情况：需要触发 JS 逻辑（且不涉及跳转），或必须参与表单控制流（如提交、重置、禁用联动）。
典型场景：
- 弹窗开关（
data-modal-id+ JS 控制显示/隐藏） - 表单内“添加一行”、“删除当前项”这类 DOM 操作
- 带 loading 状态的提交按钮（
disabled+ 文字切换） - 与
<form></form>的onsubmit事件深度耦合（比如校验失败时 focus 第一个错误字段）
别为了“长得像按钮”就硬套 <button></button> —— 多数跳转需求，<a></a> 更轻、更稳、更符合直觉。真正难处理的，其实是按钮和链接共存时的视觉一致性与焦点管理，那才是前端细节里的硬骨头。
