radio单选按钮组name必须统一且value规范为英文数字下划线，select适合超4种支付方式，form action须指向后端接口，支付结果必须由后端回调确认，payment_method需白名单校验。

radio 单选按钮组必须统一 name 且 value 要规范

用户选一种支付方式，后端靠 payment_method 这个字段识别——所以所有 <input type="radio"> 的 name 必须完全一致，否则互不排斥，提交时可能没值或多个值。

• value 只能是英文、数字、下划线，比如 alipay、wechat_jsapi、credit_card；不能写 支付宝 或 wechat pay（空格和中文会导致后端解析失败）
• 加 required 可阻止无选择提交，但只是前端提示，后端仍要校验该字段非空
• 别用 <div> 包裹 <code><input> 再加样式，语义断裂，无障碍访问会跳过选项
• 每个 <input> 必须配 <label></label>，点击文字也能选中，提升触控体验

select 下拉菜单适合选项多或移动端优先场景

当支付方式超过 4 种（比如含 PayPal、Apple Pay、货到付款、境外卡），用 <select></select> 更省空间，iOS/Android 原生下拉也更稳定。


Wechat HTML Publisher
直接上传HTML富文本到微信公众号草稿箱。支持完整的HTML格式,无需Markdown转换。
下载
• 首项用 <option value="" disabled selected>请选择支付方式</option>，配合 required 实现必选
• <option></option> 不要加 class 或 style，多数浏览器会忽略，且破坏语义一致性
• 若需区分微信公众号与小程序，value 必须不同，例如 wechat_mp 和 wechat_mini，否则后端无法路由
• 避免嵌套 <optgroup></optgroup>——支付方式一般无层级，徒增 DOM 复杂度和测试成本

表单 action 和 method 别写成空或默认跳转

<form></form> 的 action 不是摆设。写成空字符串 action="" 或漏掉，提交后页面会刷新或 404，根本不会触发真实支付流程。

• 真实场景中，action 应指向后端接口（如 /api/pay/init），由它生成预支付订单并跳转 SDK
• 若走微信 JS-SDK 或支付宝网页支付，method 通常为 POST，且需携带订单号、金额、支付方式等参数
• 严禁把 action 设成 "#" 或 javascript:void(0) 后靠 JS 提交——这会让 form 失去语义，SEO 和无障碍支持受损
• 提交前务必用 JS 检查 document.querySelector('input[name="payment_method"]:checked') 是否存在，否则用户点了“确认支付”却没选方式

禁止纯前端模拟“支付成功”状态

用 alert("支付成功!") 或直接显示 ✅ 成功页，是严重逻辑错误。用户没真扣款，订单状态却变已支付，财务对账和合规审计都会出问题。

• 真实支付结果必须由后端回调通知（如微信的 notify_url、支付宝的 return_url）决定
• 前端最多展示“跳转中…”“请在微信/支付宝 App 中完成操作”，然后轮询订单状态接口，或依赖后端重定向
• 如果用户中途关闭页面，订单应保持“待支付”状态，不能靠 JS 定时器假定超时即失败
• 所有支付方式切换时，要清空上次选中的金额、优惠券、收货地址等关联状态，否则容易提交错数据
实际交付时，最易被忽略的是：后端未对 payment_method 做白名单校验，导致前端传 value="hacker_pay" 也能通过——这个漏洞比 UI 不美观危险得多。