provideInlineCompletionItems未被调用最常见的原因是语言服务器未注册内联补全提供者或VSCode未识别文件类型支持；必须同时满足：文档有匹配language ID、已通过registerInlineCompletionItemProvider注册、且"editor.inlineSuggest.enabled": true。
为什么provideInlineCompletionItems没被调用？
最常见的情况是语言服务器根本没注册内联补全提供者，或者 VSCode 没识别到当前文件类型支持该能力。VSCode 不会主动调用你的 provideInlineCompletionItems，它只在满足三个硬性条件时才触发：当前文档有对应语言 ID（如 typescript）、已激活的 InlineCompletionItemProvider 已通过 languages.registerInlineCompletionItemProvider 注册、且编辑器设置了 "editor.inlineSuggest.enabled": true。
检查点包括：
- 在插件激活函数里确认调用了
languages.registerInlineCompletionItemProvider，且传入的 language ID 与document.languageId严格匹配（比如javascriptreact≠javascript） - 打开命令面板（
Ctrl+Shift+P），运行Developer: Toggle Developer Tools，在 Console 中搜索registerInlineCompletionItemProvider看是否有注册成功的日志 - 在目标文件中按
Ctrl+Shift+P→Developer: Inspect Editor Tokens and Scopes，确认右下角显示的语言模式和你注册的 language ID 一致 - 别依赖
onDidChangeTextEditorSelection自行监听光标——VSCode 内部只在“编辑器内容变化 + 光标静止约 300ms”后才真正发起内联请求，手动监听无法模拟这个节流逻辑
context.triggerKind 是 Invoke 还是 Automatic？
这个字段直接决定补全是否能“自动浮现”。如果用户按 Ctrl+Space 或 Ctrl+Shift+Space 手动唤起，context.triggerKind === InlineCompletionTriggerKind.Invoke；如果是敲完 console.log( 后停顿半秒自动出现，则是 Automatic。很多插件开发者只处理 Invoke，结果上线后用户抱怨“没提示”，其实是漏了 Automatic 分支。
真实调试建议：
- 在
provideInlineCompletionItems开头加断点，观察context.triggerKind值，不要假设它总是Invoke - 自动触发受
editor.inlineSuggest.showToolbar和editor.inlineSuggest.mode影响，但这两个配置不控制是否调用你的 provider，只控制 UI 渲染行为 - 某些语言服务器（如 Pylance）对
Automatic有额外置信度阈值：若变量类型为any或未声明，它会直接跳过调用你的 provider，连断点都进不去
补全项返回后，灰色文本不显示或一闪而过
这不是你的逻辑错了，而是 VSCode 的渲染层在做冲突仲裁。内联补全不是独占通道——它和 IntelliSense 下拉菜单、代码片段（Snippets）、甚至其他 AI 插件的补全项共享同一个“建议池”。一旦多个 provider 同时返回非空结果，VSCode 会按优先级排序并截断，你的 InlineCompletionItem 可能被静默丢弃。
关键排查动作：
- 打开设置，临时禁用所有非必要插件，只留你的插件和基础语言支持（如 TypeScript Server），再测试
- 确保返回的
InlineCompletionItem中range精确覆盖光标后零个或多个字符；若range起始位置不在光标处，VSCode 会直接忽略整条建议 - 不要在
insertText里包含换行符或制表符——内联补全只支持单行纯文本，否则渲染引擎会崩溃并清空整个内联队列 - 检查 DevTools Console 是否有
Inline completion item range is invalid类警告，这是最常被忽略的日志线索
流式响应中断报 stream disconnected before completion
这句错误不是网络问题，而是通义灵码/Tabby 类插件特有的状态机超时机制在起作用。它们用 WebSocket 或自定义 HTTP 流接收模型输出，但 VSCode 的 provideInlineCompletionItems 是同步 Promise 接口，必须在一定时间内 resolve，否则编辑器强制 cancel 并抛出该错误。
根本原因和对策：
- 你的 provider 在等待远端流式响应时，没做
token.onCancellationRequested监听，导致 cancel 信号无法及时终止请求，最终超时 - 别在
provideInlineCompletionItems里直接await fetch()—— 改用AbortSignal绑定token，例如：fetch(url, { signal: token.token }) - 通义灵码源码里有个隐藏逻辑：
preCompletion请求先发一次轻量上下文校验，若 200ms 内无响应，后续完整completion请求会被跳过——所以得同时监控 preCompletion 链路 - VSCode 对单次内联请求的默认超时是 1.5s，但实际可用时间更短，因为还要预留渲染耗时；建议服务端首字节响应（TTFB）控制在 300ms 内
内联补全真正的难点不在“怎么写”，而在“什么时候不该写”——比如光标在字符串内部、注释块中、或刚粘贴完大段代码时，强行返回建议只会干扰用户。这些边界条件不会报错，但会让体验崩坏，而且极难复现和调试。
