本文是按着ng2官网的高级内容“Deployment”的思路整理得出的，原文虽然在angular2的中文站下挂着，截止目前却还是英文版未翻译，笔者就在这里结合自己的理解给出原文的一点点整理。
这是原文地址：

• https://angular.cn/docs/ts/latest/guide/deployment.html

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的壳来保护认证参数，并不是什么得不偿失的事情，笼统的来讲就是，不同的平台要发挥自己平台的优势，不是非要为了做全平台而写完全通用的代码的。