本文是按着ng2官網的高級內容“Deployment”的思路整理得出的，原文雖然在angular2的中文站下掛着，截止目前卻還是英文版未翻譯，筆者就在這里結合自己的理解給出原文的一點點整理。
這是原文地址：
1. 最簡單的發布流程
最簡單指的是開發完成好一個ng2應用后，做最少的事情讓用戶能在自己的瀏覽器內訪問到此應用。從這句話出發就很容易想到，如何做到“最簡單”，自然就是什么都不做，把寫好的整個項目往服務器一扔搞定。
當然，即使是對項目文件什么都不做，服務器還是得做一些事情來配合ng2開發的前后端完全分離的網站：
- a. 調整index.html中的<base />標簽的值，因為在服務器中的index.html不一定就在根目錄下，此時就必須指定其路徑。
- b. 調整404錯誤頁，將所有的404錯誤都重定向到index.html，只有這樣才能不讓服務器的路由影響到我們ng2的前端路由(深層原因其實就是，我們在瀏覽器輸入地址時，地址先被服務器認為是錯誤路徑給返回錯誤了，這就得讓服務器認為地址有誤時將其原封不動重定向給index.html，讓其成功被客戶端路由識別)
- c. 開啟生產模式，ng2默認的引導都會開始開發模式，在引導的代碼里執行 enableProdMode() 即可開啟生產模式
- d. 簡化node_modules。 原因是開發項目時安裝的那一大堆(20500+的文件以及180M+的大小)npm包，其實絕大多數在App運行於瀏覽器時是用不着的，發布項目時，去掉其中用不着的那一大堆文件，自然能節省很大的空間。
2. 產品級優化
接下來，為了優化我們得產品，還需要做一些事情。
-
AOT編譯
全稱是 Ahead-of-Time compilation。明確點講，就是默認情況下ng2使用的是即時編譯的方式，App運行過程中需要使用到哪個模塊了，就找到它然后編譯它，然后才運行，別的且不說，實時編譯相比預編譯要多使用一個Angular Compiler，聽起來就能想到這會拖慢速度，實際上拖慢了不是一點兩點，是一大半甚至更多，這貨體積賊大。 -
使用webpack(包括AOT)
webpack是用於代替默認的SystemJS的模塊化工具，可以說使用SystemJS進行ng2的打包只是在試水鬧着玩，如果要上升到產品級別，webpack要強大得多，包括了預編譯以及代碼壓縮，而不是像SystemJS那樣，每使用到新的模塊甚至組件模板都要發起請求來獲取。 -
使用rollup消除無用代碼
這指的是搖樹優化，完成的事情是自動去除掉不再使用的代碼，來減小體積，不過需要我們具體去完成的事情好像沒有，這個ng2自己幫我們完成了。 -
修剪庫依賴
說的好像是可以進一步修剪使用到的庫，舉了個例子是RxJS，這個庫在開發ng2時會使用到其中的部分功能，比如說Observable，但更多時候也只有這一個模塊被用到了，所以可以只引入一個Observable。這其實是ng2自身還存在的一點點美中不足，至少筆者就感覺很怪，為什么用着@angular/xxx的包，還得引入個rxjs或者Observable，期待ng2后續的版本會給出更優雅的方式吧。 -
性能測試優先
講的就是通過性能測試手段來優化產品了
3. 原文后面還分ng2端與服務端重新理了一遍上面講到的
-
ng2端要做的事情有：
a. <base>標簽的路徑配置
b. 開啟ng2的生產模式
c. 使用模塊懶加載(路由中使用loadChildren)
原文還寫了一小段來說不需要把懶加載模塊import進立即加載的模塊中(比如把一個懶加載模塊import在了根模塊里)，這其實不會懶加載，模塊還是跟隨根模塊一起被加載了。 -
服務端要做的事情有：
a. 錯誤頁都要重定向到index.html(防止丟失前端路由)
b. 跨域配置(前后端分離的應用通常要解決的問題)
4. 自己的補充
最后是自己對ng2這樣的強大前端框架下的前后端分離應用的一點拙見。主要是針對於其前后端分離的情景，這就導致客戶端變得不可信，使得認證變得困難。
起初筆者的想法是就將前端網站當成是原生的App來看待，原生App不也是跟服務器分離的嗎，那原生應用如何做到認證的，ng2的客戶端也能做到不是嗎。
不過最近又有一點想通，客戶端的認證，終究要依賴於一對AppId與AppSecret或是類似的東西，這種數據在原生應用里得到保護的能力終究是大於Web應用的，畢竟在web客戶端來保存的話存在哪呢，所有的資源腳本，終究是透明的，那web應用何必非要向原生應用靠攏，即使是基於ng2的網站，不要覺得浪費，套個.Net MVC的殼來保護認證參數，並不是什么得不償失的事情，籠統的來講就是，不同的平台要發揮自己平台的優勢，不是非要為了做全平台而寫完全通用的代碼的。