在VS Code中如何为不受支持的语言自定义go to definition功能

通用规则类插件可行性 #

存在可自定义规则的通用工具链实现基础跳转能力，无需从零开发完整插件：

• 优先使用 Universal Ctags 工具，你可以为你的专有语言编写正则匹配规则，抓取函数、类、变量等符号的定义位置与文件路径，生成符号索引文件。VS Code、Vim/Neovim、JetBrains系列编辑器都有适配ctags索引的插件，配置完成后即可实现基础的go to definition能力，开发成本仅需几小时编写匹配规则。
• 如果你的编辑器内置了自定义符号解析功能，比如VS Code的用户自定义语言配置，也可以直接在编辑器配置中写符号匹配规则，不需要额外引入工具。

以上方案仅适合语法简单、无复杂作用域、无函数重载、无跨文件复杂引用的场景，规则匹配的准确率会随语法复杂度提升而下降。

是否需要开发专属插件 #

如果你的专有语言存在以下特性，通用规则方案无法满足跳转准确率要求，才需要开发专属能力：

• 存在函数重载、同名变量分作用域、嵌套类/函数定义
• 需要支持跨文件的引用跳转
• 后续还要扩展代码补全、语法检查、重构等其他语言能力

最佳落地路径 #

按开发成本从低到高选择即可：

1. 优先验证通用规则方案：编写Universal Ctags自定义规则，测试跳转准确率，满足需求就不用继续开发，投入产出比最高。
2. 通用规则无法满足时，优先基于LSP（语言服务器协议）框架开发轻量语言服务器：不需要实现完整的语法解析器，仅需要实现textDocument/definition这一个LSP请求的处理逻辑，针对你的语言做符号解析和索引即可。所有主流编辑器都原生支持LSP协议，一次开发可以适配全平台，比单独开发编辑器专属插件成本更低。
3. 如果你的使用场景仅限定在某一款编辑器，也可以直接开发对应编辑器的专属扩展，比如VS Code扩展、JetBrains插件，仅处理跳转逻辑即可，不需要遵守LSP规范，开发流程更灵活。

内容的提问来源于stack exchange，提问作者JHCS