React Native TypeScript项目@typescript-eslint报'Record'未定义问题

这个报错和TypeScript本身的识别能力没有任何关系，问题出在原生ESLint核心规则no-undef和TypeScript类型系统的适配断层：

• 你能通过cmd+click跳转到Record的定义、项目整体运行正常，说明TypeScript的编译、类型解析链路完全通畅，Record确实是TS内置声明中存在的合法类型。
• no-undef是ESLint原生的纯JavaScript规则，设计初衷是检查JS代码里未声明的全局变量，它根本不会自动读取TypeScript的lib配置，也识别不了TypeScript特有的内置工具类型（Record、Partial、Pick这类），所以哪怕TS能正常解析这些类型，ESLint也会把它们误判成没有定义的标识符。

结合你的React Native + TypeScript 4.1.4环境，按优先级选择修复方式：

• 第一优先级：关闭ESLint原生的no-undef规则
  这是@typescript-eslint官方明确要求的适配操作——TypeScript本身的类型检查已经完全覆盖了「未定义标识符」的校验，原生no-undef规则对TS代码不仅冗余，还因为不理解TS的类型系统，频繁产生无意义的误报。
  操作很简单：找到项目根目录下的ESLint配置文件（.eslintrc.js/.eslintrc.json这类），在rules配置块里添加规则关闭项：

  "no-undef": "off"
  

  十有八九报这个错的项目，都是当初搭建ESLint配置的时候漏了这一步，没跟着@typescript-eslint的官方推荐规则集完整配置。
• 临时适配方案（不推荐长期使用）：
  如果你因为历史项目的包袱实在没法直接关掉no-undef，可以在ESLint的全局变量配置块里，手动给TS内置工具类型声明全局身份，绕开规则的检查：

  "globals": {
    "Record": "readonly",
    "Partial": "readonly",
    "Pick": "readonly"
  }
  

  这种方式需要你手动维护所有用到的TS内置类型列表，越到后面维护成本越高，远不如直接关规则来得干净。

• 确认项目tsconfig.json里的lib配置是否包含es5或更高版本的ES声明——Record类型本身就定义在es5对应的TS lib文件里，你都能跳转到对应定义了，这一项基本不会有问题，只是顺手核对下避免遗漏。
• 你在VS Code里配置的typescript.tsdk只负责给IDE提供TS版本的提示能力，和ESLint的运行逻辑完全独立，不要指望这个配置能帮你修复ESLint的识别问题。
• 确认项目本地安装的eslint、@typescript-eslint/parser、@typescript-eslint/eslint-plugin版本和你用的TypeScript 4.1.4是兼容的，版本错配会进一步导致ESLint认不出TS的语法和类型上下文。

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