html无法直接完成支付，仅能传递支付方式选择信息；真实扣款需后端或第三方sdk（如微信js-sdk、支付宝api、stripe elements）；单选按钮必须统一name、规范value、使用required；select适合选项较多场景；严禁纯前端模拟支付成功；需严格管理支付方式切换时的表单状态。
HTML 本身不能完成支付，它只是负责把「用户选了哪种支付方式」这个信息交出去；真要扣款，必须走后端或第三方 SDK（比如微信 JS-SDK、支付宝 MiniProgram API、Stripe Elements）。别在 <form></form> 里写个 submit 就以为能付款——那只会提交一个字符串。
用 <input type="radio"> 做基础选择，但必须绑定 name 和 value
这是最轻量、兼容性最好、也最容易出错的方式。常见错误是漏掉 name，导致多个单选按钮互不排斥；或者 value 写成中文/空格/特殊符号，后端解析失败。
正确写法示例：
<label> <input type="radio" name="payment_method" value="alipay" required> 支付宝 </label> <label> <input type="radio" name="payment_method" value="wechat_pay"> 微信支付 </label> <label> <input type="radio" name="payment_method" value="credit_card"> 银行卡（需跳转网关） </label>
-
name必须一致，否则不是“单选组” -
value推荐用英文下划线命名，避免空格、中文、/、.等字符 -
required属性可防止表单无选择就提交，但仅前端校验，后端仍需兜底 - 不要用
<div> 包 <code><input>后再加样式——语义丢失，屏幕阅读器可能读不出选项关系用
<select></select>+<option></option>适合移动端或选项较多时当支付方式超过 4 种（比如含境外卡、PayPal、货到付款等），
<select></select>更节省空间，iOS/Android 原生下拉体验也更稳定。但注意：部分安卓 WebView 对select样式支持差，且无法用 CSS 精确控制下拉箭头。关键点：
- 首项建议设为
<option value="" disabled selected>请选择支付方式</option>，并配合required - 不要给
<option></option>设置style或 class——多数浏览器会忽略 - 如果后端要求区分“微信公众号”和“微信小程序”，
value必须不同，例如wechat_mpvswechat_jsapi - 避免在
<select></select>中嵌套<optgroup></optgroup>—— 支付方式一般无层级，反而增加 DOM 复杂度和测试成本
禁用纯前端 JS 模拟“支付成功”提示
有人用
onclick直接触发alert("支付成功！")或切换 div 显示“✅ 已付款”，这极其危险。用户没真付款，订单状态却变成已支付，财务对不上账是小事，合规风险才是大问题。真实流程必须包含：
- 用户选择后，JS 收集
payment_method值，连同订单号、金额等，通过fetch发送给后端 - 后端调用支付渠道接口（如微信统一下单），返回预支付 ID 或跳转链接
- 前端根据返回结果：跳转 H5 支付页 / 唤起微信 App / 渲染 Stripe CardElement / 显示二维码
- 支付结果由渠道异步通知后端（notify URL），前端轮询或监听回调事件更新 UI
也就是说：
document.querySelector('[name="payment_method"]:checked')?.value只是起点，不是终点。最容易被忽略的是「支付方式变更后，已填的银行卡号/手机号是否清空」——比如用户先选微信，又切到信用卡，但之前微信的 openid 还留在 hidden input 里，后端一并提交可能导致签名失败或渠道拒单。这类状态管理必须显式处理，不能靠 DOM 自动清理。
- 首项建议设为
