ctrl+shift+o仅索引文件符号而非函数内逻辑路径；应结合面包屑、代码折叠、正则搜索（return|throw|await|if）及调试断点来追踪真实执行流。
Ctrl+Shift+O 只搜当前文件的符号，不是函数内逻辑路径
很多人按 Ctrl+Shift+O（Windows/Linux）或 Cmd+Shift+O（macOS）后，以为能“看清函数里怎么走”，结果出来的是整个文件的类、方法、变量列表——它不解析执行顺序，只做静态符号索引。你真正要的，是函数体内部的条件分支、return 位置、await 链、异常跳转这些动态逻辑线索。
用「面包屑」+ 手动折叠看控制流结构最直接
VS Code 的面包屑（编辑器顶部路径栏）默认显示当前函数名，但关键在配合代码折叠：
- 确保启用了
"editor.foldingStrategy": "indentation"或"syntax"（推荐后者，对 if/for/try/async 更准） - 把光标停在函数首行，按
Ctrl+Shift+[折叠所有子块，再逐级展开：先看顶层 if/else，再看里面有没有嵌套 await 或 throw - 特别注意被折叠掉的
return、throw、break—— 它们常藏在缩进最深的块末尾，是逻辑提前退出的关键点 - 如果函数太长（>50 行），折叠后仍混乱，说明它本该拆分；此时别硬读，先用
Ctrl+F搜return、throw、await、catch这四类词，人工串出主干路径
正则搜函数体内关键语句比靠插件更可控
想快速定位所有可能中断流程的位置？关掉花哨插件，直接用全局搜索限定到当前文件：
- 按
Ctrl+Shift+F，输入框填return|throw|break|continue，勾选.*（正则模式），再在files to include里填当前文件名（如utils.ts） - 搜
await\s+\w+看异步调用链，注意它后面是否紧跟if或try - 搜
if\s*\([^)]*\)\s*{匹配带大括号的 if（排除单行 if），再手动扫括号内是否有 return/throw - 避免搜
else单独出现——它没上下文，必须和前一个if对齐看才有效
调试视图里的「调用堆栈」和「断点命中顺序」才是真逻辑路径
静态分析永远有盲区。函数里写了 if (x) { doA(); } else { doB(); }，但你不运行，就不知道这次走哪条。这时候：
- 在函数第一行打个断点，F5 启动调试（哪怕只是本地 Node.js 脚本）
- 观察「调用堆栈」面板里当前帧的上层是谁，下层还没进——这是入口与出口视角
- 单步（F10）时紧盯「变量」面板里关键状态变化，比如某个 flag 从
false变成true的那一行，就是逻辑分叉点 - 如果函数被高频调用，用「条件断点」：右键断点 → Edit Breakpoint → 填
process.env.NODE_ENV === 'development'这类守卫，避免打断点卡死
函数内逻辑路径不是画出来的图，是跑出来的轨迹。折叠、正则、断点三者得轮着用——光靠一个，漏掉的往往是那个没写注释的 return;。
