前段时间做活动营销页的时候运营提了个需求下单页输入优惠券码输入框下方要实时显示一行提示文案比如“该券仅限新用户使用”“当前订单金额未达到券门槛”“券码有效期至本月底”。文案不固定要后端根据用户身份和订单金额动态下发。第一反应是找个现成的 Form 组件套一下但那个项目里的表单组件版本很老自定义插槽渲染方式各种别扭后来干脆用原生 div 手写了一个表单项。这篇就聊聊这个“优惠券提示文案表单项”从设计到落地的完整过程以及为什么在这种场景下原生 div 反而是更省事的选择。如果你也在做类似的自定义表单项或者想了解原生 div 写表单的边界和坑这篇应该能给你一些参考。1. 先想明白这个表单项到底要解决什么问题1.1 需求场景还原优惠券输入看起来是个小事但拆开之后痛点不少。用户在下单页找到一个“优惠券”入口点开之后可能是一个输入框加一个“使用”按钮也可能是一个整行可点击的区域。不管交互长什么样核心诉求都一样用户输入一串优惠券码系统要判断这串码当前能不能用。能用就给用户一个正向反馈不能用得告诉用户为什么不能用不然用户一脸懵转头就去找客服投诉。难点在于“为什么不能用”这个信息不是一个静态文案能覆盖的。优惠券的有效期、适用商品类目、最低消费金额、用户身份限制、是否与其他优惠叠加任何一个条件不满足提示文案都不一样。更麻烦的是有些限制条件是用户把券码输完、提交到后端之后才能返回的比如“该券已被领取完”“该券与当前活动互斥”。这种情况下表单项就不只是一个输入框加一行固定提示而是一个需要承载动态状态的交互单元。我当时接到的需求里文案内容本身由后端接口返回前端只负责展示和触发。这听起来像是“端了个土豆”的活儿但真正写起来才发现光是“什么时候展示、什么时候隐藏、展示成什么样式”就能抠出不少细节。1.2 为什么不用组件库的 Input 和 Form.Item团队其实有现成的组件库Element 和 Ant Design 都有用过。按理说用一个 Form.Item 包一层 Input再写个自定义校验规则不就能出提示文案了吗理论上可以但实际会遇到几个问题。第一组件库版本锁定之后自定义 slot/render 的写法会被限制得很死。有些版本的 Form.Item 对自定义控件的校验触发时机和 value 同步有自己的约定你想在输入过程中实时校验需要额外处理 validator 的触发条件代码绕来绕去。第二组件库自带的错误提示样式通常默认显示在输入框下方位置、颜色、动画都是定死的。我们要的提示文案不是“红色错误文字”一种状态还有灰色提示、蓝色加载中、绿色成功状态不同状态对应不同图标。用 Form.Item 的 validateStatus 去硬套也不是不行但为了四种状态去改组件库的样式变量收益远没有想象中高。第三也是最现实的一点项目里如果只是为了一个表单项去升级或者引入完整的组件库那有点杀鸡用牛刀。很多内网后台项目其实已经积累了各种“祖传”写法有 jQuery 时代的有原生 JS 的组件的版本兼容问题能让你排查一下午。与其去适配组件库的脾气不如直接用原生 div 搭一个轻量的表单项样式和逻辑都自己控制不依赖任何框架。当然这个选择有个前提表单校验逻辑不复杂没有大量联动字段。如果是一个完整的报名表单、订单表单字段十几个、校验规则几十条那还是老老实实用成熟表单库。单一字段、动态文案、需要高度定制视觉这才是原生 div 的舒适区。2. 整体设计与交互拆解2.1 表单项的视觉结构与布局层级写代码之前我习惯先把视觉和交互状态画出来。这个优惠券提示文案表单项从视觉上可以拆成三个部分输入容器、提示文案区、辅助图标区。输入容器是整个表单项的主体包括一个文本框和一个“使用”按钮。文本框本身可以是一个真正的 input 元素也可以是一个 div 模拟出来的占位区。这里有个小细节即使用原生 div 搭建结构我也建议内部还是老老实实放一个 input 元素而不是用 contenteditable 的 div 模拟输入。原因后面会在可访问性部分详细说简单讲就是输入体验、键盘交互、移动端唤起数字键盘这些事浏览器对 input 的原生支持是任何 DIY 方案都比不上的。提示文案区是重头戏它在输入容器的下方负责展示动态文案。这个区域可以分成两行来看第一行是主提示文案比如“您可使用一张平台券最高抵扣 50 元”第二行是辅助链接或附加说明比如“查看可用优惠券”“去领券中心”。有时候只要一行大部分时候一行就够了但设计上要预留第二行的空间。辅助图标区通常嵌在输入框右侧比如“加载中”的旋转图标、“校验通过”的对勾、“校验失败”的感叹号。图标不单独占一行而是覆盖在输入框内部这是为了保持视觉紧凑。2.2 提示文案的四种状态与切换时序设计上我定义了四种状态默认态、加载态、成功态、失败态。默认态出现在用户还没有输入任何内容的时候提示文案可以是静态的引导语比如“请输入正确的优惠券码”。如果优惠券码是固定格式的比如大写字母加数字这里也可以直接写成“券码由大写字母和数字组成不需要输入空格”提前帮用户规避低级错误。加载态出现在用户输入完券码并点击“使用”按钮之后前端把券码传给后端等待返回结果的这段时间。此时提示文案区一般显示“校验中请稍候”右侧图标转圈。加载态的核心作用是给用户一个信号——系统正在处理别反复点按钮。成功态和失败态对应后端返回的不同结果。成功态不一定是绿色对勾加“使用成功”更常见的做法是提示“已使用优惠券立减 50 元”并把输入框置灰、按钮改成“已使用”防止用户再次提交。失败态则要具体说明失败原因比如“该券码已过期”“该券码仅限新用户使用”红色字体加感叹号图标。这里想强调一个容易忽略的点状态切换的时序比状态本身更重要。校验接口还没返回的时候你不能把上一轮的失败文案留着也不能直接清空让用户以为是自己删了输入内容。正确做法是进入加载态时不改输入框的内容只替换提示文案区的内容同时给加载图标加上淡入动画这样用户能感知到“我提交的内容还在系统在处理”。3. 一步步实现HTML 结构、CSS 细节与交互逻辑3.1 HTML 骨架与无障碍属性先给出一份简化但完整的 HTML 结构。需要注意这里的代码是基于我实际项目改造过的去掉了业务字段只保留核心骨架。div classcoupon-field idcouponField div classcoupon-input-wrap label classcoupon-label forcouponInput优惠券/label div classcoupon-input-box input typetext idcouponInput classcoupon-input placeholder请输入优惠券码 autocompleteoff maxlength20 aria-describedbycouponHint aria-invalidfalse / span classcoupon-status-icon idcouponStatusIcon aria-hiddentrue/span /div button typebutton classcoupon-submit idcouponSubmit使用/button /div div classcoupon-hint idcouponHint rolestatus aria-livepolite span classcoupon-hint-text idcouponHintText请输入正确的优惠券码/span /div /div说几个关键点。input 的aria-describedby指向提示文案的容器 id这样屏幕阅读器会把提示内容关联到输入框上rolestatus和aria-livepolite的作用是让动态更新的提示文案能被读屏软件及时播报同时不打断当前操作。aria-invalid会根据校验状态在 JS 里动态切换失败的时候置为true。很多人写原生 div 表单项的时候容易把 label 和 input 的关联做丢要么没有 label要么用 div 代替 label。这里用真正的 label 元素for 指向 input 的 id点 label 的时候 input 会自动聚焦这个体验成本几乎为零但收益很明显。3.2 CSS 细节聚焦态、错误态、加载动画CSS 部分我不打算贴全部代码只讲几个我实际调试中花时间最多的细节。首先是输入框的边框和聚焦态。为了让原生 div 写的表单项看起来不像“半成品”聚焦态的反馈必须做好。我的做法是默认边框颜色用浅灰#d9d9d9hover 的时候加深一点聚焦的时候用一个偏品牌色的描边同时加一个 2px 的 box-shadow 向外扩散形成光晕效果。这个光晕的颜色要和成功态、失败态联动比如失败态时聚焦光晕是浅红色这样用户即使没有仔细看提示文案也能通过边框颜色感知错误状态。.coupon-input:focus { outline: none; border-color: #3b82f6; box-shadow: 0 0 0 2px rgba(59, 130, 246, 0.2); } .coupon-field.is-invalid .coupon-input:focus { border-color: #ef4444; box-shadow: 0 0 0 2px rgba(239, 68, 68, 0.2); }其次是提示文案区的过渡动画。我不建议用 display: none 和 block 直接切换因为生硬而且会让人感觉文案是“弹出来”的而不是“长出来”的。建议给提示文案容器设置一个最大高度和 opacity 的过渡并加一点位移效果让文案出现的时候有一个轻微的下滑感。这类细节不会直接影响功能但对整体质感的提升很明显。再次是加载图标的旋转动画。我用的是一个独立的 span塞一个 SVG 圆弧进去通过 CSSanimation: rotate 0.8s linear infinite让它匀速旋转。这里有个小坑如果 SVG 的宽高和视口没有显式设置某些浏览器会按默认的 300×150 渲染图标会大得离谱。务必给图标容器和 SVG 都设置宽高或者用 CSS 强制覆盖。最后是输入框整体的宽度控制。优惠券输入场景通常出现在订单确认页或结算侧栏空间不会特别宽。我给输入容器设置了 flex 布局input 部分 flex: 1按钮宽度固定这样不管外层容器宽度怎么变按钮不会挤压变形。3.3 JavaScript 交互逻辑校验时机、节流与状态切换交互逻辑是整个表单项最核心的部分也是最容易出 bug 的地方。我先把核心逻辑拆成几个函数校验入口validateCoupon、状态切换setFieldState、文案更新updateHint。const field document.getElementById(couponField); const input document.getElementById(couponInput); const submitBtn document.getElementById(couponSubmit); const hintText document.getElementById(couponHintText); const statusIcon document.getElementById(couponStatusIcon); let currentState default; // default | loading | success | error let timer null; function setFieldState(state, message) { currentState state; field.classList.remove(is-default, is-loading, is-success, is-error); field.classList.add(is- state); hintText.textContent message; if (state error) { input.setAttribute(aria-invalid, true); } else { input.setAttribute(aria-invalid, false); } } function handleSubmit() { const code input.value.trim(); if (!code) { setFieldState(default, 请输入正确的优惠券码); return; } setFieldState(loading, 校验中请稍候…); if (timer) clearTimeout(timer); // 模拟接口请求实际项目中这里应该调用真实的校验接口 timer setTimeout(() { const result mockValidate(code); if (result.valid) { setFieldState(success, result.message); submitBtn.disabled true; input.disabled true; } else { setFieldState(error, result.message); submitBtn.disabled false; input.disabled false; } }, 800); } submitBtn.addEventListener(click, handleSubmit); input.addEventListener(keydown, (e) { if (e.key Enter) { e.preventDefault(); handleSubmit(); } });这段代码有几处是从实际踩坑里得出的经验。第一输入值为空时的处理。运营最开始希望在用户没有输入任何内容时也显示“请输入优惠券码”我当时觉得这有点多余因为 placeholder 就是干这个的。但实际上手之后发现当用户删掉了已输入的券码、但焦点还停留在输入框时提示区如果不恢复默认文案会一直保留上一次的失败信息体验非常奇怪。所以建议在 input 的 input 事件里监听一旦发现输入框空了就主动切回默认态。第二按钮的禁用状态。进入加载态之后按钮不能无限点击。我这里用timer控制模拟请求真正项目中应该用一个isRequesting布尔值把重复提交拦截掉或者直接 disabled 提交按钮。这里没有直接 disabled 按钮是因为产品希望加载状态下按钮不可点但视觉上不能“灰”得太明显所以我用了类名控制样式同时在逻辑里做了拦截。第三成功态的处理。成功之后输入框和按钮都 disabled这个操作在表单提交时很重要。如果不禁用用户可以在拿到成功反馈后再改输入内容那样表单数据和界面状态就会不一致。真实项目里成功态之后你往往还需要把优惠券信息同步给父组件或提交给结算接口这个同步动作也建议在成功态触发而不是在按钮点击时就触发避免后端还没确认就提前一步。下面再补一个简化版的 mock 校验函数方便你运行整个例子时有个完整的参考function mockValidate(code) { return { valid: code WELCOME2024, message: code WELCOME2024 ? 已使用优惠券立减 50 元 : 该券码不存在或已失效 }; }4. 原生 div 写法的边界事件、校验与可访问性4.1 事件绑定与动态文案的时序竞争用原生 div 写表单项最容易被忽视的问题是事件绑定的生命周期。组件库帮你处理了组件卸载、事件解绑这些事但原生写法全靠自觉。如果这个表单项是动态渲染进页面的比如用户点了“添加优惠券”才出现那你要小心在容器销毁时把事件监听、定时器、未完成的请求回调都清理干净否则会出现“组件已经消失了但 setTimeout 还在执行”的经典 bug轻则控制台报错重则你试图去更新一个不存在的 DOM 节点行为不可控。我习惯的做法是如果项目里用了 jQuery就统一用$(container).on(click, .coupon-submit, handler)这种事件委托写法容器销毁时不用手动解绑单个事件如果项目是 React 或 Vue 里嵌原生 div就在组件的卸载生命周期里 clearTimeout、abort 请求。另一个容易踩坑的是时序竞争。用户输入券码 A点击校验还没等结果返回用户又把输入框改成券码 B 点了校验。这时候 A 的请求和后返回、B 的请求先返回界面最终显示的可能是 A 的结果但输入框里是 B 的内容。解决办法是在发起新请求时给请求加上序号或者在发起新请求时记录一个 token返回结果后对比 token 是否还是当前这次请求的不是就直接丢弃。我这边的代码里用timer超时模拟其实没有完全规避这个问题如果接真实接口务必加上这个防护。4.2 表单提交时的校验时机优惠券表单项很少是孤立的通常都在一个大表单里比如结算页面有收货人、地址、优惠券三个区块。这里涉及一个关键问题整个表单提交时优惠券这块的校验应该在什么时候触发我见过不少实现是用户点击“提交订单”按钮时把表单里所有字段统一校验一遍优惠券也在其中。这很容易出问题因为优惠券的校验是异步的而且有“输入内容为空”和“输入内容无效”两种不同状态。你很难保证整个表单提交时优惠券的校验已经完成。更合理的时机是优惠券输入框失焦时做一次轻量校验如果格式明显不对比如只输入了三个字符前端可以直接提示“券码格式不正确”不需要发请求如果格式看起来对再发请求走后端校验。当用户点击整个表单的提交按钮时优惠券区域如果有未完成的校验要么先拦下来等校验完成要么明确提示用户优惠券状态还在确认中。千万不要把优惠券的异步校验和整个表单的同步校验混在一起否则你会调试到怀疑人生。我自己的项目里还加了一个细节如果用户在优惠券输入框里输入了内容但从未触发校验表单提交时会在优惠券区域显示“请先点击使用按钮完成校验”。这个提示可以避免用户以为自己填了就完事结果优惠券压根没有生效最后订单金额和他预期不符只能来投诉。4.3 可访问性与键盘操作兜底前面提到我用原生 input 而不是 contenteditable div 模拟输入这里展开说说。contenteditable 在移动端的表现差别很大有些浏览器会弹出普通键盘有些会莫名带格式键盘焦点管理也很乱回车换行没法天然禁止读屏软件对 contenteditable 内容的播报也远不如 input 稳定。所以尽管需求标题写的是“原生 div 写的表单项”我的理解是外层的容器、提示文案、状态图标都可以用 div但“输入”这个动作还是要交给原生 input。这也是我给同行的第一个建议div 模拟的是表单外壳不是输入函数本身。键盘操作方面除了回车触发校验我还建议支持 Esc 键清除当前输入内容。这个不是刚需但加上之后实际体验会好很多尤其是用户输错一串字符想全部重来的时候不用按很多次退格键。读屏方面提示文案容器的aria-livepolite覆盖了大部分场景但注意不要在加载态频繁更新文案比如不要 200 毫秒更新一次“校验中”这样读屏会连续播报体验极差。加载态的文案只在进入加载状态时更新一次即可。5. 常见问题速查与排查技巧5.1 典型问题清单写这个表单项的过程中我遇到的典型问题整理成了一张表方便你对照排查。现象可能原因解决思路提示文案不更新动态更新的 div 没有设置aria-live或者类名没切换成功检查setFieldState是否清掉了所有旧状态类名再确认提示文案容器引用是否正确点击“使用”按钮没有反应按钮事件没绑定成功或者按钮被 loading 态盖住了检查事件绑定是否在动态渲染之后执行按钮是否有 z-index 遮挡问题加载图标不旋转SVG 或图标容器尺寸异常给图标容器和 SVG 显式设置 width 和 height确认 animation 有施加到正确的元素输入框失焦后提示文案还停留在失败态没有监听空值场景并切回默认态在 input 的 input 事件里判断输入为空时调用setFieldState(default, ...)页面里多个优惠券表单项互相干扰给多个字段用了相同的 id 或复用了一个全局状态每个表单项用唯一的 id 或使用事件委托时记录当前操作的目标元素实际接口校验返回之后文案错位异步请求返回顺序和用户操作顺序不一致用请求序号或 token 机制丢弃过期请求的返回结果屏幕阅读器不播报校验结果aria-live容器没有在初始渲染时挂在 DOM 上确保提示文案容器在页面加载时就存在不要用 JS 动态创建后再塞进 DOM5.2 两个实用的调试技巧最后分享两个我实际用下来效率很高的调试方法。第一个是状态类名可视化。我会在全站开发模式下加一小段 CSS把is-loading、is-success、is-error这类状态类的背景条打到输入框区域这样不用看控制台也能直观知道当前状态是不是按预期切换了。调试完成后删掉即可。原理不复杂状态切换本质还是 class 的增删能可视化 class 就等于可视化状态流。第二个是请求时序复现。遇到“文案和输入内容对不上”这种概率性 bug我会在 mock 校验接口里加一个随机延迟让不同请求的返回时间交错。比如第一次请求固定 300ms 返回、第二次请求 1500ms 返回很快就能复现出结果错乱的问题然后再去验证自己加的保护逻辑是否生效。这个方法对所有异步校验的表单都适用不只是优惠券场景。5.3 什么时候应该回头用组件库写完这么多还是得泼一盆冷水。原生 div 写表单项确实自由但也有代价。如果你发现自己的需求开始往这几个方向发展我的建议是回头用组件库或者自封装一个完整组件而不是继续在原生的路上越走越深。判断标准很简单第一这个表单项开始被其他业务模块复用时比如运营后台有好几个页面都要用到优惠券输入那就别再复制粘贴原生代码了应该抽成一个组件第二你需要支持表单重置、批量校验、提交前动态加字段等复杂表单能力时这些能力组件库已经封装好了自己重新铺轮子的成本远高于收益第三团队里其他前端对这种原生写法的维护意愿不高那你一个人留一堆原生代码对团队是一种负担。我在这个项目里的取舍是单个页面、单一字段、视觉定制要求高所以选择原生 div 快速落地但如果后续运营提出要在这个基础上再加一个“优惠券叠加”功能让用户同时输入多张券我大概率会把这部分逻辑抽成一个独立组件内部可能还是原生 div 写法但对外提供清晰的 props 和事件接口。这个表单项上线之后运营反馈最明显的是用户因为“券码无效”来咨询客服的数量减少了一截。说到底是提示文案变具体了把“为什么不能用”这件事讲清楚了。从我个人的体会来说原生 div 写表单项不是什么高深技术但它在“自由度”和“可控性”上的优势恰恰是组件库在某些边界场景下给不了的。如果你也遇到类似需求大胆用原生方案去试但在动手之前先把状态切换时序和异步请求竞态这两个问题想明白能省不少回头改 bug 的功夫。
