SelectionRange 不生效主因是未正确注册、上下文未触发或被语言服务器覆盖；需检查 documentSelector 匹配、激活事件覆盖、LSP 冲突及 range 严格嵌套，且返回数组首项必须覆盖光标位置。
VSCode 插件开发中 SelectionRange 不生效，基本不是 API 用错了，而是没正确注册、没触发上下文、或被语言服务器覆盖了。
为什么 SelectionRangeProvider 注册后没反应
插件调用 vscode.languages.registerSelectionRangeProvider 后，编辑器完全不响应 Ctrl+Shift+→ 或命令面板里的 “Expand Selection”，常见原因有三个：
- 未指定
documentSelector，或 selector 匹配不到当前打开的文件（比如写了{ language: 'typescript' }，但文件是.tsx或没有语言模式） - 插件激活事件未覆盖该语言，例如用了
onLanguage:javascript，但文件实际语言 ID 是typescriptreact - 已有其他 provider（如 TypeScript Server、ESLint 插件）抢先注册并返回空数组，VSCode 会跳过后续 provider
验证方式：在插件激活后，执行 console.log(vscode.languages.getLanguages()) 看当前文档语言 ID；再用 vscode.workspace.onDidChangeTextDocument 打印 e.document.languageId 确认实时值。
provideSelectionRanges 返回的 range 必须严格嵌套
VSCode 要求每个 SelectionRange 的 range 必须完全包含在其父级 parent 的 range 内——不能相交、不能错位、不能空。否则整个链会被静默丢弃。
- 错误示例：
parent.range是第 5–7 行，子range是第 6–8 行 → 越界，失效 - 正确做法：用
document.getWordRangeAtPosition(pos)或document.getSectionRangeAtPosition(pos)（需自己实现）确保层级收缩 - 调试技巧：临时在返回前加断点，用
console.log(JSON.stringify(ranges, null, 2))检查嵌套结构
和原生智能选中冲突时怎么定位源头
即使你的 provider 正常注册、range 结构合法，Ctrl+Shift+→ 仍可能走原生逻辑而非你的实现。这是因为 VSCode 默认优先使用语言服务器（LSP）提供的 selection ranges —— 只要 LSP 响应了 textDocument/selectionRange 请求，就不会 fallback 到插件 provider。
- 检查方法：打开开发者工具（
Help → Toggle Developer Tools），过滤 network 请求，搜索selectionRange，看是否有 LSP 响应 - 临时禁用 LSP：在插件调试 launch.json 中加
"env": { "VSCODE_DISABLE_MAIN_PROCESS_EXTENSIONS": "true" }，或关闭相关语言插件（如 TypeScript Hero、ES7 React Extensions） - 绕过限制：改用
vscode.commands.registerCommand绑定自定义命令（如mylang.expandSelection），明确调用你的 provider
最易忽略的一点：provider 返回的 SelectionRange 数组长度至少为 1，且首个元素必须覆盖光标所在位置 —— 否则 VSCode 认为“无有效范围”，直接跳过渲染。别假设它会自动补全或 fallback。
