Angular 去掉url中的#号，并解决页面刷新404问题
1. 为什么要去除？
Angular官方指出：如果没有足够使用hash风格（#）的理由，还是尽量使用HTML5模式的路由风格；
如果配置了hash风格，在微信支付或是Angular的深路径依然会出404的问题；
当你需要使用GA等工具时，由于无法获取#号后的URL，导致每次路由切换都给其发送一个路径；
'#'有点丑。
2. 怎样才能去除？
有四个方法：
- 前端 + ngx
- 前端 + Apache
- 前端 + Tomcat
- GithubPages + 404 页面
2.1 前端
index.html的head里加
app.module.ts
import { ROUTER_CONFIG } from './app.routes.ts';
@NgModule({
imports: [
...
RouterModule.forRoot(ROUTER_CONFIG)
// RouterModule.forRoot(ROUTER_CONFIG, { useHash: true } ) 这样写是带#的
],
})
app.routes.ts：
import { NgModule } from '@angular/core';
import { Routes } from '@angular/router';
export const ROUTER_CONFIG: Routes = [
{
...
}
];
如果只配置前端会怎么样？
如果只配置前端虽然会去掉'#'但是一刷新页面就404，路径解析上出错了。
Angular是单页应用，它实现了前端路由功能，后台可以不再控制路由的跳转，将原本属于后端的业务逻辑全部丢给前端。
用户刷新页面时(http://gitee.poetry/life)，请求是先被提交到了WebServer后台，后台路由没有对应页面的路由管理，就会出现404的错误。
用户如果是先访问首页(http://gitee.poetry)，然后再跳转到 页面(http://gitee.poetry/life)，则这个跳转是由Angular前台管理的URL，访问是正常的。
那么我们让WebServer把属于Angular管理的路由URL，都转发到index.html就可以解决404的问题了，也就是后面介绍的配置信息。
思考：hash模式为什么不会404？
2.2 ngx配置
带'***'的是需要自己配置 nginx.conf 文件内容
server {
listen 80; #监听的端口号
server_name my_server_name; # 服务器名称 ***
root /projects/angular/myproject/dist; #相对于nginx的位置 ***
index index.html; #如果index.html存在，就结束查找过程，把这个文件附加到请求的request_uri后面，并且发起一个内部的redirect。
location / { # / 是匹配所有的uri后执行下面操作
try_files $uri $uri/ /index.html; #try_files先寻找名为 $uri 文件，没有则寻找 $uri/ 文件，再没有就寻找/index.html
}
}
try_files 详细解释：
如请求的是https://deepthan.gitee.io/poetry/life, $uri则是‘/life’,如果‘$uri’‘$uri/’都找不到，就会 fall back 到 try_files 的最后一个选项 /index.html发起一个内部 “子请求”，也就是相当于 nginx 发起一个 HTTP 请求到https://deepthan.gitee.io/poetry/index.html。这个请求会被 location ~ .php$ { ... } catch 住，也就是进入 FastCGI 的处理程序。而具体的 URI 及参数是在 REQUEST_URI 中传递给 FastCGI 和 WordPress 程序的，因此不受 URI 变化的影响。
2.3 Apache
Apache的根目录新建一个.htaccess文件
RewriteEngine On
# 如果请求的是现有资源，则按原样执行
RewriteCond %{DOCUMENT_ROOT}%{REQUEST_URI} -f [OR]
RewriteCond %{DOCUMENT_ROOT}%{REQUEST_URI} -d
RewriteRule ^ - [L]
# 如果请求的资源不存在，则使用index.html
RewriteRule ^ /index.html
2.4 Tomcat配置
Tomcat/conf/web.xml文件上添加
404
/
2.5 GithubPages + 404 页面
对于github pages来说，我们没办法直接配置Github pages，但可以在commit时添加一个404页。简单的解决方案如下：
我们在项目的根目录新建404.html，把index.html中的内容完全复制到404.html中就可以了。这样做github pages仍然会在恰当的时候给出一个404响应，浏览器将会正确处理该页，并正常加载我们的应用。
关于这方面的hack： S(GH)PA: The Single-Page App Hack for GitHub Pages
3. 带‘#’和不带‘#’原理上有什么区别呢？
3.1 这个得先说下什么是前端路由：
以前路由都是后台做的，通过用户请求的url导航到具体的html页面，现在我们在前端可以利用 Angular、vue、react等通过配置文件，达到前端控制路由跳转的功能。
前端路由的实现方法：
通过hash实现
当url的hash发生改变时，触发hashchange注册的回调（低版本没有hashchange事件，通过轮回检测url实现），回调中去进行不同的操作，进行不同的内容展示。
使用hash来实现的话，URI规则中要带上#，路由中#后边的内容就是hash，我们常说的锚点严格来说应该是页面中的a[name]等元素。HTML5的history api操作浏览器的session history实现
基于history实现的路由中不带#，就是原始的路由
3.2 Angular中的路由策略
angular2提供的路由策略也是基于上面两个原理实现的，可以在@NgModule中通过providers配置或RouterModule.forRoot()配置：
1） 路由中有#
@NgModule({
imports:[RouterModule.forRoot(routes,{useHash:true})]
})
或
@NgModule({
imports:[RouterModule.forRoot(routes)],
providers:[
{provide: LocationStrategy, useClass: HashLocationStrategy}
]
})
HashLocationStragegy
适用于基于锚点标记的路径，比如/#/**，后端只需要配置一个根路由即可。
2） html5路由（无#）
改用 PathLocationStrategy（angular2的默认策略，也就是HTML5路由），使用这个路由的常规路径不带#，这种策略需要后台配置支持，因为我们的应用是单页面应用，如果后台没有正确的配置，当用户在浏览器从一个路由跳往另外一个路由或者刷新时就会返回404，需要在服务端里面覆盖所有的路由情况（后端可以通过nginx或者apache等配置）。
@NgModule({
imports:[RouterModule.forRoot(routes)],
providers:[
{provide: LocationStrategy, useClass: PathLocationStrategy}
// 这一行是可选的，因为默认的LocationStrategy是PathLocationStrategy
]
})
更改index.html中的base href属性，Angular将通过这个属性来处理路由跳转
在后端的服务器上，用下面的正则去匹配所有的页面请求导向index.html页面。
we must render the index.html file for any request coming with below pattern
index.html
My App
Loading...
hash方案：路径比较丑，但是兼容老的浏览器，如果应用需要兼容低版本浏览器推荐使用
纯h5方案：只支持高版本浏览器，不过ng2+目前只支持高版本浏览器...
3） 定制自己的路由策略LocationStragegy
https://angular.io/api/common/LocationStrategy
4） Angular路由复用策略
http://m.itboth.com/d/7nQFni/typescript-angular2-angular4
3.3 前端路由优缺点
优点：
1.从性能和用户体验的层面来比较的话，后端路由每次访问一个新页面的时候都要向服务器发送请求，然后服务器再响应请求，这个过程肯定会有延迟。而前端路由在访问一个新页面的时候仅仅是变换了一下路径而已，没有了网络延迟，对于用户体验来说会有相当大的提升。
2.在某些场合中，用ajax请求，可以让页面无刷新，页面变了但Url没有变化，用户就不能复制到想要的地址，用前端路由做单页面网页就很好的解决了这个问题缺点：
使用浏览器的前进，后退键的时候会重新发送请求，没有合理地利用缓存，
原文转自：https://juejin.im/post/5a39c10351882538d3101129