我知道这有点过时了，但这里可能有更好的解决方案。

当需要字符串，但希望字符串只匹配某些值时，可以使用enum。

例如:

enum Fruit {
    Orange = "Orange",
    Apple  = "Apple",
    Banana = "Banana"
}

let myFruit: Fruit = Fruit.Banana;

现在您将知道，无论如何，myFruit将始终是字符串“Banana”(或您选择的任何其他可枚举值)。这对很多事情都很有用，无论是将类似的值分组，还是将用户友好的值映射到机器友好的值，同时强制和限制编译器允许的值。

当你这样做的时候:

export type Fruit = "Orange" | "Apple" | "Banana"

…你正在创建一个名为Fruit的类型，它只能包含字面意义上的“Orange”、“Apple”和“Banana”。这种类型扩展了String，因此可以将它赋值给String。但是，String没有扩展"Orange" | "Apple" | "Banana"，所以不能分配给它。String不太具体。它可以是任何字符串。

当你这样做的时候:

export type Fruit = "Orange" | "Apple" | "Banana"

const myString = "Banana";

const myFruit: Fruit = myString;

.．.它的工作原理。为什么?因为在这个例子中myString的实际类型是“Banana”。是的，“香蕉”就是那种类型。它是extends String，所以它是可赋值给String的。此外，当一个类型扩展Union type的任何组件时，它也扩展了Union type。在本例中，类型“Banana”扩展了“Orange”|“Apple”|“Banana”，因为它扩展了它的一个组件。因此，“香蕉”可分配给“橙子”|“苹果”|“香蕉”或水果。

有几种情况会给出这种特定的错误。在OP的情况下，有一个显式定义为字符串的值。我必须假设这可能来自下拉列表，或者web服务，或者原始JSON字符串。

在这种情况下，一个简单的类型转换<Fruit> fruitString或fruitString as Fruit是唯一的解决方案(参见其他答案)。您永远无法在编译时对此进行改进。[编辑:查看我关于<const>]的其他答案!

然而，当在代码中使用不打算为字符串类型的常量时，很容易遇到同样的错误。我的回答集中在第二种情况:

---

首先:为什么'神奇'字符串常量往往比enum更好?

我喜欢字符串常量相对于枚举的方式——它紧凑而“javascript” 如果您正在使用的组件已经使用字符串常量，则更有意义。 为了获得枚举值而导入“枚举类型”本身就很麻烦 无论我做什么，我希望它是编译安全的，所以如果我添加从联合类型中删除有效值，或键入错误，那么它必须给出一个编译错误。

幸运的是当你定义:

导出类型FieldErrorType = 'none' | '缺少' | '无效'

.．.你实际上是在定义一个类型的联合，其中'missing'实际上是一个类型!

我经常遇到'not assignable'错误，如果我在我的typescript中有一个像'banana'这样的字符串，编译器认为我的意思是它是一个字符串，而我真的想让它是香蕉类型。编译器的智能程度取决于代码的结构。

下面是我今天得到这个错误的一个例子:

// this gives me the error 'string is not assignable to type FieldErrorType'
fieldErrors: [ { fieldName: 'number', error: 'invalid' } ]

一旦我发现'无效'或'香蕉'可以是一个类型或字符串，我意识到我可以断言一个字符串为该类型。本质上是将其转换为自身，并告诉编译器不，我不希望这是一个字符串!

// so this gives no error, and I don't need to import the union type too
fieldErrors: [ { fieldName: 'number', error: <'invalid'> 'invalid' } ]

那么，仅仅“转换”为FieldErrorType(或Fruit)有什么问题呢?

// why not do this?
fieldErrors: [ { fieldName: 'number', error: <FieldErrorType> 'invalid' } ]

它不是编译时安全的:

 <FieldErrorType> 'invalidddd';  // COMPILER ALLOWS THIS - NOT GOOD!
 <FieldErrorType> 'dog';         // COMPILER ALLOWS THIS - NOT GOOD!
 'dog' as FieldErrorType;        // COMPILER ALLOWS THIS - NOT GOOD!

为什么?这是typescript，所以<FieldErrorType>是一个断言，你告诉编译器狗是一个FieldErrorType!编译器将允许它!

但是，如果你执行以下操作，编译器会将字符串转换为类型

 <'invalid'> 'invalid';     // THIS IS OK  - GOOD
 <'banana'> 'banana';       // THIS IS OK  - GOOD
 <'invalid'> 'invalidddd';  // ERROR       - GOOD
 <'dog'> 'dog';             // ERROR       - GOOD

只是要注意像这样愚蠢的错别字:

 <'banana'> 'banan';    // PROBABLY WILL BECOME RUNTIME ERROR - YOUR OWN FAULT!

另一种解决这个问题的方法是强制转换父对象:

我的定义如下:

   export type FieldName = 'number' | 'expirationDate' | 'cvv';
   export type FieldError = 'none' | 'missing' | 'invalid';
   export type FieldErrorType = { field: FieldName, error: FieldError };

假设我们得到了一个错误(string not assignable error):

  fieldErrors: [ { field: 'number', error: 'invalid' } ]

我们可以像这样“断言”整个对象为FieldErrorType:

  fieldErrors: [ <FieldErrorType> { field: 'number', error: 'invalid' } ]

然后我们避免必须执行<'invalid'> 'invalid'。

那么错别字呢?<FieldErrorType>不只是断言右边的任何类型为该类型。在这种情况下不会——幸运的是，如果你这样做，编译器会报错，因为它足够聪明，知道这是不可能的:

  fieldErrors: [ <FieldErrorType> { field: 'number', error: 'dog' } ]

例如，如果在模拟数据时转换为下拉值[]，则将其组合为具有value和display属性的对象数组。

例子:

[{'value': 'test1', 'display1': 'test display'},{'value': 'test2', 'display': 'test display2'},]

当传递道具到React组件时，我也遇到了类似的问题。

原因:我在myArray上的类型推断没有正确工作

https://codesandbox.io/s/type-string-issue-fixed-z9jth?file=/src/App.tsx

特别感谢Reactiflux的Brady在这个问题上的帮助。

我知道这有点过时了，但这里可能有更好的解决方案。

当需要字符串，但希望字符串只匹配某些值时，可以使用enum。

例如:

enum Fruit {
    Orange = "Orange",
    Apple  = "Apple",
    Banana = "Banana"
}

let myFruit: Fruit = Fruit.Banana;

现在您将知道，无论如何，myFruit将始终是字符串“Banana”(或您选择的任何其他可枚举值)。这对很多事情都很有用，无论是将类似的值分组，还是将用户友好的值映射到机器友好的值，同时强制和限制编译器允许的值。