爱情是什么？你们体验过爱情吗？单方面的喜欢算爱情吗？爱情的本质，是反馈调节吗？

就是文章阅读时，单词标红之后鼠标移动上去不是会有单词释义吗。1.好像很多单词没有释义。2.由于单词释义的小方框出现在鼠标（单词）右下方，在最下面的单词释义就会被浏览器边框挡住看不到啦~

听说站长想让我帮忙推广社区？ 把它写在我博客的about页面好了。

\require{AMScd} \begin{CD} (X) @>{ch}>> H(X;\mathbb Q);\ VVV @VVV \ (Y) @>{ch}>> H(Y;\mathbb Q); end{CD} \begin{CD} A @>>> B @>{\text{very long label}}>> C \ @. @AAA @| \ D @= E @<<< F end{CD}

从最初部署开始就用了 Angular Universal 来做同构渲染，不过效果是渐进的。最初的时候，连服务器端语言切换都没有实现，就是说，无论你的 URL 是 /en 还是 /zh 打头的，渲染出来的 HTML 都是英文。目前我还不知道原因是啥，不过把语言从普通的 service 的成员，用 angular-redux 改造为 observable 之后，语言的问题暂时解决了。（其实还有部分页面有问题） 这种状态维持了很久，直到今天早上进行了第二阶段改造。这次把 API 调用也挪到服务器上了。其实本来就应该是在服务器上的，不过一直没有配 CORS，导致每次都调用失败。改造当中还有一个副产品，就是发现了跨域请求的 OPTIONS 会阻塞真正的请求，相当于延迟 * 2 了，延迟一大体验就十分糟糕，所以我把 API 代理到同一域名了。 第三阶段就是继续优化。首屏可以在服务器渲染全部内容之后，又有一个新的问题，就是闪烁问题。它的原因是，在服务器填充了内容，在本地页面初始化的时候，又重新去加载 API，这时候就进入了「加载中」的状态，加载完之后又会变回原来的样子，这就是「闪烁」。 理想中的思路很简单，要是能把服务器的状态延续到桌面端就好了。我的加载是订阅的路由变化，所以想像中如果路由状态能延续，就可以避免重新加载了。我在这里查到有个配置叫 RouterModule.forRoot(routes, {initialNavigation: 'enabled'})，可以把第一次加载的路径直接作为 app 的路径，而不是从 baseUrl 跳转过来的。可惜用了之后我的加载事件还是被触发了，原因正在研究中。 所以我又退而求其次，能不能转移一些别的状态，比如 apollo client 的缓存。Angular 专门有个叫 TransferState 的模块做这个，简单的可以参考这篇。利用 TransferState，我们可以把 apollo client 的缓存、redux 的 store 都序列化之后再在本地回复，理想情况下就不会闪烁了。但我做了之后还是闪。 这是为什么呢？因为我当时针对 apollo client 的 refetch 有时候不能正常工作的问题，自己造了一套缓存失效标记的系统——简而言之就是给每个请求加上一个叫 cacheKey 的参数，如果 cacheKey 不同，apollo client 自然就不缓存了。再用一个唯一的键去识别一个请求，如果它需要缓存失效，就把这个键标记为 true，每次请求的时候去找自己对应的键的值，看是不是失效了，失效了就重新生成一个随机的 cacheKey，没失效就用原来存起来的 cacheKey。而我这个缓存系统同样需要状态转移。等我转移好之后，确实就不闪烁了。 转移的时候还遇到一个问题。我的系统本来是 Map 而不是普通 object，结果遇到了Map 序列化的问题。折腾了半天 Map 的序列化搞不定（因为我是多层的，而且为了类型安全，用了 tagged union，导致有 Map 套 object 套 Map），最终还是暴力把 Map 迁移到 object 了（暴力在为了减少代码更改，在 Object.prototype 上定义一些类似 get, set 的方法……） 现在工作是正常了，但还有一个隐患——生成的 HTML 太大了。这些 store 都以 json 的形式保存在了 HTML 中，本来可能接近 100 KB 的页面，暴涨到 250 KB 左右。现在我正在寻求这个问题的解决方案。可能用 GraphQL 的时候要克制一点了，不要贪图方便，而加入无关的 field。

没有想像的那么简单。感觉可以从理论的角度分析一番……

用苹果的人（包括我）习惯滑动后退，但这样似乎无法触发 SPA 式的后退，页面还是被重新加载了一遍，真是太遗憾了…… 不知道有没有什么解决方法。

我在这里说到「这个 API 很卡」，现在我终于知道本质原因了，猜猜是因为啥？ 跨域 QAQ 我一开始以为是服务器质量的问题，后来查了发现确实质量下降了，本来有 CN2 的现在没了，延迟从 150ms 上升到 250ms。搬迁到另一个（目前还是）CN2 的机房之后，延迟又回到了 150ms，然而还是感觉很慢。 看着调试工具里一堆 http 请求的时候，我终于想明白了，因为跨域会先发一个 OPTIONS 请求，这个请求虽然不大，但会阻塞住第二次真正的请求……这么一来延迟其实是 300ms，难怪这么慢。 于是我把 api 代理到了同一个域名下，现在看来效果应该好多了。

在单服务器的情况下，我目前想到一种方案，就是不迁移 IP 而是直接购买一个新的，然后把数据迁移到新的，把旧的 IP 反代到新的 IP，这样避免了如果直接更改 IP 后，DNS 缓存有段时间会导致不能访问的问题（因为解析到旧的 IP 了，旧的 IP 已经没了。这种方案里旧的 IP 被反代到了新的，所以无论解析到新的还是旧的，都可以访问）。

经常听说，有通俗的介绍吗