最近一个SPA的玩具项目中在用react-router，有个问题一直在困扰我。我按照官方的文档，使用browserHistory，然后生成的客户端路由都是不带#的。这样在一个子级路由中刷新页面，就是请求这个子级路由，我后端就得能识别这个子级路由。。这就有些蛋疼，和我以前用过的#/XXX这样的客户端路由有些不同。
不应该啊，作者不可能没考虑到这个问题啊，肯定是我哪里用的不对。于是乎，我又去看了下文档。
找到这篇文档 Histories，终于算是解决了我的疑惑。
react-router提供了三种方式来实现路由，并没有默认的路由，需要在声明路由的时候，显式指定所使用的路由。
//v1.x
<Router/>
//v2.0.0
// hash history
import { hashHistory } from 'react-router'
<Router history={hashHistory} />
- browserHistory
- hashHistory
- createMemoryHistory
官方推荐的是browserHistory，它是使用浏览器内置的 History API 实现的。同时，后端也需要特殊配置，来处理这些可能发送到后端的路由，不光是因为用户可能手动刷新页面，还有另外一个更重要的原因。在不支持 History 特性的旧式浏览器中，react-router就会直接重新加载页面（显然后端必须识别这些路由）。
文档中有一句也提到了为什么推荐使用browser history，而不是hash history。要知道，react router以前是默认使用hash history的。
You might wonder why we don't fall back to hash history; the problem is that URLs become non-deterministic. If a visitor on hash history shares a URL with a visitor on browser history, and then they share that back, we end up with a terrible cartesian product of infinite potential URLs.
意思就是怕 hash history 和 browser history 的混用在分享url时引起混乱。
我有点不太明白，一个app应该只会采用一种方式，不会混用啊。
先留个坑，待我再查查。
在stackoverflow上提了个问题，总算解决了疑惑。
文档中的意思是在运行时切换 browser history 和 hash history，而不是我之前理解的只有一种方式实现。那在分享url的时候，自然是会引起混乱的。
