現在 TypeScript 的生態如何？

01-14

國內又是如何呢？
個人目前遇到的最大問題是，缺少某些 Type Definition 文件。

謝邀

截止目前，此問題共有151人關注，3人回答。這已側面回答樓主的半個問題：TypeScript 在國內的生態並不成熟。

但是，在2014年3月白鷺引擎 v0.9 版本第一次發布的時候，除了少數開發者認同（主要是和 TypeScript 非常相似的 ActionScript 3.0 開發者）之外，絕大部分 JavaScript 開發者在質疑：為什麼不直接用 JavaScript ，非得多此一舉弄個什麼沒聽說過的 TypeScript ? 而目前，越來越多的開發者（無論是否使用白鷺引擎）已經認可了 TypeScript 的價值。

我認為，這主要是微軟對 TypeScript 的定位清晰、野心龐大並且心胸開闊決定的。（ P.S：我真的不是軟粉）

我第一次了解 TypeScript 是2013年，Adobe 的 Flash Player 產品經理宣布離開 Flash 團隊並參與到 Adobe 的一個OpenWeb 相關的項目中（至今我也不知道到底是啥項目），當時他說他已經不再搞 AS3 了，並給大家推薦 TypeScript 。在那個時候，TypeScript 給人的感覺就是單純的 JavaScript + ActionScript （或者說是 ES4，這其中的淵源大家可以自行百度谷歌）。

在 TypeScript 進化的過程中，我認為幾個關鍵節點是：

1. TypeScript 1.1發布

這個版本重寫了全部編譯器代碼，大幅提升性能（在白鷺引擎的實際項目測試結果至少提升了三倍），並且不再託管在微軟自身的開源代碼倉庫（不好意思忘了叫什麼了，我又不是軟粉，怎麼會記得這種東西╮(╯▽╰)╭ ）而是改為了在 GitHub 上託管。

2. TypeScriptService 發布和穩定

TypeScript 開源了其抽象語法樹分析器，並提供友好的 API 介面，這被稱為 TypeScriptService，這使得第三方 IDE 可以非常快速的提供 TypeScript 代碼補全、類型檢查、代碼重構等支持，而不是把開發者綁定在 VisualStudio 和微軟體系中。

3. TypeScript 1.6 發布

TypeScript 從1.5開始開始支持 ES6 特性，並且廢棄了和 ES6 矛盾的 module 關鍵字。從這點可以看出，在 ES6 標準出台之後，TypeScript 堅定遵循標準，而非自己制定「標準」的決心和魄力。在 1.6版本中，TypeScript 實現了幾乎所有的 ES6 新特性，並能將其編譯為 ES5，就像開源社區風頭很勁的 Babel 一樣。由於 TypeScript 遵循並實現了 ES6 標準，TypeScript 自身的價值變得更大，因為只要掌握了 TypeScript ，就相當於掌握了 JavaScript 語言的最新標準，並且能在老式瀏覽器上完整運行。

除此之外，TypeScript 1.6 支持 Facebook React 框架，由於 Facebook 引入了 JSX 這個神奇的標籤語法以及組件化編程思想，強類型變得更加必要（如果你看了 React 的 PropsType 你就知道我在說什麼），相比 PropsType 這樣在運行時進行類型檢查，TypeScript 的編譯時檢查顯然可以讓開發變得更有效率。

4. VSCode 發布

VSCode 是微軟的第一款（可能是，求確認）跨平台開發工具，他使用了大量的開源社區的優秀技術以至於如果把 VS 這兩個字母去掉的話，幾乎根本看不出這是一款微軟的產品。VSCode 包含了對一個文本編輯器來說非常優秀的 JavaScript 代碼分析能力，但是如果你通過一個簡單的命令，下載一個框架定義文件，這種代碼分析和智能感知能力立馬感動到哭。以一個比較簡單的 jQuery 為例：

而這裡的奧秘，就是 VSCode 採用 TypeScriptService 來分析 JavaScript 代碼，以及用 TypeScript Definitions File 來做 API 支持。這意味著 TypeScript 自身已經不僅僅是一門語言，其服務和開源社區貢獻的第三方 Definitions 文件已經反哺回饋到 JavaScript 生態中。哪怕是最固執的 JavaScript 開發者以後都可能會在不經意間用到 TypeScript 生態中的內容。

5. ` Salsa ` 項目

Salsa 是一個 TypeScript 新版本的代號（並且確認不是2.0）。在微軟 VSCode 和 TypeScript 的 Github 討論和 Roadmap 中我多次看到了這個代號。VSCode 路線圖提到，通過 Salsa，JavaScript 可以被更加智能的支持。目前我簡單的理解是，在未來，JavaScript 代碼可以直接由 TypeScript 編譯器編譯，也就是說，在可能稍微遙遠的未來，並不存在 TypeScript 這門語言，只存在經典 JavaScript （ ES5）， ES6語法糖，類型檢測混合在一起的新一代 JavaScript 語言，微軟在其中只專註做兩件事：

1. 將ES6語法翻譯成ES5

2. 在「你認為必要的地方」添加類型檢查支持

從上述回答中，我們把黑色字部分提取出來，重新讀一遍

不再託管在微軟自身的開源代碼倉庫

不是把開發者綁定在 VisualStudio 和微軟體系中

遵循標準，而非自己制定「標準」

使用了大量的開源社區的優秀技術

反哺回饋到 JavaScript 生態

只專註做兩件事

這真的是那個我們印象中的，想把所有東西都大包大攬，牢牢控制住開發者衣食住行吃喝拉撒的微軟么？

由此可以看出，遵循國際標準，擁抱開源社區，然後最廣泛的人民群眾群策群力，有人提供運行時支持（ Google Chromium ），有人提供框架支持（ Google AngularJS / Facebook React ），有人提供技術標準（ ES6 / NPM ）有人提供開發工具（ Microsoft TypeScript / Definition / VSCode ) 才能皆大歡喜。埋頭髮明背離 Web標準的新語言的的做法已經不再適用。

關於提主提問的 TypeScript 生態，通過上面的觀點，我認為目前，大家關心的是 TypeScript 「生態」，但也許，微軟其實根本不想做自己的「 TypeScript 生態」，而是用 TypeScript 去完善 JavaScript 生態。畢竟，無論是ES6翻譯為ES5，還是在必要的地方添加類型檢查，都是當下 JavaScript 生態中非常迫切的需求。

在這個大 JavaScript 生態中，Google ( AngularJS ) , Facebook ( React ) 等大廠都是微軟的朋友。

敵人？目前我能想到的可能只有一個

Babel

更新於11月22日

今天看見了 InfoQ 上的一篇文章 Delphi、C#之父Anders Hejlsberg首次訪華推廣TypeScript 感受頗多。自己的很多見解和這篇文章一致，包括 TypeScript 的目標、關注點和主要競爭對手。

謝邀. 作為一個一直在關注 TypeScript 生態發展的同學, 我的觀點可能會比較片面, 但排開個人好惡, 就見聞來講, 多數是正面的.

Angular 2 (Google, 使用 TypeScript 開發), Immutable.js (Facebook, 官方提供數千行的詳盡聲明文件), Asana 這些就不展開了. 而到了國內, 就答主看到的活躍在知乎的一線前端工程師中, 對 TypeScript 持正面評價的還是佔了大多數.

當然叫好不一定叫座. TypeScript 究竟最後是否能擁有繁榮的社區, 顯然也不是我們能左右的事情.

目前 TypeScript 應該已經臨近 1.7 正式版, DefinitelyTyped 倉庫已經有超過 1300 個類庫的聲明文件. 當然, 這裡也和題主遇到的問題撞上了. 沒有聲明文件怎麼辦?

這種情況必然是有的, 通常我的做法是自己寫一個:

如果這個庫穿插在項目的各個地方, 被大量使用, 並且我覺得大體瀏覽一遍它的 API 很有意義, 那我可能會寫一個完整的聲明文件.

如果我覺得這個聲明文件可能被更多的人使用, 自己又正開心, 則可能會補上詳盡的注釋.

以上兩種情況我都會發 PR 到 DefinitelyTyped. 如果覺得沒有必要寫完整, 則通常是用到什麼寫什麼, 成本非常有限. 如果你沒有強迫症, 那或許更開心, 直接 any 解決問題 (當然前提是該庫使用範圍有限).

如果大家使用過 Visual Studio Code, 可能注意到它能夠識別 TypeScript 的聲明文件, 並且用於 JavaScript 開發中的提示和檢查. 這個特性將 (有可能已經) 合併到 TypeScript 中, 未來可以方便地供三方編輯器實現相應功能. 這樣一來, 也能夠推動 JavaScript 開發者為自己的庫提供 .d.ts 聲明文件, 或者至少能夠給流行的 JavaScript 庫將 .d.ts 聲明文件放到倉庫中提供一個很棒理由. 即便作者不自己添加, 也會有像熱心多事的同學去發 PR. 一旦合併, 更新相關聲明文件也就成了庫開發過程中自然的一環了.

當然指望這個去解決聲明文件缺失是不大現實的, 但也增加了大家接觸到 TypeScript 的機會, 能 YY 到一種可能的良性循環.

稍微更新下兩個重點。

1. TypeScript 1.8 開始支持了 AllowJS 選項

所以現在可以直接引用 js 文件而不需要對應的 .d.ts 文件也不會報錯（當然，也就沒有那麼良好的類型提示支持）。

2. DefinitelyTyped （tsd）已死

現在 TypeScript 的 .d.ts 管理已經全面轉向 Typings（GitHub - typings/typings: The TypeScript Definition Manager），後者具有更好的版本控制、平台管理、Registry 管理支持（其實與其說 Typings 多好，不如說 tsd 完全是翔）。

所以，

個人目前遇到的最大問題是，缺少某些 Type Definition 文件。

這個問題目前基本可以視為已解決。

瀉藥，框架級別的都有（好好用TSD工具很舒服了），前陣子用到百度地圖，自己照著官方文檔寫了TD文件(覆蓋50%左右API吧)，用了2年TS也就這麼一次遇到需要大寫第三方TD文件的，其它情況下都是直接用匿名類型，或者只聲明自己用到的幾個方法，這種工作量可以忽略不計的。

最爽的用法是在自己的框架下創建獨立的上下文環境，然後只能調用自己封裝的API(配合node的vm模塊, 很有黑科技既視感)，用這種模式自己封裝了類似PHP的開發體驗，封裝$request，$response等等，造輪子很爽。

至於早年在體制下維護原有的大型開發環境，把原有項目全部翻寫成ts的也干過，5w行代碼（移動網站）以內直接翻寫，50w行代碼的（PC網站）花了2周時間去寫TD文件，可以屏蔽掉很多不建議使用的方法和對象，那個時候JS開發還不支持引用TD文件，所以工作成果1年以後才有人去發掘（我早走了）。

遇到原有項目比如Backbone和React是使用工廠模式創建類型的，一些聲明寫法跟TS的繼承方式的不能完全套用，也都可以手動解決（React官方文檔上都有介紹用ES6的Class寫法）。

直接用於生產2年多了，不用問什麼生態了，生態早就熟透了。

更新一波，最近升級到typescript 2.4 發現@types/react家族有異常，導致TSX組件無法識別的錯誤，發現是由於多個d.ts且緩存，最後處理方案是清理緩存 rm -rf ~/.cache/typescript/

================================================

【Typescript生態見解】

1、Typescript隨著版本升級，對語法的控制和代碼的檢查能力越來越強和智能化，基本上能夠通過類型來約束和達到對開發人員編碼控制。

2、Typescript 相應的工具鏈升級很快，且breaking Change很多，導致時常更換配置，因使用TS需要相應的配套其它框架對應的工具使用，所以導致不同版本可能導致的問題很多很複雜，排查十分困難，當然如果不升級工具也是可以的，但是後續如果想要升級，可能戰線會拉得更長。切換成本也很高，建議採用穩定版本，也無須隨意切換工具。

3、版本升級後，對第三方不嚴格的typings 或者 JS 庫都有提示，提PR或者改進，都會有相應的維護成本。而且通常質量比較低，例如像antd此類庫，質量說真的一般般，但是能夠解決燃眉之急，通常情況下問題不大，但一出問題又需要些時間進行完善，時常fork出一個新的版本，建立補丁包體系可以解決此類問題

4、Typescript 每天都提交commits，所以typescript@next的版本都會有對應的commit，處理問題的時候，可以依賴這些commit查找問題，十分方便，同時也對自己有提升。

5、Typescript 同時主要是兼顧 Angular 2 工具生態，再加上 ng2 主推 Typescript，所以相應來說該工具生態比較成熟，遇到的問題都是主要以解決 ng2為主。其它例如React / Vue等支持度就只能靠各自的生態解決。

下面是分享一下最近一次升級工具鏈的過程：

【起因】階段性更新工具鏈，迭代縮減原Cli工具（簡化合併API指向配置） 【目標】升級版本 React（15.4.1） / Webpack（2.1-Beta27） / Typescript（2.2-1130）包括其周邊的工具版本

【升級產生的問題】編譯成功，vscode提示「antd/lib/xx」找不到該模塊

【分析問題】

1、Typescript 升級後變得更嚴格，可能更換了module定義的方式

2、Antd1.x 版本的d.ts 本身BUG及問題很多

【解決方案】順序使用的解決方案，因為一直失敗

1、通過新增 lib typings，即定義declare module "antd/lib/xx"；

2、COPY 2.x版本的typings 進行修改

3、升級至2.x版本，直接迭代版本（畢竟使用的組件並不太多）

因不太想降低工具的版本，故此選擇以上3個方案進行，比較信任typescript團隊，考慮方向其實沒有正確，最後繼續了以下方案

4、檢查tslint版本（因為vscode提示tslint某個函數找不到）

5、檢查vscode版本（因為一直提示升級，慣性習慣升到最新）

6、回滾代碼至舊版本，因為升級後，webpack config 配置因工具發生了部分改變

7、將npm包還原至升級前的版本

8、對比tsconfig配置

9、不斷切換typescript版本（20+次）一直到找到問題

10、上到官方typescript Github，檢查版本對應的commits

【結果】

1、 alwaysStrict，要求所有導入的代碼必須是嚴格模型，無論配置是true / false，均都不成功。可能因為antd代碼本身可能是混合的模式導致的吧。

2、maxNodeModuleJsDepth：最大node_modules JS模塊查找深度。調整成jsconfig默認是2，tsconfig默認是0，以便提高模塊查找速度。因我去掉了JSConfig，所以導致模塊檢測不到。調整成1即可。

【解決過程遇到的問題】

1、ts-loader 提示 typescript.js 的node.id 找不到

2、使用awesome-typescript-loader編譯速度提升10倍，但同樣也遇到第1點問題

3、awesome-typescript-loader 3.0 beta 版本，提示所有使用antd中的模塊都出現基於原生的語法屬性（如INPUT 缺少 toString，valueOf等）

4、awesome-typescript-loader 2.2.4 版本出現 instance 的 typeOptions.exclude 不存在，那是因為typescript 新版本不再使用 typesOptions，所以代碼有錯，通過新增補丁包，每次編譯前自動COPY過去

5、因為項目使用了echart，而echart恰好又用了zrender，而它正好使用了jsdoc的註解，有個錯誤的註解是@type {private}，而private是保留字，所以提示錯誤，官方issues 有人提出並提交了PR，但是並沒有放出版本，也只能使用補丁包的辦法處理。

6、時常會遇到JSX組件不能夠識別為JSX，儘管批量對代碼進行調整（代碼量很大，好在有批量修改），改好後，往往會遇到編譯不通過的情況。

7、通過google / issues 查找出來的問題往往提供的解決方案更多提說語法上的，但並未真正解決實際上的問題。

【流水帳】

升級發現在vscode里的原來的代碼import 的 antd/lib/xx模塊找不到，開始一整天無止境查問題：

1、修改N次antd.d.ts里，新增『antd/lib/xx』，打包卻出錯出現過n種不同的typescript錯誤，包括typescript里的checkoutXX(node.id)找不到等，切到node_modules的typescript打包文件斷點，無結果。回滾

2、升級antd1.x到2.x最新版（乾脆硬上升級算了），更換react及周邊組件的typings，發現有衝突，刪舊，組件庫屬性不同，批量改N個文件的代碼，無效，回滾

3、重複1-2步，發現新的問題，繼續改，還是沒有結果。改動2.x的typings 還是沒結果，並且官方issues是OPEN狀態（即要等不知N個版本後修改），無結果，回滾。忙碌的一天過去了，靈光一閃。

4、檢查TSLINT版本是不是有問題，檢查VSCODE升級是不是導致問題，切舊版本，無效果，還暴新錯誤，升級最新版本。無效，回滾

5、檢查VSCODE版本問題，下了1.6安裝，無效，繼續回滾

6、檢查TYPESCRIPT版本，代碼版本回滾至上上個版本，發現還是無效，未回滾

7、將NPM包安裝到代碼上上個版本的包版本，發現有效果了。但代碼是上上個版本

8、將代碼checkout到新版本，發現還是有同樣的問題，檢查TSCONFIG，是不是有變化，發現alwaysStrict是多出來的，刪除成功即OK，欣喜，下班回家

9、回家後，將包升到最新。問題依舊，開始typescript版本著手，還原成上上版本的TS版本，成功。不斷切換TS版本（20次+），找到是0826這個版本有問題，欣喜

10、上typescript的github，查找0826日提交的commit，翻了N頁，找到0826的COMMIT，總計提交17個COMMIT，找不到模塊，應該是以EXPORT MODULE為關鍵字，找到了「Fix crash when checking module exports for export=」，直覺告訴我，就在這裡。

11、檢查裡邊所有相關代碼，最終發現TSCONFIG的maxNodeModuleJsDepth被初始為0，是不是關鍵是這個問題呢，直接在TSCONFIG，加個maxNodeModuleJsDepth，改成2，發現成功了，驚喜，發現改成1也是OK的，查找模塊的速度也快些。

當時真的累覺不愛了，忙著業務代碼，一段時間沒堅持每周一次迭代工具，導致的時間被浪費了。

已經很易用了，react.d.ts 甚至已經支持了很新的 default generics，React 周邊的很多倉庫也有對應的 .d.ts 了，可見用 ts 寫 React 的人還是挺多的。

這個問題至今仍然回答很少，也說明了 TypeScript 仍然很冷門。

大概 14 年底開始聽到 TypeScript。因為在用 Angular.js，所以在知道 Angular 2 開始基於 TypeScript 開發之後，就去了解並學習 TypeScript 了。

TypeScript 和 CoffeeScript 是不同的，但我不了解 CoffeeScript 生態，對比不出個一二來。

你可以把 TypeScript 當 Lint 來用，直接在裡邊寫 JavaScript（ES5、ES6）。也可以當做 JavaScript 的增強語言來用，依賴它的 interface、class、module 等特性。

TypeScript 可以編譯到 ES3/ES5/ES6 來使用，所以沒有執行環境的兼容性問題。而且可以編譯成多種 JavaScript 模塊來使用，也支持直接導入或編寫 JavaScript 代碼，與現有的 JavaScript 項目進行整合也沒有困難。

在 Node.js 里使用 TypeScript，只要配好模塊、編譯規則以及各種 tsd，就可以編寫執行了。

在瀏覽器環境里，可以先編譯再執行，也可以使用 jspm/system.js 熱載入 TypeScript 代碼來執行。

Update 2016-05-09 13:11:07

----

TSD 已經被 typings 取代了 Deprecate TSD · Issue #269 · DefinitelyTyped/tsd · GitHub :sad

TypeScript + Angular2 的技術棧仍然不穩定，可以開始學習，但還不建議直接做線上產品。

如有不妥，請指正。

題主發布問題在2015年11月，距離今日快兩年了。

我也是15年開始關注typescript，在2016年10月的時候正式使用（自己的一個項目，非公司），該項目的存儲層用typescript書寫，到目前為止約有1w行左右的代碼(公司為996，周日才有時間)。

只要typescript升級，我的項目跟著升級...

由於是存儲層，所以主要是資料庫操作以及對外提供介面，感覺寫ts比寫js爽得多，基本不需要文檔，就知道方法應該怎麼調用，返回值是什麼類型。也不會出現錯誤跟本都不知道在哪，需要跑幾遍打個debug才能定位問題。

這是最直接的體驗。當然前提是你得事先定義好interface。

至於題主所說第三方類庫支持的情況，在項目剛啟動的時候(2016年10月)，僅僅是使用koa框架及周邊，就折騰了我兩天多時間，基本上都是自己補tds文件，好不容易跑起來了，有一些庫又不支持koa2...

到目前，應該說這個問題已經不大了，大多數庫都已經提供了官方tds，一些不常用的庫，api也不會太多，自己花點時間補上就是了。

例外，我司現在前端服務端（業務層nodejs），客戶端(瀏覽器，主要是數據可視化業務)，也打算使用ts，相關兼容計劃方案已提上議程。

最後

ts大法好！

Typescript 2.0之後，tsd和typings都可以去掉了。要獲得lodash的類型定義文件只需要

npm install @types/lodash

這樣一來，typescript的工作流就和普通的Node.js項目沒什麼區別了。

更重要的是Typescript 2.1之後，async/await可以直接編譯到ES5。babel什麼的，再見吧

白鷺引擎

個人看法：

1）前端開發正在走向大型化，專業化。以往前端附屬於後端的現象，估計很快就會改變。基於這樣的認識，前端開發的語言就是一個大問題。

2）js從誕生之初，就缺乏完整的設計，這麼些年來不斷的修修補補，離開發大型項目的要求仍然很遠。

所以說，機會就在眼前，但是es6/es7都不會獲得這樣的機會了。機遇不會等待es的完善，就讓js變成前端的彙編吧。

以後類似 Complie to JavaScript (List of languages that compile to JS · jashkenas/coffeescript Wiki · GitHub) 的語言會和當年瀏覽器大戰一樣，最終也沒有一個統一的解決方案，開者還是不得不兼容各種版本的瀏覽器，各種版本的 ES

這樣以來 Typescript 的優勢就明顯了，因為他可以 complie to plain javascript 適當的使用甚至可以兼容很老版本的瀏覽器

唯一不好的一點是做為一個語言沒有任何 JS 引擎來原生支持 TS。用 ES 6 可能總有一天可以拋棄 compiler，目前來說這一點 Typescript 沒能讓人看到希望

現在來看已經是很不錯的了，npm的下載量非常高

可以看到，現在TypeScript的下載量已經比三大框架都高出不少，說明大家的認可度還是挺高的

最近用了一下，感覺優勢還是很明顯的，優勢主要體現在以下幾點：

1. JavaScript的超集

支持所有原生JavaScript的語法

2. 強類型語言

現在很多主流語言都是強類型的，而這點也一直是JavaScript所被人詬病的地方。使用TypeScript之後，將會在代碼調試、重構等步驟節省很多時間。

比如說：函數在返回值的時候可能經過複雜的操作，那我們如果想要知道這個值的結構就需要去仔細閱讀這段代碼。那如果有了TypeScript之後，直接就可以看到函數的返回值結構，將會非常的方便

3. 強大的IDE支持

現在的主流編輯器如VSCode、WebStorm、Atom、Sublime等都對TypeScript有著非常友好的支持，主要體現在智能提示上，非常的方便

4. 可運行於任何瀏覽器、計算機、操作系統

強大的編譯引擎

5. 迭代更新快

不斷更新，提供更加方便友好的Api

6. 微軟和Google爸爸

TypeScript是微軟開發的語言，而Google的Angular使用的就是TypeScript，所以不用擔心會停止維護，至少在近幾年內TypeScript都會一門主流開發語言

7. npm下載量非常高

截止2017.12.17, TypeScript在全球範圍內的npm日均下載量在30w左右，這個數字將近是vue下載量的10倍，可見TypeScript還是非常受歡迎的

所以TypeScript是一個非常有意義的項目，也逐漸的被大家所認可。本人平時主要使用Vue框架開發，最近結合Vue和TypeScript寫了一個Demo，讓Vue也可以使用TypeScript開發，寫起來非常過癮

https://github.com/SimonZhangITer/vue-typescript-dpapp-demo

希望大家多多支持~

目前vue + ts ，很爽，有種之前面向eclipse編程的感覺

我看不只是某些吧，缺得太多了。。

我覺得 TypeScript 1.5 以後, 國外很多大公司還在用 JS (ES6+Babel) 寫些重要的開源庫這種行為真是令人費解. 還整什麼 Flow.js. 真是閑的蛋抽筋.

還有那些以 JS 以編譯目標的語言, 居然不出 *.d.ts -&> host-lang 的生成工具, 大把 Type Definition 資源不用, 瞎折騰.

開源的vscode里好多typescript代碼，意外啊

作為一個經常需要和別的人員合作的前端人員覺得真的每當引入一個新技術就需要增加其他人員大量的抵觸和適應時間

因為每增加一個編譯器都是一次build時間增加而且typescript還不和js一樣 Js可以向下兼容會ES6的ES7的寫這些不會的繼續ES4，ES5 所以不會有太大問題而且用的這些新的功能是早晚會被瀏覽器支持的所以用起來很放心所以除非TypeScript受到瀏覽器的支持之前我都不建議在一個不可控的團隊中使用TypeScript 如果你的團隊可控性非常強喜歡新技術那沒任何問題用吧