接手一个老项目最痛苦的事情不是代码难写，而是代码"看不懂"。上个月我接手一个内部的中台服务，代码量不大，也就八万行左右，但模块之间的调用关系乱成一锅粥。我想搞清楚"订单模块到底被谁依赖、如果我重构它会影响哪些服务"，结果在IDE里跳来跳去跳了一整天，最后还是靠开会问同事才拼出个大概。就是在那几天，我认真把 codegraph 这种"代码图谱"工具捡起来试了一遍，感触很深：这类工具解决的不是"写代码"的问题，而是"读代码"的问题——把整个仓库的依赖关系变成一个可以查询、可以可视化的图，让"代码地图"这件事不再只存在于资深同事的脑子里。这篇文章就围绕 codegraph，聊聊这类工具的核心原理、实际用法、典型场景和我踩过的坑，给同样被代码库庞大结构困扰的朋友一个可以直接上手的参考。
1. codegraph 要解决的问题：为什么代码一多，IDE 就不够用了
1.1 三个最典型的"代码没地图"场景
第一个场景是接手老系统。你刚入职或者刚接手一个模块，Leader 丢给你一个服务链接，说"你先看看"。你打开仓库，几千个文件铺在那里，从哪个文件开始读？大多数人的做法是从 main 函数或者入口 Controller 往下追，追到第三层就忘记前面是谁调过来的了。第二个场景是改代码之前的影响评估。你接到一个需求："把库存服务里的扣减逻辑改成异步"。你本能地想：哪些地方调用了库存服务？如果改接口，哪些上游要跟着改？靠 IDE 的 Find Usages 确实能列出一堆调用点，但那只是"直接调用"，间接调用、事件通知、配置注入这些关系，IDE 是看不见的。第三个场景是团队的知识沉淀。代码里最值钱的不是语法，而是"为什么要这么设计"和"模块之间到底是什么关系"。但这些知识通常只存在于几个核心开发者的脑子里，没有形成任何可查询的文档，人一走，知识就断层了。
这三个场景本质上指向同一个痛点：代码库的"结构信息"没有被显式建模。代码本身是文本，但代码背后的依赖关系是一张网。IDE 能帮你读单个文件，能帮你跳转单个引用，但它没有把整张网给你铺开。而 codegraph 这类工具做的事情，就是把这张网捞出来，存成一个结构化的图，然后提供查询和可视化能力。这也是"代码图谱（Code Graph）"这个概念越来越受关注的原因——它不是语法分析的新花样，而是把软件工程里的"可读性"从代码行级别提升到了系统架构级别。
1.2 传统手段的边界在哪里
我并不是说 IDE 和 grep 没用，它们依然是日常主力，但它们的边界很明显。
拿 IDE 的跳转来说，它的模型是"从 A 走到 B"。你从调用处跳到函数定义，再从函数定义跳回调用处，这是点对点的导航。但如果你想问"从订单服务到支付服务之间一共有几条调用路径？中间经过了哪些适配层？"IDE 就无能为力了——它能给你一条路径，却给不了全貌。再拿全文搜索来说，grep 一个类名能搜出几百个匹配，其中一半是注释、一半是测试、剩下的是同名不同包的重载。你需要在脑子里手工过滤这些噪音。这种"人肉过滤"在小项目里无所谓，但在模块超过一百个的中大型项目里，它消耗的精力和耐心是惊人的。
还有一类传统手段是架构文档和 UML 图。问题在于文档是静态的，写完的那一刻就过时了。代码每提交一次，文档就失真一分。等到文档跟代码的偏差超过三成，团队里就再没人信文档了。而 codegraph 这类工具最大的优点之一，是它的图谱是从代码本身实时生成的——代码变了，图谱跟着变。它不是一份静态文档，而是一个随仓库演进的活模型。
1.3 codegraph 的解决思路：把仓库变成一张可查询的图
codegraph 的核心思路并不神秘，一共三步：扫描代码、提取符号和依赖、输出图结构数据。所谓"图"由节点和边组成。节点就是代码里的实体——类、函数、接口、模块、文件；边就是实体之间的关系——调用、继承、实现、引用、导入。这样一个结构，既可以用可视化界面去"看"，也可以用查询语言去"问"。
我整理了一个对比表格，直观感受一下它和传统手段的区别：
| 维度 | IDE 点对点跳转 | 全文搜索 | 静态文档 | codegraph 图谱 |
|---|---|---|---|---|
| 信息形态 | 单次跳转 | 文本匹配列表 | 静态图片/文字 | 结构化图数据 |
| 查询能力 | 弱（只看单点） | 弱（需要人肉过滤） | 无 | 强（图查询语言） |
| 全貌感知 | 无 | 无 | 有但不准 | 有且实时 |
| 时效性 | 实时但碎片化 | 实时但噪音大 | 滞后 | 随仓库更新 |
| 学习成本 | 低 | 低 | 低 | 中（需懂一点图查询） |
从表格里能看出来，codegraph 不是替代 IDE 和 grep，它补的是"全貌"和"关系查询"这块空白。如果说 IDE 是显微镜，让你看清局部细节；那 codegraph 就是卫星地图，让你看清整片地形。日常开发可以继续用显微镜，但当你需要规划路线、评估影响范围的时候，必须有一张地图在手。这也是我后来坚持在项目里引入它的原因。
2. 深入内部：codegraph 怎么从源码里"炼"出图谱
这一节讲原理。我不打算讲太深的编译原理，但至少要让你明白 codegraph 生成图谱的几个关键阶段——不然你可能只会跑命令，遇到问题完全不知道从哪里排查，比如"为什么这个函数没有被收录？""为什么边画反了？"。理解了它的工作流程，这些问题就迎刃而解。
2.1 第一阶段：从文件到 AST（语法骨架）
codegraph 做的第一步是把每个源码文件解析成 AST（抽象语法树）。AST 是什么？一句话：代码的结构化表示。你写的代码是一串文本，但编译器或者解析器会把它拆成一棵树——顶层是文件，往下是包、类、函数、变量、语句。这个过程类似你读一个句子：先把一句话切成主谓宾、定状补，然后才谈得上理解这句话的意思。没有这层结构化，代码在机器眼里就是一堆字符串，没法谈"关系"。
codegraph 的扫描器会根据你配置的语言类型选择对应的解析器。比如 Go 项目用 go/parser，TypeScript 项目用 TypeScript compiler API，Python 项目用 ast 模块。这一层解析的意义在于：codegraph 需要拿到代码里的"定义"和"引用"。所谓定义，就是"这里有一个类叫 OrderService、这里有一个函数叫 CreateOrder"；所谓引用，就是"这里调用了 OrderService.CreateOrder"。AST 恰好把这两种东西区分开了——看到func CreateOrder(...)是定义，看到service.CreateOrder()是引用。这一步是所有后续分析的地基。
2.2 第二阶段：符号解析与依赖提取（理解谁在用谁）
拿到 AST 之后，codegraph 进入第二个阶段：把"定义"和"引用"串起来。这个阶段在编译原理里叫做"符号解析"，通常需要构建一个符号表（symbol table）。符号表相当于一份全仓库的通讯录：所有类、函数、变量的名字、类型、所在文件、可见性都记录在里面。然后扫描器遍历 AST 里的每一个引用点，去通讯录里查这个引用指向谁。
这里有一个关键难点：跨文件引用。比如在order.go里 import 了payment.go的包，然后调用了payment.Charge()。codegraph 需要先解析 import 语句，确定包路径映射到哪个目录，再在目录里找到Charge的定义，然后才能把"调用边"从order.go连到payment.go的Charge函数上。这个链条只要断一环，边就丢了。我实际使用中确实遇到过语言特性和动态加载导致找不到边的情况，这个放到后面避坑章节专门说。
这个阶段还有一个隐含动作：符号的全局唯一标识。为了让图中每个节点可区分，codegraph 会给每个符号生成一个唯一 ID，比如module/package.Class.Method这种格式。这样即使两个不同包里有同名函数，在图里也能被准确区分。这也是它比 grep 强大很多的原因——grep 会把同名函数混在一起，而 codegraph 是精确到符号的。
2.3 图模型设计：节点是什么、边是什么
扫描和解析结束之后，codegraph 已经拿到了"实体"和"关系"的清单。接下来它会按照自己的数据模型，把这些实体和关系写入图结构。
我以大多数代码图谱工具通用的模型为例，列一份典型的节点类型和边类型表格：
| 节点类型 | 含义 | 常见属性 |
|---|---|---|
| File | 源文件或目录 | 路径、语言、行数 |
| Module | 模块/包（Go module、npm package 等） | 名称、版本 |
| Class | 类或接口 | 可见性、继承父类 |
| Function | 函数或方法 | 返回类型、参数列表 |
| Variable | 全局变量、常量 | 类型、值 |
| Database | 数据库或数据表（部分工具支持） | 表名、字段 |
| 边类型 | 含义 | 典型场景 |
|---|---|---|
| CALLS | 函数调用关系 | A 函数调用 B 函数 |
| IMPORTS | 模块导入关系 | A 文件 import B 包 |
| EXTENDS | 类继承关系 | SubClass 继承 BaseClass |
| IMPLEMENTS | 接口实现关系 | Class 实现 Interface |
| READS_WRITES | 读写变量/表 | 函数访问某全局变量 |
| CONTAINS | 包含关系 | Module 包含 Class，Class 包含 Method |
这些节点和边组合在一起，就形成了一张有向图。有向的意思是：调用是有方向的，A 调用 B，那么边从 A 指向 B。方向性极其重要，因为它直接决定了"反向依赖查询"（谁在调用我）和"变更影响分析"（我改了会影响谁）能不能实现。
2.4 为什么用"图"而不是"树"或者"列表"
这是很多人的疑问：MySQL 表也能存依赖关系，为什么非要搞个"图"出来？其实不是"非要"，而是图模型在某些核心问题上天然比表和树更合适。
树的问题是：每个节点只有一个父节点，表达不了多对多的依赖关系。代码里的依赖可不是一棵树——一个函数可以被十个地方调用，一个模块同时依赖多个包，这些都是标准的"多对多"。硬把多对多压成树，必然会有信息丢失。列表的问题则是：没有关系信息。你拿着一张函数清单，看不出谁调用谁，等于只有实体没有联系，那代码之间的结构依然是一片空白。只有"节点 + 边"的图结构能同时保留实体和关系，而且可以在这张图上做路径查询、子图匹配这类高级分析。所以，codegraph 选图模型不是因为炫技，而是因为代码依赖问题本质就是一个图问题。
3. 实操：把 codegraph 跑起来，生成你的第一张代码图谱
原理讲完，说说怎么上手。我按"安装 -> 初始化 -> 扫描 -> 查询/可视化"这条主线来写，每一步都给具体命令和注意事项。不同版本的 codegraph 命令名和参数可能有差异，本文以常见的 CLI 用法为例，实际使用时以你安装版本的--help输出为准。
3.1 安装与前置条件
codegraph 大多是用 Go 或 Rust 这类静态编译语言写的单二进制工具，安装一般就两步。如果你的环境有 Go，可以直接用 go install；macOS 上也可以用 Homebrew 安装。以常见 Linux/macOS 环境为例：
# 方式一：Go 安装 go install github.com/your-org/codegraph/cmd/codegraph@latest # 方式二：Homebrew 安装 brew install codegraph # 验证安装 codegraph --version前置条件方面，我提三点。第一，语言解析器需要真实环境存在——比如你要扫 TypeScript 项目，机器上得有 Node.js 运行环境，因为解析依赖 AST 可能要用到 TypeScript 编译器；要扫 Python 项目，得有对应版本的 Python 解释器。第二，磁盘空间：生成的图数据文件虽然不大（一般几 MB 到几十 MB），但扫描过程会产生中间缓存，给个 1GB 左右的余量比较稳。第三，大仓库建议先在小目录上试跑一遍，再铺开到全仓库，避免第一次扫描就超时。
3.2 初始化配置：只扫你关心的目录
装好之后先初始化配置文件。codegraph init会在项目根目录生成一个codegraph.yaml（或者其他格式，取决于版本）。这个配置文件是整个扫描行为的核心，里面要指定三件事：扫哪些路径、忽略哪些路径、用什么语言解析器。
我以一个典型的前后端混合仓库为例，给一份配置参考：
project: name: my-app root: . languages: - go - typescript scan_paths: - ./server - ./web/src ignore_paths: - ./server/vendor - ./web/node_modules - ./web/dist - ./docs exclude_test_files: true output: format: graph out_dir: ./codegraph-out配置里的几个关键点：scan_paths一定要精确到"真正放源码的目录"，不要把 node_modules、vendor 这种第三方依赖目录放进扫描范围，否则产出的图会被上万个第三方符号淹没，核心业务逻辑反而看不清。exclude_test_files我建议默认开启，除非你专门想分析测试对生产代码的依赖。ignore_paths支持通配符，合理配置能大幅减少噪音。
3.3 扫描：生成你的第一张图谱
配置写好后，执行扫描命令：
codegraph scan --config codegraph.yaml扫描过程会输出进度。对十万行级别的仓库，通常几分钟能跑完。扫描结束后，./codegraph-out目录下会生成图谱数据文件。常见的有graph.json（节点和边的完整导出）、graph.db（SQLite 格式，方便程序化查询）、index.html（可视化入口）。你可以在 JSON 里直观地看到节点长什么样：
{ "nodes": [ { "id": "server/internal/service.OrderService", "type": "Class", "name": "OrderService", "file": "server/internal/service/order.go" }, { "id": "server/internal/service.OrderService.CreateOrder", "type": "Function", "name": "CreateOrder", "file": "server/internal/service/order.go" } ], "edges": [ { "from": "server/internal/handler.OrderHandler.Create", "to": "server/internal/service.OrderService.CreateOrder", "type": "CALLS" } ] }看到这个 JSON，你就知道图谱的本质是啥了，它就是一份结构化的依赖清单。我不建议直接去读 JSON 文件——除非你想写脚本处理——正常人用可视化或者查询语句。
3.4 查询与可视化：三种打开方式
codegraph 最实用的能力在查询。我常用三种方式：
第一种是 CLI 查询。codegraph 内置了简单的查询子命令，适合快速问问题。比如"谁调用了 OrderService.CreateOrder"：
codegraph query --reverse-callers --symbol "server/internal/service.OrderService.CreateOrder"第二种是可视化 Web UI。执行codegraph serve --open会启动本地服务，在浏览器里打开图谱。页面支持缩放、拖动、按节点类型过滤、点击节点跳转到对应源码文件。对刚上手的人来说，可视化是最直观的入口——你可以从某个入口函数开始，一层一层点开调用链，比对着 IDE 跳转效率高很多。第三种是导入 Neo4j 做深度分析。codegraph 支持导出 Cypher 语句或者直接和 Neo4j 数据库对接。执行codegraph export --neo4j --uri bolt://localhost:7687能把图谱灌进 Neo4j，然后你用 Cypher 任意查询。这是最强的一种方式，适合复杂分析，后面第 4 节的几个场景我主要按 Cypher 查询来讲。
3.5 增量扫描：让图谱跟上日常开发
第一次扫描完成只是开始，真正让图谱发挥价值的是让它"保持新鲜"。全量扫描每次跑一遍，大仓库会越来越慢，所以我更推荐用增量扫描。典型的做法是在 git 提交时计算变更文件，然后只对变更文件做局部重扫，把新增的函数和调用关系合并进已有图谱。codegraph 一般会提供--since-commit或者--changed-files之类的参数支持增量模式，命令大致长这样：
codegraph scan --config codegraph.yaml --incremental --since-commit HEAD~1如果版本不支持增量，也有一个笨办法：把scan_paths拆成多个配置，按模块分别扫描、统一导入，这样你只需要重扫当前改动的那一个模块。实际下来，增量扫描能把一次更新的耗时从"分钟级"降到"秒级"，这个体验差异很影响你愿不愿意每次 commit 都顺手更新图谱。
4. 几个高频实战场景：从查询到结论
工具跑起来之后，真正有价值的是用它在真实场景中解决问题。这一节挑我实际用过的四个场景，每个场景给出查询思路、语句示例和结果解读，你可以对照自己的项目举一反三。
4.1 反向依赖查询："谁在调用我？"
最常用也最刚需的场景。你要重构一个函数、改一个接口签名，第一反应就是想知道哪些地方在用。IDE 的 Find Usages 能找到直接调用，但在图谱里你可以问得更细：谁直接调用？谁间接调用？调用的路径长什么样？深度有几层？
在 Neo4j 里（假设图谱数据已导入），查询"谁调用了 Charge 函数"：
MATCH (caller)-[:CALLS]->(target {name: 'Charge'}) RETURN caller.id, caller.file如果要查"调用深度不超过 3 层的所有上游"，用变长路径：
MATCH path = (caller)-[:CALLS*1..3]->(target {name: 'Charge'}) RETURN path结果解读有一个重点：直接调用者（1 层）往往就是你改接口要同步改的；2 层以上的间接调用者，虽然不用马上改，但它们对你这次改动的影响范围要心里有数，尤其是做线上变更的时候。曾经有一次我改一个内部工具函数，想着只被两个地方直接调用，结果通过图谱发现有一条 3 层的调用链能从某个定时任务一路通到用户导出的入口，差点出事故。
4.2 变更影响分析："改这个模块，会炸哪些下游？"
这个场景跟 4.1 类似但范围更大。你改的不是一个函数，而是一个模块甚至一个服务。这时候要看的不只是 CALLS 边，还有 IMPORTS、EXTENDS 这些不同类型的依赖边。"订单服务依赖了库存服务的 RPC 客户端，库存服务又依赖了商品服务"，这种跨模块依赖如果想要一张全局清单，手写是不可能的。
用 Cypher 可以一次性拉出两级依赖：
MATCH (m:Module {name: 'inventory'})<-[:IMPORTS]-(dependent:Module) OPTIONAL MATCH (dependent)<-[:IMPORTS]-(transitive:Module) RETURN dependent.name, collect(transitive.name) AS transitive_dependents输出是一张表格：第一列是直接依赖库存的模块，第二列是间接依赖的模块。这样你在评审"库存模块能不能下线"这种问题的时候，手里就有了一份硬数据，而不是只能靠"我觉得应该没人用了吧"。我还习惯把这个查询脚本存成一个固定脚本，每次上线周报里都跑一遍，作为变更风险评估的附加参考。
4.3 主干流程梳理："这个功能到底是怎么走通的？"
新入职或者接手不熟的业务模块，最头痛的是：给你一个功能名字（比如"发起退款"），你怎么找到它的入口和主干链路？传统做法是全局搜"refund"，然后从 Controller 开始一层一层读。有了图谱，你可以倒过来——先找到所有名字里带 Refund 的函数，看它们的调用关系，让链路自己浮出来。
在可视化界面里做这步最舒服：搜Refund，把所有匹配节点显示出来，然后再展开它们的调用和反向调用，你会看到一张子图。从子图里挑出入度（被调用次数）为零的节点——它们大概率是入口；再挑出出度为零的节点——它们大概率是终点（落库、发消息、调第三方）。把入口到终点之间最粗的一条路径拎出来，就是这条功能的主干。我经常用这个法子给新同学画"模块讲解图"：不是贴一段文字，而是直接打开图谱，选中一条链路，截图放到文档里。见过一次这种图的人，基本不用再问第二遍业务链路。
4.4 团队场景：代码评审与新人上手
代码评审里用图谱也有奇效。我 review 一个 PR 的时候，除了读 diff，还会用 codegraph 扫一下这个 PR 涉及的文件，看看它们被哪些其他模块依赖。如果有一个很核心的公共模块被改了，但 PR 描述里没提调用方适配方案，我就会直接在评审意见里附上反向依赖查询的截图和结论。这比单纯说"这里改动影响面很大，请谨慎"有说服力得多，因为它有数据、有图、有据可查。
新人上手这块我前面已经提到了。我对新同学的建议是：先在图谱里把负责模块的高亮子图导出来，把每个节点的文件路径去 IDE 里打开一遍，对照着读。这比直接从入口 main 往下读快得多，因为你能先建立"全局结构安全感"，再钻进细节。团队层面，我们后来约定：新模块合入主干时，PR 描述里必须附一张 codegraph 子图，说明该模块的对外依赖和对内依赖。这个习惯坚持了半年，效果非常显著——架构评审的效率高了一大截。
5. 实际使用中的心得与避坑
工具好用，但坑也不少。这一节把我踩过的、见过别人踩的整理成几条，按"性能、准确性、查询质量、协作落地"四个维度来讲。
5.1 性能：图谱不是越大越清晰
我第一次跑全仓库扫描，把 node_modules 和 vendor 都扫进去，结果生成了一张 50 万个节点、120 万条边的大图。打开可视化界面，密密麻麻一片黑，根本找不到业务代码在哪。后来我学乖了，scan_paths只留业务代码目录，ignore_paths把第三方依赖都排掉，节点数量降了一个数量级，图谱才变得真正可用。所以第一原则：图谱追求的是"关键路径清晰"，不是"所有符号齐全"。你可以在配置里用exclude规则过滤测试代码、生成代码、第三方依赖，只保留你自己维护的源码。第二原则：分模块扫。把大仓库拆成"核心域""应用层""基础设施"三个扫描单元，各自出图再合并，比一把梭子扫完要快得多，排查问题也容易定位是哪个模块的边丢了。
另外注意增量扫描的时间点。我建议把 codegraph 放进 CI 里的定时任务，比如每天凌晨对主干分支做一次增量更新，而不是让每个开发者在本地全量扫——既慢，又会因为各人分支不同产生大量不一致的中间数据。
5.2 准确性：动态语言的"反射"和"依赖注入"会漏边
codegraph 这类工具大多数情况下依赖静态分析，而静态分析的天敌就是动态特性。Python 里的 getattr、Go 里的 interface{} 加反射、Java 里的 Spring 依赖注入 + AOP、JavaScript 里的 Proxy，这些运行时才能确定的东西，扫描器在静态阶段看不到，于是相关的边就不会出现在图谱里。
我在一个 Python 服务里就遇到过这种情况：一个类通过__getattr__动态转发方法调用，图谱里完全找不到"谁在调它"，导致变更影响分析漏了一条关键链路。遇到这种问题，我的处理方式是：在 codegraph 支持的情况下，用"手动补充边"的方式把已知的动态关系写进图谱（有些工具提供manual_edges配置），或者接受这个限制，在分析结论里注明"动态调用部分不在涵盖范围内"。不要因为个别漏边就否定整个工具的价值——它覆盖面已经很可观，动态部分用代码评审和测试来补足即可。
5.3 查询质量：别一开始就写全库扫描的查询
如果你把图谱导入 Neo4j，第一个要注意的问题是查询别太贵。比如不带任何过滤条件就MATCH (a)-[:CALLS]->(b) RETURN a,b，在几十万条边的图里会直接卡死浏览器或让服务超时。我的习惯是先带名称或类型过滤：
MATCH (a)-[:CALLS]->(b) WHERE a.type = 'Function' AND b.name CONTAINS 'Refund' RETURN a.id, b.id LIMIT 200另外，图查询的结果表达也很重要。我踩过的另一个坑是：查询出 500 条调用关系，但不知道从哪看起。现在我会先看节点的入度和出度分布——入度最高的那几个节点往往是公共底座，出度最高的几个往往是入口流程。把这些"枢纽节点"单独导出来，先看它们之间的拓扑，再下沉到二级细节。这样查出来的结果才不是一张无意义的蜘蛛网。
5.4 协作落地：怎么让团队不是只有你一个人在玩
最后说说团队推广。工具再好，如果只有你一个人用，价值就大打折扣。我推广 codegraph 的经验是：先做一个"样板分析"给大家看。我当时挑了一个所有人都知道模块间依赖混乱的老服务，用 codegraph 扫出一张触目惊心的依赖图，然后把它贴在团队文档里，欢迎大家来找"有没有扫错的边"。这一下就引起了讨论——有人质疑准确性，有人惊讶某些模块竟然互相依赖。争论完，大家就接受了把 codegraph 纳入日常流程的做法。
落地的具体做法我给三条建议。第一，把扫描和导出做成一条 Makefile 命令或者一个脚本，团队里任何人一键就能生成最新图谱，不要让人去记复杂的命令行参数。第二，把图谱可视化文件（HTML）跟随文档一起放到团队的文档库里，每次重大迭代都更新一次，当作"可执行的架构图"用。第三，在代码评审规范里加入一项：核心公共模块改动时，附上反向依赖查询结果。这不需要每个 PR 都做，只需要在涉及核心模块的时候执行，成本低、收益明显。
我个人实际用下来的体会是：codegraph 这类工具最大的价值不在"炫酷的可视化"，而在于它把"代码库结构"从一个只可意会的隐性知识，变成了一个可以查询、可以争论、可以传承的显式对象。你不需要记住每个模块的依赖，你只需要知道有个地方能查到。如果你手头正好有一个规模不小、依赖混乱的仓库，花一个下午把 codegraph 跑起来、导出第一版图谱、对着它梳理一遍核心模块的依赖，这个过程带给你的确定感，会很值得。
