1樓：張振衣
ST 比較解耦吧，只需要描述結構，拿著值就可以寫型別了，這一點在 ts 之於 js 是非常必要的。不然真的閉關乙個季度改型別，我需求別做了。
還有另乙個角度，叫做如何看待同構（isomorphic）和相等（equal），ST就認為同構只不過是名字不同，實際計算時相等的。而NT就認為名字不同的型別就是不同的。
這裡涉及到型別的數量和複雜性的問題，還有同構的型別的轉換的問題。
在 ts 裡好像很容易說 (1 | 2 | 3) extends number，但如果要用 oo 的視角看我不知道要怎麼看。
ST再說個例子，比如 HOC in react，就是乙個 HOC:: Component => Component，其中 Component:: T => Element，這樣定義是 ST 的，我覺得是合適的抽象。
如果放很多不同的 NT 的型別，再互相 extends，我覺得不好。HOC 模式被那麼多庫使用，這些庫也不可能用相同的 NT。
一次再解釋
我今天又思考了一下，關於怎麼說明 ST 比較解耦這個觀點。
我們考慮型別的 extends 關係，我們會有
也有而沒有 也沒有 。(經 @某兔 指正，這裡選用 never 和 unknown 作為 TS 中事實的 bottom type 和 top type)
這裡構造了乙個 partial order，也包含了結構化的資料互相 extends 的關係。在 ST 裡。
而如果在 NT 裡，我們自然也可以定義 extends，但這裡的 extends 就是顯式的定義 class A extends B，而沒有定義 extends 關係的型別就是不相互 extends 的。
這就帶來了問題，即我希望型別是 js 中的資料的標註，而非讓 js 的資料必須依託乙個型別才能實現。如果是後者，我在定義乙個函式的 argument 的時候，必然需要 import 乙個 type 作為 argument 型別，否則便不能成立。
這個產生比 ST 更高的要求，即函式的呼叫方和定義方都需要顯式的 import 那個特定型別的名字，而不能單純的從例項構造乙個標註。那麼確實是 ST 靈活些的。
比如我們考慮函式 (obj: ): string => obj.value + '!'; 它接收乙個 obj 引數，在 NT 裡，就得寫作
import from 'somewhere';
const f = (obj: Obj): string => obj.value + '!';
呼叫 f 的函式也得 import 乙個。而在 ST 裡不用。
如果我們再拓展一下，在 js 裡，即使 obj.value 是乙個 number，把它和 string 連起來也不會報錯，這讓 js 具備了【更靈活】的可組合性，不報錯就可以執行的神一般的可組合性，當然這就太靈活了。而 NT 就太嚴格了。
不過我感覺 TS 出乙個也可以哦，某種語法下可以隱藏結構而只在乎名字。（經 @賀師俊 指正原先的想法太隨意了）
typescript能否使用高階型別解決根據方法入參生成動態型別的問題？
HDDDDD 按我理解如果你的函式也有type，可以用infer 推斷出來的這篇文章可以學下ts比較深入的用法Typescript 高階語法高階 WuYang export type PickPayload Type Types extends?P never const ADD ADD const...
Typescript高階型別Record
白完 追星的前提是過好自己的生活！追星的前提是過好自己的生活！追星的前提是過好自己的生活！如果題主是第一次考六級的話，絕大部分人都是建議去考試噠。但是題主刷分的話選老林也是闊以噠。 群群群 看情況，要是我在這之前一直好好準備了，那我就去考，畢竟四六級能考的次數也就那麼多。喜歡JJ這麼多年，估計他也不...
TypeScript中的never型別具體有什麼用？
崮生 export async function proxy api fun par P Promise par P,Promise data 這個方法要求api一定返回data 也就是 T data 但實際上有些介面他喵的沒有data這個時候我一般定義data為never型別，我覺得這個場景應該算...