input元素默认不触发paste事件，因其粘贴行为是静默支持的，仅textarea和contenteditable元素可靠触发；检测粘贴应监听input事件并比对值变化，精准区分需结合paste事件（textarea）与剪贴板读取，input上inputType不可用。
input 标签本身不触发 paste 事件，必须用 addEventListener 显式监听，且不能依赖 onpaste 属性或 change/input 混用。
为什么 input 元素默认不响应 paste 事件
浏览器对 <input type="text"> 的 paste 行为是“静默支持”的：只要没设 disabled 或 readonly，Ctrl+V 就能直接粘贴。但这个过程不派发 paste 事件——这是历史兼容行为，和 <textarea> 或 contenteditable 不同。
-
paste事件只在<textarea>和启用了contenteditable的元素上可靠触发 -
<input>在 Chrome/Firefox/Edge 中多数情况下不会触发paste，Safari 更是明确不支持 - 试图写
<input onpaste="handler()">会静默失败，控制台无报错但逻辑不执行
检测 input 中粘贴动作的唯一可靠方式：监听 input 事件 + 状态比对
因为粘贴必然导致值变化，而 input 事件能捕获所有用户主动输入（包括粘贴、拖放、语音、emoji 上屏），所以它是实际可用的兜底方案。
- 必须监听
input，不是change（失焦才触发）或keyup（漏掉粘贴） - 记录上一次
value，在input回调里对比当前值长度或内容差异 - 若变化量明显（比如从 0→10+ 字符），大概率是粘贴；若变化小（±1），更可能是按键
- 移动端需注意：iOS 软键盘“粘贴”按钮也会触发
input，无需额外处理
想精准区分粘贴和其他输入？别依赖 inputType
InputEvent.inputType 在 <input> 上基本不可用：Chrome 和 Firefox 对它返回 insertText 或空字符串，Safari 则完全不支持该属性。
立即学习“前端免费学习笔记（深入）”；
- 不要写
if (e.inputType === 'insertFromPaste')—— 这在<input>上永远不成立 - 即使在
<textarea>上，inputType也存在降级：右键粘贴可能报insertText，而非预期的insertFromPaste - 真正稳定的做法是组合判断：
paste事件（仅用于<textarea>） +input事件（通用） + 剪贴板读取 fallback（如需内容预检）
如果非要在 <input> 上拦截粘贴内容，只能降级到 <textarea>
没有绕过限制的 hack。想获取粘贴文本、做过滤、防 XSS 或格式清洗，唯一可工程化的方式是换用 <textarea> 并监听其 paste 事件。
-
event.clipboardData.getData('text/plain')在<textarea>的paste回调中 100% 可用 - 用 CSS 把
<textarea>样式伪造成单行输入框（height: 1.2em; resize: none; overflow: hidden;） - 粘贴后手动插入处理后的文本，并同步更新关联的隐藏
<input type="hidden">供表单提交 - 避免用
document.execCommand：已废弃，且在现代浏览器中可能失效
最常被忽略的一点：很多开发者花时间调试 onpaste 属性或 inputType，却没意识到问题根源是 HTML 元素语义限制——<input> 就不是为可编程粘贴设计的。接受这个事实，换用 <textarea> 是成本最低、稳定性最高的解法。
