inputtype是inputevent对象的只读属性，仅在input事件中有效，用于标识用户编辑操作类型；它不能设置，仅由浏览器自动报告，且在不同环境和操作下存在兼容性差异。
inputType 不是 HTML input 元素的属性，而是原生 InputEvent 对象上的只读属性，仅在 input 事件中可用。它不能用于静态标记或表单配置，也不能靠设置来“触发”某种动作——它只是浏览器在用户执行编辑操作后，自动报告的类型标识。
为什么 oninput 里拿到的 inputType 总是 'insertText' 或 undefined
常见错误是监听了 change 事件或用错了目标元素（比如绑在 div[contenteditable] 上却没开启 input 事件冒泡）。inputType 只在原生 input、textarea 和启用了 contenteditable 的元素上，于 input 事件中有效。
- 必须监听
input事件，不是keydown或change -
contenteditable元素需确保浏览器支持该事件（Chrome/Firefox/Edge ≥ 79；Safari 16.4+ 才完整支持inputType细分） - 部分操作（如右键粘贴、拖拽插入）在旧版 Safari 中会 fallback 到
'insertText'，而非'insertFromPaste'或'insertFromDrop' - 若用 React/Vue 等框架，注意合成事件可能未透传原生
inputType，需通过event.nativeEvent.inputType访问
区分 deleteContentBackward 和 deleteContentForward 的实际意义
这两个值对应退格（Backspace）和 Delete 键，但行为受光标位置与选区影响。例如：光标在行首按 Delete，实际触发的是 deleteContentForward；而选中一段文字后按任一键，统一为 deleteByCut 或 deleteContentBackward（取决于浏览器实现细节）。
-
deleteContentBackward：退格、Ctrl+Backspace（删词）、Cmd+Backspace（Mac 全删行）都可能归入此类 -
deleteContentForward：Delete 键、Ctrl+Delete（删词）、Cmd+Delete（Mac 全删行）也可能归入此类 - 真正可靠判断“是否删除了内容”的方式是比对
event.target.value（对input/textarea）或getSelection()范围变化（对contenteditable），而非只信inputType - 移动端软键盘的“删除”键在 iOS 上常报
deleteContentBackward，但 Android 厂商定制键盘可能不一致
如何稳定捕获粘贴动作并区分来源
仅靠 inputType === 'insertFromPaste' 并不可靠：用户 Ctrl+V、右键粘贴、拖拽文本、甚至某些剪贴板 API 插入都可能触发它，但 Safari 在 contenteditable 中常降级为 'insertText'。
- 更稳妥的做法是组合监听：
paste事件 +input事件，并用setTimeout延迟检查内容变化（因 paste 后 input 事件有微小延迟） - 在
paste事件中调用event.clipboardData?.getData('text/plain')可提前判断是否纯文本粘贴，避免后续处理富文本 - 若需拦截粘贴逻辑（如过滤 HTML 标签），必须在
paste事件中event.preventDefault()，再手动插入清洗后的内容 -
inputType无法区分“粘贴图片”（如从截图工具拖入），这类操作在contenteditable中通常触发'insertFromDrop'，且无文本数据可读
真正难的不是识别 inputType 字符串，而是理解它只是浏览器“尽力而为”的提示——同一操作在不同上下文（focus 状态、选区、输入法、OS、浏览器版本）下可能产生不同值。依赖它做核心业务逻辑前，务必在目标环境实测所有路径，尤其要覆盖 iOS Safari 和低端 Android WebView。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
