atom无内置可视化依赖图，因其采用事件总线、动态require和懒初始化等松耦合设计，静态分析难以捕获完整调用链；可靠分析应聚焦atom-environment.js、text-editor-element.js和测试文件，并用depcheck+graphviz导出构造时显式依赖。
Atom 编辑器本身不提供内置的「可视化依赖关系图」功能，也没有官方维护的插件能一键生成 TextEditor、TextBuffer、GrammarRegistry 等核心模块的实时依赖图。想靠点几下就看到完整架构图，这条路走不通。
为什么 Atom 没有现成的依赖图插件？
Atom 的模块间通信大量依赖事件总线（atom.notifications、atom.commands、atom.workspace）和弱引用回调，而非显式 import/require 链。比如 TextEditor 实例会监听 text-buffer:changed 事件，但源码里找不到 require('./text-buffer') 这样的硬依赖——它通过 atom.project.bufferForPath 动态获取。这种松耦合设计让静态分析工具很难抓全调用路径。
另外，Atom 的包加载机制是运行时异步注册的：package.json 中的 activationCommands 或 activationHooks 触发后才 require 对应模块，进一步削弱了静态依赖可追踪性。
- 所有核心模块（如
TextEditor、Cursor、DecorationManager）都通过atom全局对象分发，不暴露原始构造函数引用 -
require调用多被封装在Package类的loadRequireCache方法中，且支持重写resolve钩子 - 大量使用 ES6 Proxy 和 getter 懒初始化（例如
atom.packages初次访问才加载包列表）
手动绘制依赖图的三个可靠入口点
想搞清 TextEditor 到底依赖哪些模块，别从 src/text-editor.js 开始逐行 grep，优先查这三个地方：
-
src/main-process/atom-environment.js：看createTextEditor方法里 new 出TextEditor前传了哪些服务实例（config、grammarRegistry、scopeDescriptorManager等） -
src/text-editor-element.js：这是视图层，明确列出TextEditor实例持有的关键引用，比如this.model（即TextBuffer）、this.cursor、this.selections -
spec/text-editor-spec.js：测试文件里jasmine.createSpyObj模拟的依赖项，往往就是真实构造函数参数的最小集合（例如new TextEditor({buffer, grammarRegistry})）
用 vsce + graphviz 快速导出模块关系（实操建议）
如果你真需要一张图，最可控的方式是：用 VS Code 打开 Atom 源码，装 vsce 插件，再配合 depcheck 和 graphviz 手动跑一次粗粒度分析：
- 先执行
npx depcheck --ignore-bin-package --json > deps.json，过滤掉electron、babel等构建依赖，聚焦./src/下的内部模块引用 - 把
deps.json里using字段的路径映射为模块名（如./text-buffer→TextBuffer），剔除node_modules和测试路径 - 用 Python 脚本生成
.dot文件，重点连通TextEditor→TextBuffer、TextEditor→GrammarRegistry、TextEditor→Cursor这三条主干 -
dot -Tpng deps.dot -o atom-deps.png输出图，注意加rankdir=LR让流向从左到右，否则TextEditor会被挤到角落
这张图不会包含事件监听或运行时动态 require，但它能守住「构造时显式依赖」这条底线——而这恰恰是调试 TextEditor 初始化失败、光标不更新等硬问题时最该盯住的部分。
真正容易被忽略的是：Atom 的依赖不是单向树，而是带环的网。比如 TextBuffer 会 emit changed 事件，TextEditor 监听它；反过来 TextEditor 的 setCursorBufferPosition 又会调用 TextBuffer.setTextInRange。画图时若只画 require 关系，这个环就断了。
