为什么需要 @types/react？ 解决"无法找到模块 react 的声明文件"报错
如果你刚刚开始在 React 项目中引入 TypeScript，或者在克隆了一个新项目后开心地写下第一行 import React from 'react'，你大概率会遇到下面这个令人抓狂的红色波浪线报错：
❌ TS7016: Could not find a declaration file for module 'react'. '...' implicitly has an 'any' type. (中文：无法找到模块"react"的声明文件。"user/..."隐式拥有 "any" 类型。)
按照网上的教程，你在终端敲下了两行命令，报错神奇地消失了：
Bash
npm i
npm i -D @types/react @types/react-dom问题虽然解决了，但作为一个严谨的开发者，我们不禁要问：这两步操作到底在底层做了什么？为什么加上 @types 就能拯救 TypeScript？ 今天，我们就来扒一扒这个经典报错背后的原理。
TypeScript 为什么会报错？
要理解这个报错，首先要明白 TypeScript 的核心工作机制：静态类型检查。
当有 import React from 'react' 时，ts会去 node_modules 里找 React。
它确实能找到 React 的代码，但问题是，React 最早是使用纯 JavaScript 编写的，官方主包里并没有包含 TypeScript 所需的类型声明文件（.d.ts） 。
- JavaScript 的视角：只要有代码能跑就行，参数随便传，返回值我不管。
- TypeScript 的视角 ：没有
.d.ts说明书，我怎么知道useState接收什么参数？怎么知道useEffect会返回什么？ 认为它是any类型，并给你抛出一个警告！
这就是报错"无法找到声明文件"的根本原因。
解决❕
npm i
当你在项目根目录（带有 package.json）执行 npm i 时，npm 会将项目依赖下载到 node_modules 中。
对于 React 来说，这一步下载的是 React 和 React DOM 的纯 JavaScript 运行代码。
有了它，你的项目就能在浏览器里跑起来了。
但是，TypeScript 依然看不懂，红线依然存在。
npm i -D @types/react @types/react-dom
这才是解决 TS 报错的真正杀手锏。
@types是什么？ 社区里有一个非常伟大的开源项目叫做 DefinitelyTyped 。由于很多早期的经典 NPM 包（比如 React、Lodash、JQuery）都是纯 JS 写的，没有 TS 类型。热心的社区大佬们就专门为这些包编写了独立的类型声明文件，统一发布在@types/xxx的命名空间下。@types/react就是社区专门为 React 编写的 TypeScript "词典"。- 自动识别机制 ： 当你安装了这些
@types包后，它们会被存放在node_modules/@types/目录下。TypeScript 编译器极其聪明，它的默认配置会自动去扫描这个目录。 现在，当它再看到import React from 'react'时，它会主动去@types/react里找到对应的.d.ts文件。拿到说明书后，质检员满意了，红色的波浪线也就消失了。 - 为什么用
-D（--save-dev）？-D表示将这些包安装为开发依赖 。这是一个非常标准的最佳实践。因为 TypeScript 的类型检查仅仅发生在你的开发和编译阶段。一旦代码被编译成 JavaScript 并在用户的浏览器中运行，这些类型文件就毫无用处了。把它们放在开发依赖中，可以避免让生产环境的包变得臃肿。
如果你觉得这篇文章对你有帮助，欢迎点赞收藏！有什么疑问也欢迎在评论区留言交流。