Sublime Text 默认不支持 NestJS 的 TypeScript 智能感知，需安装 SublimeLSP + LSP-typescript 插件并正确配置 tsconfig.json；import 报错但运行正常是因未启用 tsserver；高效开发应依赖代码片段、手动跳转定义及终端构建反馈，而非强求装饰器类型推导。
Sublime Text 本身不支持 NestJS 项目开箱即用的智能感知、依赖跳转或装饰器语义检查——它不是 TypeScript 的 IDE，强行当 IDE 用会卡在 @Module、@Controller 这类装饰器上无法解析类型，最终浪费调试时间。
为什么 Sublime Text 打开 NestJS 项目后 import 报错但实际能运行
这是典型 TS 语言服务未激活的表现。Sublime Text 默认只做语法高亮，不启动 tsserver，所以 import { Injectable } from '@nestjs/common' 会被标红，但 Node.js 运行时完全不受影响。根本原因在于：TS 类型检查和模块解析是两个阶段，Sublime 不参与后者。
- 必须手动安装
SublimeLSP+LSP-typescript插件，且确保typescript-tslint-plugin或@types/node等包已安装到项目本地node_modules - 检查
tsconfig.json中"baseUrl"和"paths"是否被LSP-typescript正确读取（默认不支持别名路径自动补全，需额外配置"plugins"字段） - 常见错误现象：
Cannot find module '@nestjs/common'提示持续存在 → 实际是 LSP 没加载到node_modules/@nestjs/common/package.json中的"types"字段
在 Sublime 中高效写 NestJS 模块的三个实操技巧
放弃“全自动补全”幻想，聚焦可落地的提效点：
- 用
Ctrl+Shift+P（Win/Linux）或Cmd+Shift+P（Mac）调出命令面板，输入Insert Snippet，选择预置的NestJS Controller片段（需提前安装Sublime-NestJS-Snippets插件），避免手敲@Get()、@Post()装饰器拼写错误 - 对
providers数组中的服务类，手动补全后立刻按F12（跳转定义）——仅当LSP-typescript正常工作时有效；否则右键 →Go to Definition会失败，此时改用Ctrl+P输入文件名快速定位 - 修改
app.module.ts后，不要等 Sublime 自动刷新依赖图，直接执行npm run build，观察终端报错位置比编辑器提示更准确（尤其涉及循环依赖时）
nest g resource users 生成的代码在 Sublime 里为何类型推导失效
CLI 生成的 DTO、Entity、Controller 文件都依赖 class-validator 和 class-transformer 的装饰器（如 @IsEmail()），而 Sublime 的 LSP 默认不加载第三方装饰器的类型定义。结果就是 user.dto.ts 里所有验证装饰器下划线标红，但 tsc 编译完全通过。
- 解决路径只有两条：要么在
tsconfig.json的"compilerOptions.plugins"中显式加入{"name": "@nestjs/common"}（不推荐，LSP 支持不稳定） - 要么接受现实：把这类文件当作“运行时契约文档”，专注逻辑层（
users.service.ts）的类型安全，验证逻辑的正确性靠单元测试覆盖，而非编辑器提示 - 性能影响：开启全量装饰器类型检查会使
tsserver内存占用翻倍，Sublime 在大型 NestJS 项目中可能响应延迟明显（>1s）
真正卡住开发节奏的，往往不是 Sublime 能不能识别 @Injectable()，而是你是否清楚哪个 providers 需要加 useClass、哪个该用 useValue——这些决策藏在 NestJS 的模块作用域规则里，和编辑器无关。
