课程 284 / 365
78%
正文已完成
L284画出一张可检查的依赖图
从节点、边类型、起点和停止条件交付一张小型依赖关系说明。
画很多连线不等于建模。可用的依赖图必须说明每类节点代表什么、箭头从谁指向谁、遍历从哪里开始,以及遇到重复节点或环时怎样停止。
能把真实依赖问题建成一张含方向、边类型和循环检查规则的图。
核心概念
先把关键判断说清楚
边类型不能含糊
“相关”“依赖”“包含”是不同关系,混在同一种边里会让遍历结果失去含义。
入口决定分析范围
从某服务向下查依赖与从故障组件向上查影响面是两个方向相反的问题。
访问集合防止无限遍历
每访问一个节点就记录其 ID,重复遇到时停止展开并保留发现路径。
案例拆解
定位支付组件故障的影响面
团队只保存一张系统框图,支付 SDK 故障时不知道哪些服务和页面会受影响。
- 01
将页面、服务和外部组件定义为三类节点,调用关系统一为调用方→被调用方。
- 02
从支付 SDK 沿反向边查找所有直接和间接调用方。
- 03
遍历记录已访问节点与路径,发现循环调用时停止并标注。
案例结果
故障影响面能够在数分钟内列出,并且每个受影响节点都有可追溯路径。
提交前练习
现在轮到你
为一个包含至少六个节点的真实系统或流程写依赖图说明。
内容会自动保存在当前设备
查看参考答案与评分标准
参考答案
节点是网页、API、数据库、第三方服务;边 A→B 表示 A 运行时调用 B;问题是数据库维护会影响哪些入口,从数据库沿反向边遍历;重复 ID 停止,最多 8 层,环保留首条完整路径。
评分标准
- 节点类型与实例可区分
- 箭头方向没有歧义
- 分析入口和停止条件齐全
本课收口 · 学习证据
完成,不等于随手打一个勾。
确认阅读、保存练习,再用 30 秒检查和一句话总结留下真实学习证据。
02完成本课练习0 / 4 项必填内容已填写
03通过理解检查约 30 秒
你现在更接近哪一种状态?
完成上面三项后,才能把本课记为已验证。
资料来源
继续核对与延伸阅读
本课内容最近更新于 。
- OpenTelemetry Signals↗official-docs · 核对日期 2026-08-23
- MDN Web Docs↗reference · 核对日期 2026-08-23