语音输入后表单验证未触发，因原生语音输入不派发input/change事件；需在speechend回调中手动dispatchEvent('input')并调用reportValidity()校验，同时兼容iOS/Safari等不支持webkitSpeechRecognition的场景。

语音输入后表单验证没触发？因为 speech 不会自动触发 input 或 change 事件

浏览器原生语音输入（webkitSpeechRecognition 或 speech 输入法）填入 <input> 后，不会像键盘输入那样触发 input 事件，导致依赖该事件的验证逻辑（比如实时校验、checkValidity() 调用）直接失效。

• 手动点击麦克风按钮启用语音识别，说完后文本“跳”进输入框，但 DOM 事件监听器完全收不到信号
• change 事件更靠后，只在失焦时触发，无法支持实时反馈
• 部分安卓 Chrome 或 iOS Safari 的语音输入甚至绕过 input 元素的原生行为，直接修改 value 属性却不派发任何事件

必须监听 speechend 并主动调用

dispatchEvent(new Event('input', { bubbles: true }))</H3>
<p>原生语音识别 API（<code>webkitSpeechRecognition

）提供了 speechend 回调，这是唯一可靠的时机——用户说完、识别完成、值已写入 input.value，此时主动补发一个标准 input 事件，才能让表单验证链路继续跑下去。

• 不能只靠 result 事件：它可能多次触发（中间结果），而 speechend 是最终确定态
• 必须设置 { bubbles: true }，否则事件无法冒泡到父级表单或框架绑定的监听器
• 别漏掉 input 的 type="text" 或 type="search" ——某些浏览器对非文本类型不响应语音输入

const recognition = new webkitSpeechRecognition();
recognition.onend = () => recognition.start();
recognition.onspeechend = () => {
  const input = document.getElementById('my-input');
  input.dispatchEvent(new Event('input', { bubbles: true }));
};

required 和 pattern 属性能用，但得配合 reportValidity() 主动检查

HTML5 原生属性如 required、pattern、minlength 本身是声明式的，它们只在表单提交或显式调用 checkValidity()/reportValidity() 时生效。语音输入后不触发提交，也不自动校验，所以必须人工介入。

htmlppt.skill

把任意文章或文档内容转换成精美的全屏翻页 HTML 演示文件（幻灯片风格）。当用户发来一篇文章、文档链接、Markdown 内容、或粘贴的文本，并且希望生成演示用的 HTML 时触发。支持任意内容来源：iWiki 链接、KM 链接、本地文件路径、直接粘贴的文本。生成的 HTML 文件保存到本地工作区，并通过企微直接发送给用户。触发词示例：帮我把这篇文章做成PPT、转成演示文档、生成HTML幻灯片、做个演示、转成可以演示的格式、article to deck、make a slide。

下载

• 不要等用户点提交按钮才报错——语音填完就该立刻反馈，用 reportValidity() 显示原生提示气泡
• pattern 正则注意兼容性：webkitSpeechRecognition 返回的文本可能带空格或换行，建议先 .trim()
• 如果用了第三方库（如 Formik、React Hook Form），它们通常不监听 speechend，需在 onspeechend 里手动触发 trigger() 或更新字段状态

iOS Safari 和部分安卓 WebView 对 webkitSpeechRecognition 支持极差

这不是代码写得不对，而是平台限制：iOS Safari 完全不支持 webkitSpeechRecognition，很多安卓定制 WebView（如微信内嵌页）也禁用或阉割了该 API。这时候所谓“语音输入”其实是系统键盘自带的语音按钮，行为不可控，也无法监听。

立即学习“前端免费学习笔记（深入）”；

• 检测方式很简单：typeof webkitSpeechRecognition === 'undefined'
• fallback 方案只能是隐藏语音按钮 + 提示“请使用系统键盘语音输入”，并放弃事件劫持和自动校验
• 别尝试用 input 的 oninput 监听变化——系统语音输入不保证触发它，尤其在快速连续输入时

语音输入的验证断点不在逻辑层，而在事件链最前端；补事件、补校验、补降级，三者缺一不可。最容易被忽略的是：你以为用户点了麦克风，其实浏览器根本没给你接口权限，连监听的机会都没有。