先说结论：HTML 本身并不具备深度依赖注入的能力，所有组件间的依赖关系必须通过 JavaScript 显式建模并保持同步——没有任何例外。为什么“纯 HTML 的解法”行不通？因为 DOM 自身缺乏跨组件生命周期管理的能力，无法自动协调多个组件的状态。
customElements.define() 必须封装带依赖声明的组件
Web Components 是目前最贴近原生 HTML 的组件化开发路径，但自定义元素默认彼此隔离，无法自动感知其他组件的状态变化。要实现深度依赖管理——例如 form-step-2 必须等待 form-step-1 提交成功后才能激活——这就要求在组件内部主动暴露状态、监听事件并及时响应变化。
- 每个组件需要定义明确的“就绪信号”，例如通过 dispatch 触发
component:ready自定义事件，或设置data-status="ready"属性 - 需要特别注意的是，在
constructor()里访问document或其他组件是不允许的——此时 DOM 尚未完成附着 - 下游组件应在
connectedCallback()中检查前置组件是否存在、是否满足条件；如果条件不满足，可以借助requestIdleCallback延迟重试，避免因 DOM 未完全挂载而查询失败
data-prereq + window.$deps 实现声明式依赖管理
当组件嵌套层级较深（如 A → B → C → D），或者存在跨层级、非父子关系的依赖场景（例如侧边栏菜单项依赖顶部用户头像组件的状态），单纯依靠事件冒泡或 props 透传很容易导致链路断裂。更稳健的做法是将依赖关系“外置”为声明式标记，再由统一的协调器统一驱动。
- 为需要受控的组件添加
data-prereq="user-avatar,plan-selector"属性，多个 ID 之间用英文逗号分隔 - 使用轻量级状态对象（如
window.$deps = new Map()）记录各个组件的当前状态，而不是反复查询 DOM - 当任意组件触发
statechange事件时，协调器仅更新所有data-prereq中包含该组件的下游组件，从而避免全量扫描造成的性能损耗 - 不建议使用
id作为唯一标识绑定逻辑——因为动态生成的组件可能出现 ID 冲突；推荐改用data-component-id或Symbol键来确保唯一性
避免循环依赖：检测 + 降级比强行解耦更实用
两个组件互相等待对方就绪（例如 A 等 B 初始化，B 等 A 提供配置）是常见的死锁场景。我们可能尝试过用 Promise.all 或 async/await 把所有依赖串联起来。但实践经验表明，这种方式只会掩盖真实的挂载顺序，而且无法应对动态插入的组件。
- 在协调器中加入简易的环检测逻辑，例如记录当前解析链路，当发现重复 ID 时立即触发降级行为（如将状态设为
data-status="degraded"） - 为关键路径设置超时兜底机制：比如
setTimeout(() => { el.setAttribute('data-waiting-for', 'timeout') }, 5000)，防止组件无限等待 - 在调试阶段开启日志输出：检查
window.$deps中各个组件的状态是否被正确写入与更新，便于快速定位问题
真正有挑战的不是写一堆 data-prereq 声明，而是让每个组件都清楚自己“何时才算就绪”以及“谁在等待我”。一旦这个边界变得模糊，整个依赖链就可能在 DOM 变更或异步加载中悄然断裂。这，才是设计深度依赖管理时最值得关注的核心思路。
