内联 onclick 仅适合极简场景，因无法精细控制事件对象、不支持委托与解绑；应优先用 addEventListener，配合节流、once、Web Worker 等优化 INP 性能。
button onclick 属性绑定的执行时机与局限性
直接写 onclick 属性（如 <button onclick="doSomething()"></button>）会在点击时同步执行函数，但无法拿到原生事件对象的完整信息（比如 event.target、event.preventDefault() 的细粒度控制），也不支持事件委托或动态解绑。
常见错误现象：点击后页面意外跳转、表单重复提交、移动端 300ms 延迟未处理、无法阻止默认行为导致 UI 错乱。
- 只适合极简场景，例如调试用
alert()或无副作用的纯前端跳转 - 若需访问
event对象，必须显式传参：onclick="doSomething(event)" - 不推荐在循环渲染的按钮中使用，会导致大量重复函数定义和内存占用
addEventListener 绑定 click 事件的正确姿势
现代项目应统一用 addEventListener('click', handler) 替代内联 onclick，尤其在需要兼容 INP（Interaction to Next Paint）指标优化时——它能更精准控制交互响应节奏，避免长任务阻塞主线程。
关键点在于：handler 函数应轻量、可取消、不隐式触发重排重绘。
立即学习“前端免费学习笔记（深入）”；
- 避免在 handler 中直接操作 DOM 样式（如修改
element.style.width），改用 class 切换 + CSS 过渡 - 对高频操作（如搜索框按钮）加节流，用
setTimeout或requestIdleCallback延后非关键逻辑 - 使用
{ once: true }选项处理只需触发一次的按钮（如初始化、模态框确认）
INP 场景下按钮交互的性能敏感点
INP 衡量的是用户最慢的一次交互延迟（从点击到视觉反馈完成），而不仅仅是首屏加载。按钮的 click 处理器若执行过久、触发强制同步布局（layout thrashing），会直接拉高 INP 值。
典型踩坑路径：button → 点击 → JS 计算大量数据 → innerHTML 批量更新 → 浏览器重排 → 视觉卡顿。
- 把耗时计算移入
Web Worker，或拆成微任务（Promise.resolve().then(...)）让出主线程 - 避免在事件处理器中读取
offsetHeight、getComputedStyle等触发 layout 的属性 - 给按钮添加
pointer-events: none+ loading class，并在操作完成后恢复，防止重复点击干扰 INP 统计
动态生成按钮时事件委托的实际写法
当按钮由 JS 动态插入（如表格行末尾的操作按钮），不要为每个按钮单独绑定 addEventListener，而是监听父容器的 click 事件并判断目标元素——这既减少内存开销，又天然适配后续新增节点，对 INP 更友好（绑定一次，响应所有）。
示例中父容器是 <tbody id="data-table">，按钮 class 为 <code>action-btn：
document.getElementById('data-table').addEventListener('click', function (e) {
if (e.target.classList.contains('action-btn')) {
const row = e.target.closest('tr');
const id = row.dataset.id;
handleAction(id);
}
});
- 务必用
e.target而非e.currentTarget，否则拿不到实际点击的按钮 - 用
closest()向上查找语义化容器（如tr），比硬编码层级更健壮 - 避免在委托 handler 中做 heavy work；真正耗时逻辑仍要异步化或防抖
