所谓的前端路由，拥有这样一种能力：客户端浏览器可以不依赖服务端，根据不同的URL渲染不同的视图页面。
前端路由的存在合理性
在Ajax之剑还未亮出，前端仍处于襁褓之中的时候，路由的工作交给了后端。在进行页面切换的时候，浏览器发送不同的url请求；服务器接收到浏览器的请求时，通过解析不同的url去拼接需要的html或者模板，然后将结果返回给浏览器端进行渲染。
服务器端路由也是不落俗套的有利亦有弊。它的好处是安全性更高，更严格得控制页面的展现。这在某些场景中是很有用的，譬如下单支付流程，每一步只有在上一步成功执行之后才能抵达。这在服务器端可以为每一步流程添加验证机制，只有验证通过才返回正确的页面。那么前端路由不能实现每一步的验证？自然不是，姑且相信你的代码可以写的很严谨，保证正常情况下流程不会错，但是另一个不得不面对的事实是：前端是毫无安全性可言的。用户可以肆意修改代码来进入不同的流程，你可能会为此添加不少的处理逻辑。相较之下，当然是后端控制页面的进入权限更为安全和简便。
另一方面，后端路由无疑增加了服务器端的负荷，并且需要reload页面，用户体验其实不佳。
立即学习“前端免费学习笔记（深入）”；
这样，前端路由就有用武之地了。首先，它的出现无疑减轻了服务器端的压力。特别是对于一个比较复杂的应用来讲，或者更确切的说，对于拥有一个复杂路由系统的应用来说，服务器端需要为每一个不同的url执行一段处理逻辑在高并发的情况下实在有点不堪重负；其次，页面的切换可以不需要刷新整个页面了，没有网络延迟，没有闪烁刷新，提升了用户体验。
前端路由实现方式
既然目标实现，我们需要解决的问题有哪些？我们可以将问题拆的稍微细一点，先制定一个亿的小计划，实现之后再进行下一步：）
在页面不刷新的前提下实现
url变化捕捉到
url的变化，以便执行页面替换逻辑
如何实现更新url并且页面不刷新
正如前面所说，前端路由相较于后端路由的一个特点就是页面在不完全刷新的情况下进行视图的切换。页面url变了，但是并没有重新加载！看上去似乎有点不可思议，其实也没什么大不了。
试想将浏览器地址栏当做一个输入框，我们需要实现的就是改变输入框的value但是不触发请求页面的操作，这样就不会重新加载新页面。倘若输入框的值的变化和发送请求是一个原子操作，我们也就束手无策了。庆幸的是，只有当我们敲击了回车之后，请求才会被发送出去（这是显而易见的吧）。因此这就为我们修改地址栏的值而不触发页面请求刷新创造了条件。BOM是否有提供修改浏览器地址栏url而不触发请求操作的方法呢？
这里，存在两种满足需求的方式。一是利用url中的hash字段；二是使用HTML5提供的history API。
hash方式
了解http协议就会知道，url的组成部分有很多，譬如协议、主机名、资源路径、查询字段等等，其中包含一个称之为片段的部分，以#为标识。
例如： http://www.gmail.com/text/#123，123便是url中的hash部分。
打开控制台，输入 location.hash，你可以得到当前url的hash部分（如果当前url不存在hash则返回空字符串）。接下来，输入 location.hash = '123'，会发现浏览器地址栏的url变了，末尾增加了#123字段，并且，页面没有被重新刷新。很显然，这很符合我们的要求。
history API
HTML5引入了一个history对象，包含了一套访问浏览器历史的API，可以通过window.history访问到它。
这里我们看上了它的两个API方法：pushState 和 replaceState。
history.replaceState(dataObj, title, url);
history.pushState(dataObj, title, url);
若上所示，它们接收完全相同的参数，都是对浏览器的历史栈进行操作，将传递的url和相关数据压栈，并将浏览器地址栏的url替换成传入的url且不刷新页面（正中下怀！）。
By the way，不同的地方是pushState 将指定的url直接压入历史记录栈顶，而 replaceState 是将当前历史记录栈顶替换成传入的数据。
这两种方式都可以帮我们满足题设条件。采用哪一种方式除了主观喜好之外，还得依照客观事实：低版本的浏览器对于history API的兼容性不好，例如遇到了IE8，摆在眼前的道路似乎就别无选择了。
如何跟踪url变化
在浏览器端，跟踪表单属性的变化一般都采用事件监听机制，跟踪url的变化也不落俗套。
对于hash方式的前端路由，通常可以监听 hashchange 事件，在事件回调中处理相应的页面视图展示等逻辑。
此外，HTML5提供的 popstate 事件也会在url的hash发生改变时触发。也就是说如果可以忽略低版本浏览器，我们使用hash方式路由时也可以采用监听这个事件进行回调处理。
那么，如果是采用history API的形式呢？根据MDN的描述：
调用
history.pushState()或者history.replaceState()不会触发popstate事件。popstate事件只会在浏览器某些行为下触发, 比如点击后退按钮（或者在JavaScript中调用history.back()方法）。
这也就是说，我们在使用history API改变浏览器的url时，仍需要额外的步骤去触发 popstate 事件，例如调用 history.back() 会 history.forward() 等方法。
从兼容性上来讲，前面有提及hash的方式兼容性更好。然而，对于低版本的浏览器，例如IE6等等，不支持 hashchange 事件。这个时候我们只能通过 setInterval 设置心跳的方式去模拟 hashchange。
var oldHash = location.hash;var oldURL = location.href;
setInterval(function() { var newHash = location.hash; var newURL = location.href; if (newHash !== oldHash && typeof window.onhashchange === 'function') { // 执行onhashchange回调
window.onhashchange({ 'type': 'hashchange', 'oldURL': oldURL, 'newURL': newURL
});
oldHash = newHash;
oldURL = newURL;
}
}, 100);
一个简单实现
这里，给出一个很简单的实现：
router.js
function FrontRouter() { this.routes = {};
window.addEventListener('load', this.resolve.bind(this), false);
window.addEventListener('hashchange', this.resolve.bind(this), false);
}
FrontRouter.prototype.route = function(path, callback) { this.routes[path] = callback || function() {};
};
FrontRouter.prototype.resolve = function() { this.curHash = location.hash.slice(1) || '/'; typeof this.routes[this.curHash] === 'function' && this.routes[this.curHash]();
};
index.html
index.js
var router = new FrontRouter();
router.route('blue', function() {
document.body.style.backgroundColor = 'blue';
});
router.route('yellow', function() {
document.body.style.backgroundColor = 'yellow';
});
router.route('red', function() {
document.body.style.backgroundColor = 'red';
});
一点总结
应用场景
前端路由大部分的应用场景，就是我们现在熟知的单页应用SPA。
不存在纯前端路由
我们此前所描述的前端路由，建立在已经打开了一个初始页面基础之上，然后在这个页面之内进行页面替换。然而，我们如何进入这个初始页面？仅靠前端路由肯定是力所不及。我们至少要向后端发送一次http请求，接收所需要加载的页面不是吗？
所以，我们并不能抛弃后端路由部分。这也意味着，我们需要和后端确认各自的分工，哪些url归前端解析，哪些归后台解析。
