您可以使用tsx而不是ts几乎没有区别。tsx显然允许jsx在 TypeScript 中使用标签，但这引入了一些解析歧义，使 tsx 略有不同。根据我的经验，这些差异不是很大：

输入断言<>不起作用，因为它是 jsx 标签的标记。

TypeScript 有两种类型断言语法。他们都做完全相同的事情，但一个在 tsx 中可用，另一个则不是：

let a: any;
let s = a as string // ok in tsx and ts
let s2 = <string>a // only valid in ts

为了保持一致性，我也会在文件中使用as代替。实际上是在 TypeScript 中引入的，因为在.<>tsas<>tsx

没有正确解析没有约束的通用箭头函数

下面的箭头函数在 in 中没问题，ts但tsxas 中的错误<T>被解释为 in 中的标记的开始tsx：

 const fn = <T>(a: T) => a

您可以通过添加约束或不使用箭头函数来解决这个问题：

 const fn = <T extends any>(a: T) => a
 const fn = <T,>(a: T) => a // this also works but looks weird IMO
 const fn = function<T>(a: T) { return a;}

笔记

虽然您可以使用tsx代替ts，但我建议您不要使用它。约定是一种强大的东西，人们会联想tsx到jsx并且可能会惊讶于您没有任何jsx标签，最好将开发人员的惊喜降到最低。

虽然上面的歧义（虽然可能不是完整列表）并不大，但它们可能在决定为新语法使用专用文件扩展名以保持ts文件向后兼容方面发挥了重要作用。

x当您的 JavaScript 处于JSX Harmony模式时，这是最终使用的一种约定。也就是说，当它有效时：

doSomething(<div>My div</div>);

但是，您的文件扩展名并不重要，只要您的预处理器知道您的决定（浏览器或 webpack）。一方面，.js我使用我所有的 JavaScript，即使它们是 React。这同样适用于typescript，ts/tsx。

编辑

现在，我强烈建议对带有 React 语法的 Javascript 使用 JSX，对带有 React 的 TypeScript 使用 TSX，因为大多数编辑器/IDE 将使用扩展来启用或不启用 React 语法。它也被认为更具表现力。

引入 .jsx 扩展名的原因是 JSX 是 JS 语法的扩展，因此 .jsx 文件不包含有效的 JavaScript。

TypeScript 通过引入 .ts 和 .tsx 扩展遵循相同的约定。一个实际的区别是 .tsx 不允许<Type>类型断言，因为语法与 JSX 标签冲突。as Type断言被引入作为<Type>.ts 和 .tsx 中一致性原因的替代并被认为是首选。如果 .ts 中的代码用于 .tsx 文件，<Type>则需要修复。

.tsx 扩展名的使用意味着module与 React 相关并使用 JSX 语法。如果没有，扩展名可能会给module内容和项目中的角色留下错误的印象，这是默认情况下反对使用 .tsx 扩展名的论据。

另一方面，如果一个文件与 React 相关并且在某个时候很可能包含 JSX，则可以从一开始就将其命名为 .tsx 以避免以后重命名。

例如，与 React 组件一起使用的实用程序函数可能在任何时候都涉及 JSX，因此可以安全地使用 .tsx 名称，而Redux 代码结构不应该直接使用 React 组件，可以与 React 分开使用和测试并且可以使用 .ts 名称。

我相信对于 .tsx 文件，您可以使用所有 JSX（JavaScript XML）代码。而在 .ts 文件中，您只能使用typescript。

.ts文件的<AngleBracket>类型断言语法与 JSX 语法冲突。为了避免破坏大量的人，我们使用.tsx了 JSX，并添加了和文件foo as Bar中都允许的语法。.ts.tsx

let someValue: any = "this is a string";
let strLength: number = (<string>someValue).length;

另一个是 as 语法：

let someValue: any = "this is a string";
let strLength: number = (someValue as string).length;

我们可以使用 .ts ，as-syntax但是<string>someValue很酷！