配置Neovim LSP时tsserver与eslint的诊断功能有什么区别？

二者的诊断能力从设计目标上就完全不同，即便关闭ESLint所有格式相关规则，二者的重叠度也极低，属于互补关系，核心差异如下：

• tsserver的诊断能力边界
  所有诊断逻辑完全围绕TypeScript语法合法性、类型系统安全性设计，仅覆盖两类场景：
  1. 语法错误：不符合ECMAScript/TypeScript语法规范的写法，比如括号不闭合、TS类型注解书写错误
  2. 类型安全问题：比如类型不匹配、访问不存在的对象属性、函数传参不符合类型约束、泛型使用不符合规则这类和类型强相关的问题，以及tsconfig.json中开启的可选检查项，比如未使用的局部变量、未处理的Promise异步错误等
     tsserver的诊断规则完全固定，仅可通过tsconfig.json的compilerOptions开关内置检查项，不支持自定义规则。
• 关闭格式规则后ESLint的诊断能力边界
  即便关掉所有缩进、换行、引号这类格式相关规则，ESLint的核心诊断能力是可高度自定义的代码逻辑、最佳实践检查，覆盖大量tsserver完全不会处理的场景：
  1. 非类型相关的代码质量问题：比如将赋值语句写在判断条件中（if (a = 1)）、禁止使用eval等危险语法、检测生产环境残留的console.debug等调试代码、检测模块循环引用等
  2. 团队/业务自定义规范检查：你可以编写自定义规则实现业务专属校验，比如禁止项目直接调用axios必须使用封装后的请求方法、禁止业务组件超过300行、禁止使用特定废弃API等，这类需求tsserver完全无法实现
  3. 框架/生态专属检查：比如React的Hooks使用规则、Vue的模板语法规范、Next.js的路由文件写法要求等，都是通过ESLint生态的对应插件实现，tsserver没有这类场景的支持

Neovim配置建议 #

原生LSP支持同时挂载typescript-language-server（tsserver的封装）和eslint两个LSP客户端，二者的diagnostic会自动合并展示，没有冲突。你可以通过vim.diagnostic.config为不同来源的诊断配置不同的展示样式、严重级别，优化使用体验。

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