推荐用input事件监听+正则/\s|\u3000/g实时清理空格及全角空格，并配合setSelectionRange保留光标位置；禁用change事件，避免失焦才处理导致错误值暂存。
直接用 <input type="text"> 做优惠码输入框没问题，但「能输」不等于「能用」——真正卡住你的是提交前的即时校验、后端联调时的大小写/空格容错、以及用户输错时的友好反馈。下面按真实开发顺序拆解关键点。
怎么让输入框自动过滤空格和全角字符
用户复制粘贴优惠码时，常带前后空格、中文空格（\u3000）或制表符，导致后端比对失败。不能只靠 trim()，得在输入时就干预。
- 监听
input事件，用正则/[\s\u3000]+/g替换所有空白符 - 用
setSelectionRange锁定光标位置，避免用户编辑中间时跳到末尾 - 别用
change事件做清理——它只在失焦时触发，无法阻止错误值暂存
input.addEventListener('input', () => {
const cleaned = input.value.replace(/[\s\u3000]+/g, '');
if (cleaned !== input.value) {
input.value = cleaned;
input.setSelectionRange(cleaned.length, cleaned.length);
}
});
前端校验要不要检查格式（比如 AB12-CX99）
要，但仅作弱提示，不阻断提交。因为格式规则（分隔符、长度、字母数字组合）常由运营后台动态配置，前端硬编码容易和后端不一致。
- 用
pattern属性配合title提示格式，但checkValidity()不强制拦截 - 真正拦截交给后端返回的
error_code: "INVALID_COUPON"，前端只负责展示message - 避免用正则
^[A-Z]{2}\d{2}-[A-Z]{2}\d{2}$校验——实际可能允许小写、无分隔符、或新增 4 位纯数字类型
为什么用 POST 而不是 GET 提交优惠码
GET 会把优惠码暴露在 URL、浏览器历史、服务端 access log 里，既不安全也不利于排查（比如多个用户共用同一串码，日志里全是明文）。
anything-to-html
下载
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
立即学习“前端免费学习笔记（深入）”；
fetch('/api/coupons/apply', { method: 'POST', body: JSON.stringify({ code: input.value }) })- 后端必须验证
Origin或Referer头，防止恶意脚本批量刷码 - 如果前端需要「输完自动校验」，用 POST + 防抖（debounce 300ms），别用 GET 模拟实时查询
后端返回成功后，前端怎么更新价格和按钮状态
别只改 DOM 文本。用户可能反复切换商品、修改数量，优惠状态必须和购物车数据强绑定。
- 后端返回完整订单摘要（含
original_total、discount_amount、final_total），前端用它重算，不自己减法 - 禁用输入框和「应用」按钮时，加
aria-disabled="true"，否则屏幕阅读器用户无法感知 - 清除优惠码要调用独立接口（如
DELETE /api/coupons/active），而不是简单清空 input 值——否则购物车缓存里还记着已失效的折扣
最易忽略的是「优惠码过期但未及时提示」：前端拿到 expires_at 字段后，得用本地时间对比，而不是等用户点击才报错。时间差、时区、系统时间被篡改都会导致误判，所以最终以服务端校验为准，前端只做尽力而为的提前拦截。
