html本身不处理组件依赖，所谓“依赖冲突”是javascript建模错误所致；需延后查询、用data-component-id替代id、检测循环依赖并设5秒超时兜底。
HTML 本身不处理组件依赖，所谓“依赖冲突”根本不是 HTML 的问题，而是你用 JavaScript 建模依赖关系时出错了——比如两个自定义元素互相等待、状态未同步、事件监听时机不对，或者用 id 硬编码绑定导致动态组件 ID 冲突。
customElements.define 里不能查其他组件
在自定义元素的 constructor 或 connectedCallback 开头就调用 document.querySelector('auth-provider') 是常见错误。此时 DOM 可能还没挂载完，或目标组件尚未定义，返回 null 后直接报错或静默失败。
- 必须把查询逻辑延后：用
requestIdleCallback或setTimeout(..., 0)推迟到微任务之后 - 检查目标组件是否已定义：
customElements.get('auth-provider') !== undefined，而不仅是查 DOM - 若未就绪，设
this.setAttribute('data-waiting-for', 'auth-provider')并返回，避免重复执行
data-prereq 不是 selector，是声明式依赖标记
data-prereq="user-avatar,plan-selector" 这种写法容易被误解为 CSS 选择器——它其实只是字符串标识，真正匹配靠的是集中管理器（如 window.$deps）查 dataset.componentId 或 data-component-id，而不是 id。
- 禁止用
id当依赖键：动态渲染的组件可能生成重复id，导致状态覆盖 - 推荐用
data-component-id="dashboard-123abc"，值由crypto.randomUUID()生成 - 下游组件响应
component:ready事件时，只更新data-prereq包含自己的那些节点，不全量扫描
循环依赖检测比强行解耦更实际
A 等 B 就绪、B 又等 A 提供配置，这种死锁不会在控制台报错，只会卡在 pending 状态。靠人工 review 代码很难发现，得加运行时检测。
- 在协调器中维护一个依赖路径栈，每次触发
component:ready前先检查是否已在栈中出现过当前组件 - 检测到循环时，主动降级：比如让 B 忽略 A 的配置，用默认值初始化，再发
component:degraded事件通知监控系统 - 超时兜底必须设：每个等待最多 5s，超时后清空
data-waiting-for并加data-timeout="true"方便调试
最容易被忽略的点是：WeakMap 缓存引用必须和组件生命周期严格对齐——disconnectedCallback 里要手动 weakMap.delete(this)，否则内存泄漏会掩盖真正的依赖问题。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
