问在typescript中总是使用.tsx而不是.ts有什么缺点吗？

EN

您可以使用tsx而不是ts，差别很小。tsx显然允许在TypeScript中使用jsx标记，但这引入了一些解析歧义，这使得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

为了保持一致性，我也会在ts文件中使用as而不是<>。as实际上是在TypeScript中引入的，因为<>在tsx中不可用。

不能正确解析没有约束的泛型箭头函数

下面的箭头函数在ts中是正常的，但在tsx中出现错误，因为<T>在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文件向后兼容方面发挥了很大作用。

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

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

但是，您的文件扩展名并不重要，只要您的预处理器知道您的决定(browserify或webpack)。就我而言，我所有的JavaScript都使用.js，即使它们是React。同样的道理也适用于TypeScript、ts/tsx。

编辑

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

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

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

使用.tsx扩展意味着模块与React相关，并使用JSX语法。如果不是这样，扩展可能会给人关于模块内容和在项目中角色的错误印象，这是默认情况下反对使用.tsx扩展的理由。

另一方面，如果一个文件与React相关，并且在某些时候有很好的机会包含JSX，那么它可以从一开始就被命名为.tsx，以避免以后重命名。

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