必须用 而非 或无 type 的 ，因前者确保表单提交行为一致、避免跳转或意外刷新；文案需明确动作（如“保存资料”），配 aria-label；禁用状态须用 disabled 并同步样式与焦点管理；点击区域≥48×48px，触控反馈需 :active 样式；多提交按钮必须设 name 属性供后端识别。
按钮该用 <button></button> 还是 <a></a>
必须用 <button type="submit"></button>，而不是 <a></a> 或 <button></button>（无 type）。<a></a> 会触发页面跳转，破坏表单上下文；省略 type 的 <button></button> 在部分浏览器中默认为 type="submit"，但行为不一致——比如在某些表单内可能意外提交，或在 Safari 中触发刷新。显式声明 type="submit" 才能确保它只响应表单提交逻辑。
常见错误现象：<button>保存</button> 点击后页面刷新但资料没更新，就是没设 type 或表单没配 onsubmit 处理。
- 如果按钮在
<form></form>内，且目标是提交表单数据，就用<button type="submit"></button> - 如果走纯前端 JS 更新（比如调 API 后 patch DOM），用
<button type="button"></button>，避免任何默认提交行为 - 绝对不要用
<a href="#"></a>模拟按钮——它会滚动到页面顶部，且无障碍支持差，键盘用户按 Enter 会触发两次（一次链接、一次 JS）
按钮文案和 aria-label 怎么写才安全
“修改资料”不是好按钮文案。用户点击前需要明确动作后果：是保存？是弹窗？还是跳转编辑页？按钮文案必须反映真实行为。同时，仅靠视觉文字不够，要补 aria-label 适配读屏器。
使用场景决定文案：
— 若点击后直接提交当前表单 → 用“保存资料”，配 aria-label="保存个人资料更改"
— 若点击后打开模态框 → 用“编辑资料”，配 aria-label="打开个人资料编辑窗口"
- 避免模糊动词：“修改”“操作”“管理”——用户不知道点了会发生什么
- 不要重复上下文：“个人中心的修改资料按钮”这种冗余文案塞进按钮里
- 如果按钮图标-only（如铅笔 icon），
aria-label必须存在，且不能只写“编辑”，得写“编辑个人资料”
禁用状态和加载反馈怎么加才不翻车
提交中若不置灰按钮，用户可能连点多次，导致重复请求或后端报错 409 Conflict 或 422 Unprocessable Entity。但简单加 disabled 属性还不够——它会移除焦点、中断键盘导航，且样式需同步控制。
- 初始状态：
<button type="submit" disabled>保存中...</button>+ CSS 控制opacity: 0.6; cursor: not-allowed; - JS 提交前：用
button.disabled = true，并改文案（如加“…”或换文字），别只靠 CSS 遮罩 - 提交失败后：必须恢复
disabled = false，否则用户无法重试；同时把焦点设回按钮上（button.focus()），方便键盘用户继续操作 - 别用
pointer-events: none代替disabled——它绕过表单校验，且读屏器无法感知状态变化
移动端点击区域和触控反馈要注意什么
小按钮在手机上容易点歪，尤其手指粗或戴手套时。min-width 和 padding 不够会导致误操作，而缺少触控反馈会让用户怀疑是否点到了。
- 最小点击区域至少
48px × 48px（iOS/Android 无障碍规范），可用padding扩展，别只靠字体大小撑开 - 加
:active样式，比如背景色变深或加transform: scale(0.98)，否则用户没反馈感 - 避免在按钮上监听
touchstart做自定义 loading —— 它和原生click事件冲突，可能造成延迟或不触发 - 如果按钮在
position: fixed的底部栏里，注意 iOS Safari 键盘弹起时页面缩放可能导致按钮错位，用viewportmeta 的height=device-height不能解决，得靠 JS 监听resize调整
最常被忽略的是：按钮的 name 属性。如果表单里多个提交按钮（比如“保存并退出”“仅保存”），后端靠 name 区分意图，漏写 name="save" 就只能靠 value 判断，而 value 可能被 i18n 或 UI 改写，不可靠。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
