HTML组件深度依赖注入管理实现方法

先说结论：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 变更或异步加载中悄然断裂。这，才是设计深度依赖管理时最值得关注的核心思路。