在标签上误用stopPropagation()会同时阻断跳转和冒泡,根本原因是混淆事件目标与行为意图;应按需分离控制权,仅在子元素中调用stopPropagation()且不阻止默认行为,父容器委托时需判断目标是否为并放行。

直接在 标签上绑定点击事件并调用 stopPropagation(),会同时阻断默认跳转行为和事件冒泡——但多数情况下你并不需要阻止跳转,结果就是链接“点了没反应”,看似失效。
根本原因:混淆了事件目标与行为意图
stopPropagation 的作用是阻止事件向父级传递,它本身不阻止默认行为;但开发者常误以为“加了它就能控制点击”,于是顺手也写了 打开浏览器开发者工具,在控制台执行: document.querySelector('a').onclick = function(e) { console.log('a 被点击了', e); }; 再点一次链接。如果控制台有输出,说明事件确实触发了,问题出在你的处理逻辑里;如果没有输出,说明事件连 不要在 临时移除所有 JS 交互,直接用纯 HTML 测试: 能正常打开,说明问题 100% 出在 JS 层。此时逐段注释掉相关事件监听代码,直到恢复跳转,就能锁定罪魁祸首。return false 或额外调用了 preventDefault(),最终把 href 跳转也一并掐断了。更隐蔽的是:如果在父容器(比如一个卡片 就完全失去响应能力。快速定位是否被误拦截
这一级都没到达——大概率是上层某个父元素用了 event.stopPropagation() 或者 @click.stop(Vue 场景)。修复策略:按需分离控制权
自身或其直系父容器上无差别 stopPropagation。正确做法是:
e.stopPropagation(),且 不调用 e.preventDefault();,是则放行,不是才执行自定义逻辑;@click.stop 在包裹 的 div 上,改用 @click.self 或精确绑定到操作按钮;a 统一绑定了 preventDefault(),尤其注意 CMS 或统计 SDK 注入的代码。验证跳转是否真正可用










