payment_method单选组name必须统一为payment_method，value用小写下划线（如alipay、wechat_jsapi），禁用disabled而非隐藏选项；select适用于多支付方式但需按场景区分value；金额只读，提交前禁用按钮并二次校验；支付成功状态必须由后端回调驱动，严禁前端伪造。
payment_method 单选组必须统一 name 且 value 用英文下划线
用户选了哪种支付方式，后端靠 name 和 value 区分；漏掉 name 或写错值，后端收不到或解析失败是常态。
常见错误包括：name 写成 pay_method、payment 等不一致变体；value 用中文（如 "微信支付"）、空格（"credit card"）或斜杠（"alipay/v2"），导致后端 switch 或路由匹配失败。
-
name必须全组一致，例如统一为payment_method -
value推荐小写+下划线，如alipay、wechat_jsapi、credit_card_3ds - 第一项加
required，但仅前端约束，后端仍需校验非空 - 禁用
disabled的input来“隐藏”选项——它不会提交，也不参与表单验证逻辑
select 适合 >4 种支付方式，但 value 必须区分上下文
当要支持 PayPal、Apple Pay、货到付款、多种银行卡类型时，select 比堆 radio 更省空间，尤其在移动端。但它不是万能的：iOS 原生下拉体验好，部分安卓 WebView 会忽略 style，且无法自定义箭头。
关键陷阱在于，同一支付渠道在不同场景下需不同 value。比如微信，在公众号内调 JS-SDK 是 wechat_jsapi，小程序里是 wechat_mp，App 内唤起 H5 是 wechat_h5。后端靠这个决定走哪条签名和跳转逻辑。
立即学习“前端免费学习笔记（深入）”；
- 首项用
<option value="" disabled selected>请选择支付方式</option>，配合required - 不要给
<option>加class或style——浏览器基本不认 - 避免嵌套
<optgroup>，支付方式无天然层级，只会增加 DOM 深度和测试负担 - 如果某选项需动态禁用（如“余额支付”余额不足），用 JavaScript 控制
disabled属性，而非移除<option>
表单提交前必须禁用按钮 + 显示 loading，且不可绕过验证
点击“确认支付”后若没视觉反馈，用户会反复点击，造成重复下单；若跳过前端验证直接发请求，后端可能收到金额为负、卡号乱填等非法数据，徒增风控压力。
金融类表单对状态控制更敏感：金额字段不能被用户手动修改（需只读或禁用），支付方式选择后，关联字段（如银行卡号、持卡人姓名）才应激活；切换支付方式时，要清空或重置关联字段，防止旧数据残留提交。
- 提交瞬间禁用
<button type="submit">，并替换文案为"支付中..."或添加 SVG loading 动画 - 金额类
<input>设readonly或disabled，禁止用户篡改；若需展示，用<output>或<span>配合 JS 更新 - 监听
change事件切换payment_method，触发对应字段显隐/重置逻辑 - 所有校验（格式、长度、必填）必须在
submit事件中再执行一次，不依赖 blur 或 input 实时校验
严禁在前端模拟“支付成功”，状态必须由后端或第三方回调驱动
用 onclick 直接弹 alert("支付成功!") 或切换 div 显示 ✅ 图标，等于告诉系统“钱已到账”，而实际银行流水还没生成。订单状态与资金流严重脱节，轻则财务对账失败，重则违反 PCI DSS 合规要求。
真实流程是：表单提交 → 后端创建预订单 → 调用支付宝/微信 SDK 生成支付参数 → 前端跳转或唤起 SDK → 用户完成操作 → 第三方异步通知后端 → 后端更新订单状态 → 前端轮询或监听回调结果页面渲染最终态。
- 提交后页面应进入“等待中”状态（显示加载动画+提示“请勿关闭页面”）
- 不要用
window.location.href跳转伪造回调页，第三方不会信任这种跳转 - 回调地址必须是 HTTPS，且由后端严格校验签名、订单号、金额一致性
- 前端唯一能做的“成功”反馈，是收到后端明确返回的
{ status: "paid", order_id: "xxx" }后才展示结果
支付方式结构看着简单，但 name/value 对齐、上下文区分、状态同步、回调可信链这四点，任一环节出错都会导致资金流中断或账务异常。别让一个 radio 没设对 name，变成凌晨三点的线上事故。
