浏览器中es模块循环依赖不会报错但会导致白屏和静默失败，表现为network中js文件200却无执行、import() promise pending、注释某import后恢复；唯一解法是重构抽离公共逻辑，且需更新url清除模块缓存。
循环依赖在浏览器里不报错，但会“卡住”
ES模块的循环依赖不会像Node.js那样抛出ReferenceError，也不会在控制台显示明确错误。它发生在模块图构建阶段——浏览器解析完所有import语句后，发现A→B→A这样的闭环，就停止实例化，后续代码根本不执行。结果往往是页面白屏、功能失灵、控制台静默，Network面板里JS文件明明200了，却没任何console.log输出。
最可靠的验证方法：三步定位
别猜，用DevTools快速确认：
- 打开Network面板，过滤
type="module"脚本，看是否全部返回200且size正常；若某个请求完成但没触发任何执行，大概率卡在实例化 - 在Console中手动运行
import('./a.js')，如果Promise一直pending超过5秒，基本可断定存在循环 - 临时注释掉其中一个
import语句，页面恢复渲染，就坐实了循环依赖
真正有效的解法只有结构层面的切断
所谓“加async”“改用import()”“挂到window上”，全都不解决问题本质。ES模块规范不允许运行时绕过静态依赖图。唯一可靠路径是重构：
- 把A和B共用的逻辑抽出来，新建模块C，让A和B都只依赖C
- 避免在模块顶层直接读取对方导出的变量值——它很可能是
undefined，因为求值顺序被循环打断 - 函数声明虽有提升，但
const fn = () => {}这类赋值式定义，在循环中可能根本没执行，不可依赖
模块缓存会让问题更隐蔽
浏览器对模块URL做强缓存，只要URL不变，即使你改了代码、清了HTTP缓存、甚至重开了标签页，旧的模块记录仍留在内存里继续生效。这意味着：修复循环后若没改URL，问题还会复现。务必通过版本号、哈希参数（如utils.js?hash=abc123）或重命名文件来触发新缓存项。
