Flow 严格模式
您可以通过在文件添加 **@flow strict** 来在 Flow 中启用更强的安全保障（例如禁止 any/Object/Function 类型并要求所有依赖项都具有类型）。
概述
Flow 的设计初衷是为了易于采用，因此它允许您在某些情况下选择退出类型检查，从而允许不安全的行为。但由于许多代码库现在对 Flow 类型有很高的采用率，因此这种权衡可以被颠倒。您可以使用 *Flow 严格模式* 来禁止以前允许的不安全模式。这为您提供了改进的安全保障，可以捕获更多错误并使重构更容易。您可以逐步地在文件级别实现这些更强的保障。
功能
为文件启用 Flow 严格模式意味着以前允许的几种模式现在将触发 Flow 错误。每个被禁止的模式都有一个相应的 Flow Lint 规则，该规则会触发错误。为 @flow strict 启用的规则列表在每个 .flowconfig 中配置。以下是推荐的规则
nonstrict-import: 当从未标记为@flow strict的模块导入时触发错误。这非常重要，因为它意味着当文件被标记为严格模式时，其所有依赖项也必须是严格模式。unclear-type: 当在类型注解中使用Object、Function或any时触发错误。untyped-import: 当从未类型化的模块导入时触发错误。untyped-type-import: 当从未类型化的模块导入类型时触发错误。unsafe-getters-setters: 当使用可能不安全的 getter 和 setter 时触发错误。sketchy-null: 当对可能为 null/undefined 或假值的值进行存在性检查时触发错误。
有关可用代码风格检查规则的完整列表，请参阅 代码风格检查规则参考。
此外，请注意函数参数被视为常量（即，被视为使用 const 而不是 let 声明）。此功能在 Flow 严格模式中尚不可配置；它始终处于启用状态。
在 .flowconfig 中启用 Flow 严格模式
Flow 严格模式在每个 .flowconfig 中配置。要启用
- 在
.flowconfig中添加一个[strict]部分。 - 列出要启用的代码风格检查规则。这些规则强烈推荐
[strict]
nonstrict-import
unclear-type
unsafe-getters-setters
untyped-import
untyped-type-import
也推荐，但可选，因为它在某些代码库中可能过于嘈杂：sketchy-null
我们建议您从一开始就启用所有所需的规则，然后逐步地在文件级别采用 Flow 严格模式。这比启用单个规则、在许多文件中添加 @flow strict，然后向配置添加更多规则效果更好。
采用
在文件中添加 @flow strict 并修复出现的全部错误。由于 Flow 严格模式要求依赖项也必须是严格模式（如果启用了 nonstrict-import 规则），因此从依赖项树的叶子开始，向上工作。不要添加 $FlowFixMe 来抑制出现的错误；只需在所有问题都解决后添加 @flow strict。由于使用 $FlowFixMe 的最常见原因是依赖于未类型化的依赖项或行为，因此在启用 Flow 严格模式后，将来出现的问题应该会大大减少。
在启用 Flow 严格模式方面要慷慨。与添加或删除 @flow 不同，添加或删除 @flow strict（本身）不会改变 Flow 覆盖范围。它只会阻止或允许将来添加某些新的不安全行为。即使将来必须为该文件禁用 Flow 严格模式，至少在同时阻止了添加不安全行为。
库定义被视为严格模式（因为它们可以包含在具有矛盾的严格模式配置的许多不同项目中）。
本地严格模式
如果您在 Flow 严格模式配置中启用了 nonstrict-import 规则（推荐），那么严格模式文件的全部依赖项也必须是严格模式。虽然这是最佳目标，但对于大型预先存在的代码库，在所有依赖项都成为严格模式之前，允许使用 Flow 严格模式的一些好处可能会有益。
@flow strict-local 与 @flow strict 相同，只是它不要求其依赖项也必须是严格模式（即它是“本地”严格模式）。它没有单独的配置：它使用与 Flow 严格模式相同的配置，只是没有 nonstrict-import 规则。
一旦 @flow strict-local 文件的全部依赖项都成为严格模式，该文件就可以升级到 @flow strict 文件。@flow strict 文件不能依赖于 @flow strict-local 文件，因为这会破坏 nonstrict-import 规则。
展望未来
最终，如果 Flow 严格模式的某些功能证明是成功的并获得了广泛采用，它们可能会成为 Flow 的默认行为。