真实支付场景中绝大多数应使用type="button"，因其支持完整JS控制流程（校验、加密、禁用、请求等），避免type="submit"绕过防护直接提交明文；禁用需同时设disabled属性、CSS屏蔽pointer/focus、JS守卫；文案须严格对应后端阶段，尺寸不低于60×60px并满足可访问性要求。
安全支付按钮不是“做得好看就行”，而是必须让用户一眼确认可操作、系统明确拒绝误触、且前端不暴露敏感逻辑。视觉强化本质是信任信号的叠加，不是单纯换颜色或加阴影。
button 元素必须用 type="submit" 还是 type="button"？
取决于是否在 form 内且需触发表单默认提交行为。真实支付场景中，绝大多数应使用 type="button" —— 因为你要拦截点击、手动校验、哈希加密、禁用按钮、发 fetch 请求，而不是靠浏览器原生 submit 提交明文密码。
- 用
type="submit"会绕过 JS 控制流程，一旦用户右键“另存为”改 HTML 或禁用 JS，就可能跳过所有防护直接提交 -
type="button"配合addEventListener('click', handler)才能完整控制生命周期：聚焦修复 → 输入校验 → 哈希 → 禁用 → 请求 → 清空 → 恢复 - 若真要用
form，必须加onsubmit="return false"，且仍推荐用type="button"避免语义混淆
禁用状态（disabled）为什么不能只靠 CSS opacity？
opacity: 0.5 只是视觉灰化，按钮仍可被 focus、键盘 Enter 触发、甚至被自动化脚本点击。真正的禁用必须同时满足三件事：DOM 层面设 disabled 属性、CSS 层面屏蔽 pointer 和 focus、JS 层面移除事件监听或 guard 判断。
- 正确写法：
btn.disabled = true（自动禁用交互 + 触发 :disabled 伪类） - CSS 补充：
button:disabled { cursor: not-allowed; }，但别只写这个 - 关键遗漏点：iOS Safari 在
disabled状态下仍可能响应 touchstart，需额外加touch-action: none - 恢复时务必清空 loading 状态、重置
btn.disabled = false，不能只删 class
悬停（:hover）和点击（:active）效果在支付按钮上要不要？
要，但必须克制。支付按钮不是营销 CTA，过度动效会削弱严肃感，且移动端 hover 无效，:active 若设计不当反而造成“点不动”的错觉。
立即学习“前端免费学习笔记（深入）”；
-
:hover仅建议微调：背景色加深 10% 或加 1px inset shadow，避免 scale/rotate 等分散注意力的动画 -
:active必须有，但只做视觉压感：用transform: translateY(1px)+ 背景色再深 5%，持续时间 ≤ 100ms - 绝对不要在
:active中加 loading 动画——那是异步请求阶段的事，和点击瞬态反馈无关 - 所有 transition 必须限定属性：
transition: background-color 0.15s, transform 0.1s，避免影响性能
按钮文字文案与加载态切换的边界在哪？
文案切换不是“加载中…”这种模糊表达，而是严格对应后端实际阶段：准备 → 加密 → 请求 → 等待响应 → 成功/失败。用户需要知道卡在哪，而不是被一个旋转图标安抚。
- 初始状态：
立即支付（动词开头 + 明确动作） - 点击后立刻切为：
正在验证…（非“处理中”，强调前端校验动作） - 哈希完成、请求发出后切为：
支付中…（此时才真正交给后端） - 响应返回前保持该文案，绝不提前切回或加“请稍候”之类弱提示
- 失败时文案必须带错误类型：
余额不足，请充值，而非“支付失败”
最易被忽略的是：按钮尺寸和触摸热区。44×44px 是 iOS 最低要求，但支付按钮必须 ≥ 60×60px，且上下留白至少 20px——防止误触返回或地址栏。这不是 UI 建议，是 WCAG 2.1 AA 级可访问性硬性要求。
