VS2022升级后React+TS项目Intellisense性能骤降求助
VS2022 17.5.5中TypeScript语言服务卡顿高占用的解决方案
问题背景
我有一个托管在ASP.NET Core WebApi中的中型React应用,用官方React模板创建,包含约100个ts/tsx文件和少量js文件。之前6个月开发体验正常,Intellisense、代码导航、错误提示都能即时响应。但更新VS2022 Pro 64位到V17.5.5(附带Intellicode 2.2、TypeScript Tools 17.0.20105.2003)后,VS几乎无法使用:处理JS/TS的独立Node进程持续高CPU占用,内存消耗约0.7GB,仅打开解决方案就会触发问题。
新建同模板测试项目,添加简单TS文件和依赖后问题重现:hover查看类型、错误提示加载耗时13-15秒,跳转定义时出现进度条,但项目运行不受影响,仅文本编辑体验极差。
已尝试的无效方案
- 多次删除
node_modules和package-lock.json后重启 - 删除
.vs隐藏文件夹后重启 - 纯JS新项目正常,但添加TS后问题重现
- 卸载重装VS2022后重启
- 调整VS选项(如禁用linting)
- 重新拉取远程仓库代码
- 更新NPM版TypeScript、Node.js
关键现象
将tsconfig.json的include设为[]时,性能完全恢复,但无法识别node_modules中的类型,无法正常开发。
项目配置
tsconfig.json
{ "compilerOptions": { "target": "es5", "lib": [ "dom", "dom.iterable", "esnext" ], "allowJs": true, "skipLibCheck": true, "esModuleInterop": true, "allowSyntheticDefaultImports": true, "strict": true, "strictPropertyInitialization": false, "forceConsistentCasingInFileNames": true, "noFallthroughCasesInSwitch": true, "module": "esnext", "moduleResolution": "node", "resolveJsonModule": true, "isolatedModules": true, "noEmit": true, "jsx": "react-jsx" }, "include": [ "src" // 设为空数组时性能恢复,但无法解析包类型 ], "exclude": [ "node_modules" ] }
package.json
{ "name": "omitted", "version": "0.1.0", "private": true, "dependencies": { "@babel/eslint-parser": "^7.21.8", "@reduxjs/toolkit": "^1.9.2", "@types/lodash": "^4.14.191", "@types/react": "^18.0.27", "agentkeepalive": "^4.2.0", "antd": "^5.4.6", "axios": "^0.26.0", "dayjs": "^1.10.7", "http-proxy-middleware": "^0.19.1", "lodash": "^4.17.21", "query-string": "^7.1.1", "react": "^18.2.0", "react-device-detect": "^2.1.2", "react-dom": "^18.2.0", "react-input-mask": "^2.0.4", "react-quill": "^2.0.0", "react-redux": "^8.0.5", "react-router-dom": "^6.8.0", "react-scripts": "^5.0.1", "recharts": "^2.1.14", "redux": "^4.2.1", "rimraf": "^2.6.2", "swagger-ui-react": "^4.15.5", "web-vitals": "^0.2.4", "workbox-background-sync": "^5.1.3", "workbox-broadcast-update": "^5.1.3", "workbox-cacheable-response": "^5.1.3", "workbox-core": "^5.1.3", "workbox-expiration": "^5.1.3", "workbox-google-analytics": "^5.1.3", "workbox-navigation-preload": "^5.1.3", "workbox-precaching": "^5.1.3", "workbox-range-requests": "^5.1.3", "workbox-routing": "^5.1.3", "workbox-strategies": "^5.1.3", "workbox-streams": "^5.1.3" }, "devDependencies": { "@types/node": "^20.1.7", "@types/react-redux": "^7.1.25", "@types/react-router-dom": "^5.3.3", "ajv": "^6.9.1", "cross-env": "^7.0.3", "eslint": "^7.25.0", "eslint-config-react-app": "^6.0.0", "eslint-plugin-flowtype": "^5.7.2", "eslint-plugin-import": "^2.22.1", "eslint-plugin-jsx-a11y": "^6.4.1", "eslint-plugin-react": "^7.23.2", "nan": "^2.14.2", "typescript": "^5.0.4" }, "scripts": { "prestart": "node aspnetcore-https && node aspnetcore-react", "start": "rimraf ./build && react-scripts start", "build": "react-scripts build", "test": "cross-env CI=true react-scripts test --env=jsdom", "eject": "react-scripts eject", "lint": "eslint ./src/" }, "eslintConfig": { "extends": [ "react-app" ] }, "browserslist": { "production": [ ">0.2%", "not dead", "not op_mini all" ], "development": [ "last 1 chrome version", "last 1 firefox version", "last 1 safari version" ] } }
解决方案
1. 精确限定TypeScript扫描范围
既然include设为空数组能恢复性能,说明语言服务扫描src目录时存在瓶颈。可以更精确地指定扫描文件,减少不必要的计算:
"include": [ "src/**/*.ts", "src/**/*.tsx" ], "exclude": [ "node_modules", "build", "public", "src/**/*.test.ts", "src/**/*.test.tsx" ]
2. 禁用VS的TypeScript增量检查
打开VS2022选项:
- 进入
工具 > 选项 > 文本编辑器 > JavaScript/TypeScript > 项目 - 取消勾选
启用增量编译 - 重启VS后观察性能变化
3. 切换VS使用项目本地TypeScript版本
VS默认自带的TS工具版本可能和项目依赖的v5.0.4不兼容:
- 打开VS命令面板(Ctrl+Shift+P)
- 输入
TypeScript: Select TypeScript Version - 选择
Use Workspace Version (5.0.4)
4. 禁用IntelliCode的TS辅助功能
IntelliCode的部分功能可能和新版本VS的TS服务冲突:
- 进入
工具 > 选项 > IntelliCode > JavaScript/TypeScript - 取消勾选
启用IntelliCode JavaScript/TypeScript体验 - 重启VS
5. 降级VS2022到旧稳定版本
如果上述方案无效,可暂时降级到更新前的版本(如17.4.x):
- 打开VS Installer,点击
修改旁的更多 > 查看已安装的产品 - 选择旧版本安装,同时关闭自动更新,等待微软修复该版本的TS服务问题
6. 优化TS编译选项(妥协方案)
调整compilerOptions减少语言服务计算量:
- 确保
skipLibCheck保持true,跳过库文件类型检查 - 若项目允许,可关闭
strict模式下的部分子选项(如strictNullChecks),但不推荐作为首选方案
内容的提问来源于stack exchange,提问作者Michael K
相关产品推荐
相关产品推荐

