判断用户在哪个input卡住需监听聚焦离开、输入删除、停留无输入三类行为，结合实时校验、规范autocomplete、手动埋点分析，区分真实困难与设计缺陷。
怎么判断用户在哪个 <input> 上卡住了
核心是监听用户行为，而不是猜。浏览器不会主动告诉你“这个字段难填”，得靠你埋点观察真实交互。重点看三类信号：反复聚焦又离开、输入后快速删除、长时间停留在某个字段但无有效输入。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 给每个
<input>绑定focus和blur事件，记录进入和离开时间戳 - 同时监听
input事件，统计字符变化频率（比如 2 秒内删改超 3 次，大概率是输入受阻） - 避免只依赖
change事件——用户没提交就关页，数据全丢 - 注意移动端软键盘唤起/收起会触发多次
blur，需加防抖（比如延迟 300ms 再判定为真实离开）
required 和 pattern 容易引发静默失败
用户没看到报错，但表单就是提交不了——这是最典型的“填写困难”伪装态。浏览器原生校验只在提交时触发，且错误提示位置不统一、样式不可控，很多人根本没注意到红色边框或 tooltip。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 别单独依赖
required。配合aria-invalid="true"和实时setCustomValidity()做前置反馈 -
pattern正则写太严（比如邮箱用^[^\s@]+@[^\s@]+\.[^\s@]+$）会导致粘贴邮箱时被拦截，用户不知道哪里不对 - 移动端慎用
type="number"：iOS 会强制显示数字键盘，但允许输入字母，校验失败时无提示 - 测试时真机输入，别只靠桌面端 DevTools 模拟
Autofill 不工作？先查 name 和 autocomplete
浏览器自动填充不是玄学，它严格匹配字段语义。名字写成 name="user_name" 或漏掉 autocomplete 属性，Chrome/Safari 就当普通文本框处理，连下拉都不弹。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 必须同时设置
name和autocomplete，且值要规范（如邮箱用autocomplete="email"，银行卡号用autocomplete="cc-number"） - 避免用
name="phone_number"这种自定义名，改用标准值name="tel"+autocomplete="tel" - 动态渲染的表单（比如 React useState 控制显隐），确保 DOM 插入时
autocomplete已存在，否则 Chrome 可能忽略 - 密码字段必须成对出现：
autocomplete="new-password"（注册）或autocomplete="current-password"（登录）
第三方 SDK（如 Sentry、Hotjar）怎么抓到真实卡点
它们默认不记录表单交互细节。光看崩溃日志或录屏，看不出用户是在 <select></select> 里找不到选项，还是日期组件年份选不了。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 手动打点：在
blur后立即调用sentryCaptureEvent()，带上字段id、停留时长、是否触发过input - Hotjar 热力图要开启 “Form Analysis”，并确保表单有唯一
id或data-hj-ignore-attributes没误删关键属性 - 避开敏感字段：不要把密码、身份证号等传给分析工具，哪怕只是字段名
- 注意采样率——高流量站点设 10% 就够，否则日志爆炸且掩盖真实问题
最难的不是采集数据，是区分“用户不会填”和“字段设计反人类”。比如把省市区三级联动放在折叠面板里，或者日期组件默认禁用过去日期却没提示，这些得靠人工走查+小范围用户测试才能发现。
