这是一个不错的做法，但是serverId: number = 10是多余的，因为当一个属性被赋值时，number的类型是inferred。
编译器可以轻松推断的显式类型会使代码更加冗长。
除非serverId属性可能最初未定义，但后来定义（例如在constructor函数中），否则可以安全地省略number。
这种方法与noImplicitAny选项配合使用效果最好，因为这样就不会因为类型没有被推断出来而错误地忽略它。

正如上面提到的，它在技术上是多余的，可以被认为是杂乱的。就我个人而言，我不喜欢这种观点，出于各种特定的次要工作流原因，我更喜欢同时拥有类型和值，我不认为它是一个规则的杂乱程度。如果你想禁用它，这里有方法。

• 打开tslint.json
• 找到“不可推断类型”属性
• 将ignore-properties添加到其数组中

相关tslint文档https://palantir.github.io/tslint/rules/no-inferrable-types/

如果您是因为tslint is being deprecated而来到这里寻找ESLint解决方案，请将此规则添加到您的ESLint配置中：

module.exports = {
  // ...
  rules: {
    // ...,
    "@typescript-eslint/no-inferrable-types": "off",
    ...
  },
};

此错误是由于tslint.json文件中的配置造成的。
要么将变量初始化为

serverId = 10;

或

serverId: number;

或者在tslint.json文件中将no-inferrable-types的配置设置为

no-inferrable-types: false

没有必要，它没有提供任何新的信息，它基本上是一个评论说“10是一个数字”。

现在出现这种情况可能有点奇怪，但我也遇到过类似的错误，在我的angular应用程序的tslint.json文件中找不到“no-inferable-types”属性。我不知道为什么它一开始没有生成该属性，但我不得不在这里插入它

"rules": {
    **"no-inferrable-types": false,**
    "directive-selector": [
      true,
      "attribute",
      "app",
      "camelCase"
    ],

然后它就像一个魅力！
P.S.这是为那些可能和我一样在同一个问题上徘徊的人准备的，或者我可能错了，因为任何解决方案中都没有提到必须从json文件的我们端添加这一点。

这可能被看作是噪音，更重要的是键入重要的部分

在 tslint.json 文件中添加或完成以下规则：

"no-inferrable-types": [
  true,
  "ignore-params",
  "ignore-properties"
]

在tslint.json文件中，将no-inferrable-types更改为false：

"rules": {
    ...
    "no-inferrable-types": false,
    ...
    ]