内联参数提示本身不卡顿，真正瓶颈是语言服务器（如TypeScript Server、Pylance）响应慢或重载频繁；应优先关闭高开销提示项、限定作用域、排除node_modules，并排查服务日志与CPU占用。
内联参数提示（Inlay Hints）本身不消耗显著性能，但开启后卡顿，基本不是它的问题，而是语言服务器或扩展在“同步渲染提示”时被拖慢了。 它们依赖 TypeScript Server、Pylance 或 clangd 实时分析代码并生成位置信息，一旦这些服务响应变慢或频繁重载，inlayHints 就会表现为延迟、闪烁甚至阻塞编辑器光标。
确认是不是语言服务器在拖后腿
内联提示只是“显示层”，真正干活的是背后的语言服务器。如果 typescript.server.log 里有大量 getApplicableRefactors 或 getSignatureHelp 超时，或者 Pylance 日志中反复出现 Analysis paused，那问题不在提示开关，而在服务本身。
- 打开命令面板（
Ctrl+Shift+P），运行Developer: Toggle Developer Tools，切到 Console 标签页，输入language看是否有红色报错 - 对 TS/JS 项目：在终端运行
npx tsc --watch --noEmit，观察 CPU 占用是否异常高；高则说明项目配置或类型定义本身已超负荷 - 对 Python：检查
python.defaultInterpreterPath是否指向一个带完整 site-packages 的虚拟环境——Pylance 启动时会扫描所有包，路径错或环境过大直接导致初始化卡住
关掉“实时推导型”提示项
有些提示项必须每次键入都重新计算类型，比如 python.analysis.inlayHints.variableTypes 在复杂嵌套表达式中会触发全量类型推断；typescript.preferences.includeInlayVariableTypeHints 对 const x = someFunc() 这类调用也会反复查返回值。它们比参数名提示（parameterNames）更重。
- 优先只开
python.analysis.inlayHints.parameterNames和typescript.preferences.includeInlayParameterNameHints——这两项基于函数签名静态提取，几乎无额外开销 - 关闭
python.analysis.inlayHints.functionReturnTypes，除非你真正在调试返回类型歧义；它会让 Pylance 对每个函数调用都做一次完整控制流分析 - TS 用户避免设
typescript.preferences.includeInlayVariableTypeHints为all；改用literals或干脆none，尤其在大型.d.ts项目中
限制提示作用域和刷新频率
VSCode 默认对所有打开的文件启用内联提示，包括你只是临时预览的 node_modules 里的文件——这会导致语言服务器被迫解析成千上万个无关模块。
- 在工作区
.vscode/settings.json中加这一段，把提示严格限定在源码目录：
"editor.inlayHints.enabled": "on",
"editor.inlayHints.showInComments": false,
"editor.inlayHints.showInStrings": false,
"files.associations": {
"**/src/**/*": "typescript",
"**/lib/**/*": "javascript"
}
- 禁用全局监听：
"files.watcherExclude"加上"**/node_modules/**"和"**/dist/**"，防止文件变更触发语言服务器重分析 - 不要依赖
editor.inlayHint.fontSize调大来“让提示更明显”——字体放大本身不卡，但会放大渲染压力；若提示模糊或断续，先换主题（如Default Dark+），再调字号
真正影响体验的从来不是“要不要显示提示”，而是“什么时候去算它”。很多团队把 inlayHints 当成开关一开就完事，结果在 10 万行的 monorepo 里等三秒才看到 → string，其实只要关掉变量类型提示 + 排除 node_modules，同一台机器上就能降到 200ms 内。别优化显示逻辑，去压语言服务器的负载。
