h5移动端表单校验中，震动仅用于提交节点的辅助反馈：失败单震120ms，成功双震[8,40,8]；须手势触发、检测兼容性、配合视觉文案协同，并提供开关与降级策略。
在 H5 移动端中，把震动反馈和表单校验提示结合使用，能显著提升操作确认感与错误感知力——但必须注意：震动只是辅助通道，不能替代视觉或语义提示，且受平台限制极多。核心思路是“震动触发有节制、错误提示可接管、失败反馈有层次”。
震动仅用于关键状态变更，且必须用户手势触发
表单校验中的震动不是“每次输入都震”，而是聚焦在明确的用户意图完成节点上：
- 点击「提交」按钮时，若表单未通过校验，触发一次短震（如 navigator.vibrate(120)），模拟“操作被拒绝”的物理反馈
- 用户手动修正后再次点击提交，且最终校验通过，可触发更轻快的双震节奏（如 [8, 40, 8]），表达“成功确认”
- ⚠️ 所有震动调用必须写在
click或touchend事件处理器内，不能放在input、blur或定时器中；iOS 尤其严格，首次震动必须由真实手势激活 - 调用前务必检测：
if ("vibrate" in navigator && typeof navigator.vibrate === "function")，并用返回值判断是否生效（!navigator.vibrate(120)时走降级）
自定义提示文案 + 手动 UI 渲染，绕过不可控的原生气泡
浏览器默认的 validationMessage 气泡无法样式化，也无法与震动同步。应完全拦截，统一控制：
Article To Html
下载
文章转信息图。将文章/笔记转化为手机可读的 HTML 信息图，自动匹配视觉风格。触发场景：文章转图、笔记转图、信息图、转小红书图、做张图、可视化这篇文章、文生图。
- 给每个表单控件绑定
invalid事件，并立即e.preventDefault()阻止原生提示弹出 - 在
submit事件中：e.preventDefault()→ 遍历字段 → 对每个!el.checkValidity()的元素，调用el.setCustomValidity("手机号格式不正确")→ 再调用el.reportValidity()（仅用于触发验证逻辑，不依赖其气泡） - 真正显示的错误信息，写入你预设的 DOM 节点（如
<div class="field-error"></div>），内容取自el.validationMessage - 配合 CSS 使用
:invalid:user-invalid控制边框/图标变色，避免页面一加载就标红未填项
震动 + 视觉 + 文案三者帧级协同
一次有效的错误反馈不是孤立动作，而是组合信号：
- 用户点击提交 → 同步执行：
– 表单字段添加.error类（触发动画缩放+红边）
– 对应错误区域显示中文提示文字
– 紧接着（延迟 ≤ 10ms）调用navigator.vibrate(130) - 若震动失败（返回
false），自动启用视觉强化：错误文字加粗 + 背景轻微脉冲动画（@keyframes pulse） - 所有震动总时长控制在 200ms 内（iOS 安全上限），禁用数组模式（[150,50,150] 在 iOS 直接无效），确保跨设备一致性
- 提供全局开关：设置页中增加「触觉反馈」滑块，用
localStorage记住偏好，关闭后跳过所有vibrate调用
降级策略要自然，不暴露技术断层
当震动不可用时，体验不应打折：
- 震动失败 ≠ 提示消失：仍完整执行视觉高亮 + 自定义文案渲染 + 可选音效（需用户手势后首次播放）
- 对无震动能力的环境（如桌面端、iOS Safari 未激活、后台标签页），自动禁用震动模块，不报错也不静默忽略
- 不要在表单验证失败时只依赖震动——它没有信息承载能力。例如“密码不一致”必须靠文字说明，震动只是强化“这个动作被系统注意到了”
- 测试重点放在真机：Android 各厂商系统（MIUI/EMUI/OriginOS）对震动总时长常有额外截断，建议统一用单值 100–150ms 最稳妥
