VSCode插件无法真正自动整理函数调用逻辑，因其仅基于静态AST解析，不理解业务也不执行代码；但配合clangd等语言服务器可生成可复现的调用快照。
VSCode 插件无法真正“自动整理”函数间的调用逻辑——它不理解业务含义，也不执行代码，所有生成的图都是静态 AST 解析结果；但配合正确工具链，能快速产出可复现、可验证的调用关系快照，大幅减少手动跳转成本。
Call Hierarchy（Ctrl+Shift+H）为什么点不动？
这不是插件坏了，是语言服务器没提供数据。常见断点：
-
clangd没运行或缺失compile_commands.json：用bear -- make或 CMake 加-DCMAKE_EXPORT_COMPILE_COMMANDS=ON生成 - C 文件未被识别为项目成员：检查
c_cpp_properties.json中的includePath和intelliSenseMode是否匹配实际编译器 - 函数来自宏展开、
inline或constexpr if：这些不会进入符号表，Call Hierarchy天然不可见 - Python 中用了
from module import *：改用显式导入，否则Go to References会漏调用点
Code2flow 命令行版比插件更稳
VS Code 插件版 Code2flow 只分析当前打开文件，且依赖编辑器状态；命令行版直接读源码、输出 .dot，可控性强得多。
- 必须先装
graphviz（macOS：brew install graphviz；Windows：官网下 installer） - 关键参数不能省：
--no-grouping防止函数被合并（否则调用链直接消失），--max-depth 3控制展开深度，避免图爆炸 - 不支持动态导入：
import()、export * from 'xxx'、C++ 宏和模板特化全被忽略 - TS 中的
interface、type不参与图生成——别误以为“没画出来 = 没用到”
C Relation 插件适合小型 C/C++ 模块，别用在大型项目
它靠字符串匹配解析，不依赖 clangd，启动快但精度低，100+ C 文件就容易卡死主进程。
- 函数指针调用（如
func_ptr();）完全不识别 - 宏定义函数（
#define foo() do {} while(0)）会被当作文本误标 - 含大量
#ifdef的项目，图中会出现大量灰色/断开节点 - 只建议用于单文件调试或模块级粗略扫描，真要分析全项目，请回到
clangd + compile_commands.json路线
Code Call Graph Editor：唯一支持手动补全的图形化方案
当自动解析失败率太高（比如祖传 C++ 项目满屏宏+手写模板），这个插件允许你用 JSON 手动定义节点和边，再绑定到真实代码位置。
- 它生成的
.callgraph.json是纯文本，可进 Git、可 Review、可 AI 辅助生成 - AI 提示词需明确字段格式：
nodes含id/label/symbol，edges含from/to，uri必须是工作区相对路径 - 点击图中节点可跳转到真实定义，但前提是
symbol.uri和symbol.line填对了——错一位就跳偏 - 不自动维护跨文件引用，每次重构后得手动更新 JSON，这是它“可控但费力”的本质
真正可靠的调用关系永远建立在语言服务器正确索引的基础上；图形只是表象，而最常被忽略的一点是：所有工具都默认忽略条件编译分支、运行时多态分发、以及函数指针间接调用——这些必须靠人工补全或结合调试器动态抓取。
