在实际问题中遇到在使用了iframe的情况下对前端路由的影响。应用的角度讲，这种方式不常用也不大会影响生活，不过浏览器如何处理这个情况确实是一个有意思的问题。遂做如下小实验：
┌─────────────────────────────────────────────────┐
│ Main window │
╞═════════════════════════════════════════════════╡
│ Keep changing iframe.src and print history │
│ +----------------------+ │
│ | | │
│ | | │
│ | iFrame | │
│ | (Print history) | │
│ | | │
│ | | │
│ +----------------------+ │
└─────────────────────────────────────────────────┘由于安全策略的原因，history的内容并不能直接被访问，只有一个length属性可以看看stack的大小。所以这里所谓的print也只是打印下length和自己手动记录的src值而已，除了响应操作之外并没有太多意义。
history实例是不同的，实例下对应的model是相同的(joint session history)划重点:
history是所有fully active的Document对象的所有browsing context的所有session history的合集。
简单说就是同一个session, 同一个history，甚至不同域也逃不掉(虽然依然收同源策略制约)。
history.length看看就好没啥意义，不同浏览器初始值都不同，变化也各种没谱，还有个最大值50iframe.src的变化会反映到history中，同浏览器地址栏document的路由基本不用考虑了，事件侦听和同步的成本比较大。