input事件和change事件到底该监听哪个
绝大多数场景下，应该用 input 事件，而不是 change。因为 input 在每次输入（包括键盘、粘贴、自动填充、中文输入法未确认前）都触发，而 change 只在元素失去焦点且值发生改变时才触发——这意味着用户打完字还没点别的地方，你根本收不到更新。
常见错误现象：change 监听下，实时搜索框没反应、表单校验延迟、防抖逻辑失效。
- 中文输入法场景下，
input会在“选词完成并上屏”后触发；若需捕获拼音过程（极少见），得监听compositionstart/compositionend -
input不会触发于type="checkbox"或type="radio"，这类控件仍应使用change - 性能敏感场景（如每键触发 API 请求），必须加防抖，不能只靠事件选择
addEventListener绑定input事件的正确写法
别直接写 oninput 行内属性，也别用 jQuery 的 .on('input', ...)（除非项目已重度依赖 jQuery）。原生推荐用 addEventListener，它支持多次绑定、可移除、语义清晰。
容易踩的坑：监听了父容器却忘了事件委托，或绑在了动态插入的 input 上但没做后续绑定。
立即学习“前端免费学习笔记（深入）”；
- 静态表单：直接对
input元素调用addEventListener('input', handler) - 动态表单（如新增行）：要么在插入 DOM 后立刻绑定，要么用事件委托——但注意：
input事件不冒泡到document外层，只能委托给其最近的静态父容器 - 避免重复绑定：调试时反复执行绑定代码，会导致 handler 被触发多次；可用
{ once: true }或先removeEventListener
input事件在不同浏览器和输入方式下的兼容性
input 事件在现代浏览器（Chrome 58+、Firefox 46+、Safari 10.1+、Edge 79+）中行为一致，但老版本 Safari 和 IE 完全不支持——IE 只有 propertychange（已废弃）。
使用场景判断：如果项目还需兼容 IE11，就不能只靠 input；如果目标是移动端或现代桌面端，放心用。
- Safari 10.0 及更早版本对
contenteditable元素的input支持不完整，但普通input标签没问题 - 移动端软键盘触发粘贴、语音输入、emoji 选择，均会正常触发
input事件 - 自动填充（autofill）在 Chrome/Firefox 中会触发
input；Safari 需要开启autocomplete属性才稳定触发
如何安全读取input事件中的当前值
别在事件回调里用 this.value 或 event.target.value 前不加判空——DOM 元素可能已被移除，或 event.target 指向了子节点（比如 input 里套了 span）。
最稳妥的方式是显式获取目标元素，并确认类型。
- 始终用
event.target instanceof HTMLInputElement做类型检查，再取.value - 避免直接访问
this.value，因为箭头函数中this不指向元素，且严格模式下可能为undefined - 需要区分空字符串和
null时，注意value永远是字符串，哪怕输入框为空也是''，不是null或undefined
示例：
inputEl.addEventListener('input', (event) => {
if (event.target instanceof HTMLInputElement) {
const value = event.target.value.trim();
// 后续处理
}
});
input事件本身很简单，但真实业务里最麻烦的永远不是绑定动作，而是状态同步时机——比如输入过程中弹出校验提示，又在用户继续输入时被遮挡或没及时消失。这些细节比事件名选择更消耗调试时间。
