原生弹窗（alert/confirm/prompt）同步阻塞主线程，事件被挂起，e.target和e.srcElement均无法获取；必须在调用前保存this或dataset等关键信息。
click 事件里 e.target 和 e.srcElement 都拿不到弹窗按钮？
HTML 原生 alert()、confirm()、prompt() 是同步阻塞式弹窗，执行时 JS 主线程暂停，所有事件（包括 click、mousedown）都被挂起，直到用户点完“确定”才继续。这意味着你根本没法在弹窗显示期间监听或捕获点击源——它压根没发生。
所以不是 e.target 拿不到，而是根本没机会触发事件。常见错误是写成这样：
button.addEventListener('click', () => {
confirm('确定删除？');
console.log('此时 e 已不可用'); // 这里已经没有 event 对象了
});
- 所有原生弹窗都不提供「点击哪个按钮」的回调参数，
confirm()只返回true或false -
e.target必须在事件处理函数第一行就保存，一旦调用alert()等，后续代码里的e就失效或未定义 - IE 下曾支持
e.srcElement，但现代浏览器统一用e.target，两者在原生弹窗场景下都无意义
想区分点击源？必须在弹窗前保存 event 或 this
真正可行的做法，是在调用 confirm() 前把关键信息存下来，比如触发元素的 id、dataset 或引用本身：
document.querySelectorAll('.delete-btn').forEach(btn => {
btn.addEventListener('click', function(e) {
const clickedBtn = this; // 保存 this（即 button 元素）
const actionId = this.dataset.id;
if (confirm(`确定删除 ${actionId}？`)) {
// 此时可用 clickedBtn 或 actionId 做后续操作
api.delete(actionId).then(() => clickedBtn.disabled = true);
}
});
});
- 用
this最稳妥，它指向绑定事件的 DOM 元素，不受闭包或异步影响 - 避免用
e.currentTarget，在事件委托中它可能和this不一致；而e.target可能是子元素（比如按钮里的span） - 如果按钮是动态生成的，优先用事件委托 +
closest()定位源：e.target.closest('.delete-btn')
需要更细粒度控制？换 showModal() 或第三方库
原生弹窗能力有限，真要响应「取消」「确认」「更多选项」且保留上下文，得用现代方案：
立即学习“前端免费学习笔记（深入）”；
-
<dialog></dialog>元素配合.showModal()：支持close事件、可自定义按钮、能访问e.target（因为不阻塞主线程） - 点击「确认」按钮时，直接读它的
dataset.action或父容器属性，无需依赖原始 click 事件 - 第三方库如 SweetAlert2、Toastify 等，回调函数里明确传入触发元素或上下文对象，比硬啃原生弹窗靠谱得多
例如用 <dialog></dialog>：
<dialog id="confirmDialog">
<p>确定删除？</p>
<button data-action="confirm">确定</button>
<button data-action="cancel">取消</button>
</dialog>
confirmDialog.querySelector('[data-action="confirm"]').addEventListener('click', () => {
// 这里可以安全读取 this.dataset.action 或 this.parentElement.dataset.id
confirmDialog.close();
});
容易忽略的关键点：原生弹窗没有「事件源」概念
开发者常误以为 confirm() 返回后还能回溯当时是谁点的——但它不保存也不传递任何上下文。JS 执行流中断后，之前的 event 对象早已被回收，栈帧清空。所谓「获取点击源」，本质是你要自己在中断前把必要信息记下来，而不是指望弹窗帮你留着。
如果你正在调试某个已有的 confirm() 调用并发现 e.target 是 null 或 undefined，不是代码写错了，是时机根本不对。
