在iframe中对锚点元素进行事件委托时，为何preventDefault()无法单独阻止链接跳转？

这问题挺有意思的，我来帮你梳理下背后的原因，以及为什么必须搭配stopPropagation()才能生效：

1. 事件冒泡到iframe元素后的特殊浏览器行为 #

当你在iframe内部的DOM元素上触发点击事件时，事件会顺着DOM树向上冒泡，最终会到达iframe元素本身，还会继续冒泡到主页面的DOM结构中。

部分浏览器的机制里，当来自iframe内部<a>标签的点击事件冒泡到iframe元素时，会额外执行一次默认行为的校验——哪怕你已经在iframe内部的父元素处理器中调用了preventDefault()，浏览器可能仍会尝试触发跳转。而调用stopPropagation()能直接阻止事件冒泡到iframe元素，切断了这个额外校验的触发路径，从而彻底阻止跳转行为。

2. 特殊环境下默认行为的触发顺序变化 #

理论上，preventDefault()在事件流的任意阶段调用都能阻止默认行为，但iframe属于跨文档的特殊环境，可能存在默认行为触发时机提前的情况：浏览器可能在事件还未完成内部冒泡时，就已经标记了要执行跳转操作。此时你在父元素（ul）的处理器里调用preventDefault()，已经无法取消这个提前标记的跳转动作；只有通过stopPropagation()阻止事件继续冒泡，才能让浏览器取消这个跳转标记。

3. 全局事件对象的潜在干扰（代码笔误的可能性） #

看你的代码里，函数参数是evt，但console.log中写的是event.target.href——如果这不是笔误而是实际代码，可能存在全局event对象的干扰问题。当事件冒泡到主页面时，全局event会被替换为主页面的事件对象，导致你在iframe内部调用的evt.preventDefault()只作用于内部事件对象，而浏览器可能读取全局event的状态来决定是否执行跳转。不过你提到处理器能正常输出href，大概率是笔误，但还是可以排查下这个点。

验证思路 #

• 直接在<a>标签上绑定点击事件，只调用preventDefault()，看是否能阻止跳转。如果可以，说明问题确实出在事件委托+iframe冒泡的组合场景中。
• 在iframe的document上绑定一个捕获阶段的点击事件（设置addEventListener的第三个参数为true），只调用preventDefault()，观察是否能单独生效，这也能验证冒泡阶段的特殊行为。

内容的提问来源于stack exchange，提问作者Stephen Miller