onchange 事件不实时，仅在 select 失去焦点且值改变后触发；应通过 e.target.value 获取新值，避免依赖 this 或 state；需用自定义下拉组件实现真正实时响应。
onchange 事件本身不“实时”，它只在失去焦点且值改变后触发
很多人以为 onchange 会像输入框那样每选一次就立刻响应，其实不然。对 <select> 来说，浏览器要等你完成选择（比如鼠标松开、回车确认或 Tab 离开）并判定值确实变了，才会触发。如果你在下拉展开状态下反复用键盘上下键切换选项，onchange 不会反复执行——它只认“最终提交”这个动作。
所以别指望靠它做“每选一个就立刻反应”的交互，除非你接受这个延迟和行为边界。
直接在 onchange 里读 value 最简单，但要注意 this 指向
最常见写法是内联绑定：<select onchange="console.log(this.value)">。这里 this 指向当前 <select> 元素，this.value 就是选中项的 value 属性值。
如果用函数封装，容易犯的错是忘了传参或绑错上下文：
立即学习“前端免费学习笔记（深入）”；
function handleSelect(e) {
console.log(e.target.value); // ✅ 推荐：用事件对象的 target
// console.log(this.value); // ❌ this 可能不是 select（尤其箭头函数或 addEventListener 场景）
}
- 内联写法中
this是可靠的，但可维护性差 - 用
addEventListener('change', ...)更规范，此时必须用e.target.value - 确保
<option>都有value属性；没写的话，value会取 innerText，但空格、换行可能导致意外结果
想“真正实时”响应？改用 click 或 keyup + 检查 focused 状态
如果业务要求一点击选项就立刻响应（比如联动搜索、预加载），onchange 不够用。可行替代方案是监听 click 事件，但得加一层判断：只有当 <select> 处于聚焦态、且点击的是其内部 <option> 时才处理。
更稳妥的做法是监听 input 事件（部分浏览器支持 <select> 的 input，但兼容性差），或者退而求其次——用 mousedown 捕获点击瞬间，再结合 setTimeout 延迟读取（因为 DOM 更新可能异步）：
select.addEventListener('mousedown', () => {
setTimeout(() => {
console.log(select.value); // 此时 value 已更新
}, 0);
});
-
input事件对<select>在 Chrome/Firefox 新版本中可用，但 Safari 仍不支持 - 不要依赖
keyup监听方向键——用户可能不按方向键，或用鼠标快速点选 - 所有“伪实时”方案都绕不开一个事实：浏览器原生下拉控件的交互生命周期不开放给 JS 干预
React/Vue 等框架里别直接碰 onchange，用受控组件逻辑
在 React 中写 <select onChange={handleChange}> 看似一样，但本质不同：value 由 state 控制，onChange 触发时，state 还没更新（需要 setState 后异步生效）。所以想立刻拿到新值，得从事件对象里取：e.target.value，而不是 state 当前值。
Vue 的 @change 同理，v-model 绑定的变量在回调中已是新值，但前提是没手动干预 value 属性或用 :value + @input 混搭。
- 框架里误把
onchange当作“值已更新完成”的钩子，容易引发竞态（比如刚 setState 就发起请求，却用了旧 state） - 服务端渲染（SSR）场景下，首次 hydration 时
onchange可能被忽略，需额外处理初始值同步
change 就够了；真要毫秒级响应，就得换自定义下拉组件——那里才能完全掌控点击、键盘、焦点、DOM 更新的每个环节。 
