这个问题本质是ESLint的作用域检查逻辑和TypeScript的模块/全局声明规则之间的小差异，我给你拆解明白：

核心原因：declare global块的作用域被ESLint特殊处理了 #

当你的文件里存在import语句时，它就变成了一个模块文件，而非全局脚本。declare global的作用是在模块内部向全局作用域添加声明，但ESLint在检查这个块内的代码时，会把它当成独立的全局作用域上下文——也就是说，模块顶层导入的typesAsObj，在ESLint眼里是不属于这个全局块作用域的，所以会触发no-undef报错。

而TypeScript编译器本身其实是能识别这个写法的（它知道declare global块属于模块内部，允许引用模块内的导入），但ESLint的静态代码检查逻辑和TypeScript的类型解析是两套独立的机制，所以才会出现“TS编译通过，但ESLint报错”的情况。

第二种写法为什么能正常工作？ #

第二种写法里，我们先在模块顶层定义了_EntityType：

type _EntityType = keyof typeof typesAsObj;

模块顶层的代码处于模块作用域，能正常访问导入的typesAsObj，ESLint也能识别到这个变量是已导入的。之后在declare global块里引用_EntityType时，这个类型是模块内已经定义好的“本地变量”，ESLint能找到它的定义，自然就不会报错了——相当于用中间类型做了个“作用域桥接”，把模块里的类型传递到全局声明块中。

额外补充 #

如果不想用中间变量，也可以通过修改ESLint配置来解决：在eslintrc里给no-undef规则添加例外，或者使用@typescript-eslint/no-undef替代原生规则（TypeScript专属的ESLint规则会更好地识别TS的模块和全局声明逻辑）。不过用中间类型的写法其实更符合TS的最佳实践，也不需要修改配置，是更稳妥的方案。

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