回答。

问题的背景

TypeScript 最初在设计时就考虑到了与 JavaScript 的平滑过渡，因此默认情况下，未显式指定类型的变量或参数会得到 any 类型。这使得迁移变得简单，但降低了静态类型的优势。为了提高代码的可靠性和可预测性，TypeScript 团队引入了编译器标志 noImplicitAny，要求显式指定类型或让 TypeScript 有能力正确推导其类型。

问题

当 noImplicitAny 被禁用时，开发者可能会不小心忽略显式指定变量、参数或函数返回值的类型。这使代码的安全性降低，并且使重构变得困难：与类型相关的任何错误在编译期间不会被发现，仅在运行时表现出来。

解决方案

在 tsconfig.json 文件中启用 noImplicitAny 会导致 TypeScript 编译器在每次隐式使用 any 类型时抛出错误。这要求开发者对类型保持高度关注，使重构过程风险降低，代码本身也更可靠。

代码示例：

// tsconfig.json
{
  "compilerOptions": {
    "noImplicitAny": true
  }
}

// 参数类型未指定的示例函数
function printUser(user) {
  console.log(user.name); // 编译错误，如果未指定类型
}

// 正确：
function printUser(user: { name: string }) {
  console.log(user.name);
}

关键特点：

要求在任何模糊的地方显式指定类型。
使大部分类型错误在编译阶段得以发现。
在大型项目中确保代码的高度可预测性和安全性。

可能误解的问题。

启用 noImplicitAny 是否总能防止项目中的所有潜在类型错误？

不，这个标志仅消除了隐式 any。显式使用 any 仍然是允许的。为了完全保护，应该通过 linting 和审查限制显式 any。

如果类型自动推导，noImplicitAny 仍然会报错吗？

不会，如果 TypeScript 能够正确推导类型（例如通过初始化），则不会出现错误。例如：

let n = 123; // 类型为 number，不是 any

启用 strict 是否会自动启用 noImplicitAny？

是的，strict 标志启用许多严格的检查，包括 noImplicitAny。但如果需要，可以手动禁用它。

常见错误和反模式

在很多地方留有显式 any — 失去了严格类型的意义。
在大代码中不运行启用 noImplicitAny 的项目，寄希望于 "或许" — 隐藏很多错误。
添加类型 "随便，加上就行"，不考虑准确性。

生活中的示例

负面案例

在项目中禁用了 noImplicitAny，大多数 API 处理程序接受未显式类型的参数。当引入新的业务逻辑时，开发者在属性名称上出错，但错误仅在生产环境中显现。

优点：

代码启动简单快速。
从 JS 迁移更容易。

缺点：

在生产环境中出现可以静态检查出来的错误。
重构和扩展变得复杂。

正面案例

在启用 noImplicitAny 后，所有代码都逐步进行重构，隐式 any 被消除。开始使用带有类型高亮和自动补全的编辑器。新出现的错误立即在构建阶段被修复。