<button>能嵌套HTML，<input type="button">只能靠value设纯文本；前者是容器元素，支持SVG、图标、换行等任意合法HTML，后者是自闭合标签，内容完全由value字符串决定。
button能嵌套HTML，input type="button"只能靠value设纯文本
这是最根本的差异。<button>是容器元素，内部可放任意合法 HTML：<svg>、<img>、<span>、换行符、甚至内联样式；<input type="button">是自闭合标签，内容完全由value属性字符串决定，无法插入任何子节点。
常见错误现象：试图在<input type="button" value="<svg>...</svg>刷新">里写 HTML —— 浏览器会原样显示字符串，不会解析 SVG；而<button type="button"><svg></svg>刷新</button>能正常渲染图标+文字。
使用场景上，只要按钮需要以下任一能力，就必须选<button>：
- 带图标（SVG / icon font / <img>）
- 文字加粗、变色、多行排版
- 动态插入/替换部分 DOM（比如加载中状态加 spinner）
- 配合
aria-label与视觉内容分离（如“上传”按钮旁有隐藏说明）
button支持伪元素和更稳定的盒模型
<button>原生支持 ::before 和 ::after，能用 CSS 添加装饰性内容（箭头、状态标记、小圆点），无需额外 DOM 节点；<input type="button">不支持伪元素，想加箭头只能靠背景图或包裹一层 <span>，增加结构复杂度。
立即学习“前端免费学习笔记（深入）”；
盒模型行为也不同：
-
<button>的padding、line-height、垂直居中表现稳定，尤其在 flex 布局中默认按内容盒对齐 -
<input type="button">在旧版 IE 中常出现文字上下偏移、line-height失效、height+padding导致文字被截断 - 移动端点击热区：两者默认都太小，但
<button>更容易通过min-height+padding安全扩大，<input>的基线对齐问题容易让热区错位
表单中不写type属性，button默认submit，input天然安全
这是最容易引发线上 bug 的点：<button> 在 W3C 规范中默认 type="submit"，放在 <form> 里不加 type="button" 就会触发表单提交；而 <input type="button"> 的 type 是必填属性，浏览器不会猜测，天然不会提交。
所以即使你只是写个“取消”按钮，也必须显式声明：
- ✅
<button type="button">取消</button> - ❌
<button>取消</button>（危险！可能刷新页面） - ✅
<input type="button" value="取消">（安全，但功能受限）
别依赖 event.preventDefault() 补救——那是在掩盖设计缺陷。DOM 位置一旦变动（比如把按钮从 form 外挪进 form 内），行为就会突变。
可访问性和脚本操作差异真实存在
屏幕阅读器对 <button> 内部结构识别更准。比如 <button type="button"><svg aria-hidden="true"></svg><span>刷新</span></button> 可以配合 aria-label="刷新数据" 精确播报；而 <input type="button" value="刷新"> 只能读出 value 字符串，图标语义完全丢失。
脚本操作也不同：
- 更新文字+图标：
btn.innerHTML = "已刷新"会清空 SVG，但保留结构可控；inp.value = "已刷新"只能换纯文本，无法恢复图标 - 禁用状态：
<button disabled>会天然禁用所有子节点；<input disabled>只影响自身 - 获取值：
btn.value在 IE 下返回 innerText，在其他浏览器返回value属性值，行为分裂；inp.value行为一致，但无扩展性
真正麻烦的不是“能不能用”，而是混用后在自动化测试、无障碍审计、跨浏览器回归中暴露的隐性偏差——DOM 树和可访问树完全不同，光看渲染效果根本发现不了。
