VSCode需通过扩展支持新语言，优先查官方/社区LSP或TextMate扩展；无扩展时可手动配置.tmLanguage.json实现语法高亮，但语义功能须依赖Language Server；调试需单独适配debugger协议，且维护可持续性是关键。
VSCode 本身不直接支持新型编程语言，必须通过扩展（Extension）实现语法高亮、智能提示、调试等功能。没有现成扩展时，不能靠改配置或装插件包“凑合用”，得从语言服务器（LSP）或 TextMate 语法定义入手。
如何判断该语言是否有可用的官方或社区扩展
打开 VSCode 扩展市场（Ctrl+Shift+X），搜索语言名或文件扩展名，比如 astro、.res、gleam。重点看三点：
- 发布者是否为语言官方团队（如
redwoodjs.redwood-vscode） - 最近更新时间是否在 6 个月内
- Issues 页面是否有大量未关闭的
Language Server crashed或No completions provided类报错
若只有语法高亮扩展（如仅含 language-xxx），但无 xxx-language-server 或 xxx-lsp，说明补全/跳转/诊断功能大概率不可用。
没有扩展时，手动添加基础语法支持（.tmLanguage.json）
适用于已有 TextMate 语法定义（常见于 GitHub 上的 grammars 仓库）的语言，比如新出的 .wasm 文本格式或自研 DSL。步骤如下：
- 下载对应
xxx.tmLanguage.json文件（不是.plist或.yaml） - 新建用户代码片段目录：
~/.vscode/extensions/custom-lang-support-0.0.1/（Windows 为%USERPROFILE%\.vscode\extensions\custom-lang-support-0.0.1\） - 在该目录下创建
package.json，声明contributes.languages和contributes.grammars - 把
.tmLanguage.json放进./syntaxes/子目录，并在package.json中正确引用路径
注意：scopeName 必须唯一且符合 source.xxx 或 text.xxx 规范，否则 editor.tokenColorCustomizations 无法生效；VSCode 不支持动态加载未打包的语法文件，必须走扩展目录结构。
使用四维度框架评估任意 GitLab MR 或 GitHub PR 的复杂度：规模（20%），认知负荷（30%），审查工作量（30%），风险/影响（20%）...
需要语义功能（跳转、补全、错误诊断）时，必须接入 Language Server
单纯语法高亮解决不了 Go to Definition 或 hover 提示。此时需确认该语言是否已实现 LSP 协议的服务端（CLI 工具）：
- 查官网文档是否有
xxx-lsp或xxx-language-server项目（如gleam lsp、cairo-language-server） - 运行
xxx-language-server --help，确认输出含--stdio或--socket等 VSCode 可对接的通信方式 - 在
settings.json中配置"xxx.enable": true和"xxx.serverPath"，路径必须指向可执行二进制（不是源码或脚本入口）
常见失败点：LSP 进程启动后立即退出，通常因缺少依赖（如 Rust 的 libc 版本）、权限问题（macOS Gatekeeper 拦截），或工作区根目录下缺失必要配置文件（如 pyproject.toml 对应 Python 工具链）。
调试支持往往需要单独适配，不能复用 LSP
即使语言已有成熟 LSP，也不代表能直接调试。VSCode 的调试器基于 debugger 扩展协议，与 LSP 分离。要启用断点、变量查看等功能，必须：
- 确认存在
xxx-debug类扩展（如ms-vscode.go-debug已弃用，改用golang.go内置） - 检查
launch.json中type字段是否匹配扩展注册的调试类型（如"type": "zig"要求扩展声明了zig调试器） - 某些新语言（如
V、Odin）尚无调试器实现，此时只能靠日志或 REPL 临时替代
真正卡住的地方往往不是“怎么加”，而是“谁来维护”——一个没人在 upstream 更新的扩展，半年后可能因 VSCode API 变更（如 vscode.workspace.findFiles 返回值类型变化）而彻底失效。
