Sticky Scroll需同时满足三前提才生效：语言模式正确、存在可折叠结构、光标位于已滚动出视图的嵌套块内；开关用命令面板“Toggle Sticky Scroll”最便捷；maxLineCount默认5较平衡，Markdown/JSON等因无大纲支持而失效。
Sticky Scroll 不是“在文件头部显示函数名”，而是把当前光标所在嵌套块的声明行（比如 def foo()、class Bar:）“粘”在编辑器**可视区域顶部左侧**——它只在你向下滚动且该声明行已移出视野时才生效，不是固定在文件最顶上。
为什么开了 editor.stickyScroll.enabled 却没看到函数名？
常见失效不是配置错，而是没满足三个硬性前提：
- 右下角语言模式必须是支持大纲（Outline）的语言，如
Python、TypeScript、Java、C#；Plain Text或未配好解析器的Markdown一定不工作 - 文件里得有真实可折叠的语法结构：比如
def后紧跟缩进块，if后有冒号+下一行缩进；空行、纯注释、无缩进的代码行会让语言服务识别失败 - 光标必须落在某个嵌套块内部（例如函数体里的
return x那行），且你已经向下滚动，让def xxx:这行移出了当前可视区——没滚动，它就不“粘”
验证方式：按 Ctrl+Shift+O 打开大纲视图，如果这里也为空或层级错乱，问题出在语言服务，不是 Sticky Scroll 设置本身。
editor.stickyScroll.maxLayerDepth 控制能“粘”几层嵌套
默认只显示当前函数 + 上一级（比如类 → 方法），但对链式调用或深度回调不够用。比如光标在 Promise 的 then() 里，想同时看到 class ApiClient → function fetch() → then()，就得调这个值：
- 设为
3或4，适合 TypeScript/JavaScript 的深层回调 - 设为
1就只剩最外层作用域，基本失去上下文意义 - 值越大，解析开销略增，但日常编辑几乎无感；真正拖慢的是语言服务器本身，不是 Sticky Scroll 渲染
注意：它和 editor.stickyScroll.maxLineCount 不是一回事——后者只控制顶部最多显示几行标题（默认 5），不影响解析深度。
Python 用户特别注意缩进与作用域识别
VS Code Python 扩展对“作用域”的定义不如 JS 严格，导致某些结构粘不住：
-
def和class基本稳，但裸if、for块不一定被识别为独立作用域层级 - 混用 Tab 和空格、函数体开头有空行或多行注释（尤其 JSDoc 前格式不标准），会干扰
DocumentSymbolProvider解析 - 手动折叠过某段代码（
Ctrl+Shift+[）后，Sticky Scroll 不会主动展开读取名称，可能显示空白或截断
解决办法：保持缩进一致，避免函数体前加空行，禁用自定义折叠增强类扩展后再试。
真正容易被忽略的是：Sticky Scroll 不随光标移动实时刷新，而是滚动停止约 200ms 后才更新。快速拖动滚动条时顶部“卡住”是正常防抖行为——强行取消它反而会抬高 CPU 占用，得不偿失。
