老弟苦等了两个多月的新页面终于来啦！好耶！！！

新页面

新页面其实老弟从8月底就提出来要做了，关于之前的情况见动态。发了动态也并没有找到人帮忙，后面放下了这件事情一个星期，10月底我最后尝试了一次，断断续续用了一个周末，还是没有做出来。就在我绝望地找老弟谢罪的时候，老弟提出他的工作室新来帮忙的老哥可能有这方面的经验，看看能不能合作一下。新来的老哥叫@CarrotGeball ，就叫他萝卜兄吧。跟他聊了聊，很快就熟悉了，因为他说他之前有做游戏的相关经验，所以我觉得处理起来这些布局和动画的计算问题应该会很得心应手，就跟老弟说肯定没问题。前面几天他先用flash打了个样。现在的这个页面设计大概是他自己和老弟商量后确定的，和我之前的打算略有不同，不过我看到demo之后觉得这样确实更好。一周以后也就是这周二，他就把做好的整个页面布局和动画发给我了。我看了真的大受震撼，没有用任何框架和库，几百行CSS和JS全是自己写的（侧栏是字符串innerHTML插进去的），我自己（因为数学极差）一看到那些坐标计算脑袋就嗡嗡的，然后所有这些他是全部自己做出来的，还把我之前一直在发愁的图标做出来了，我真的十分佩服。拿到之后我开始整理代码，初步整理之后，发现侧栏的内容切换他用了一种明显比较别扭的方式去实现，导致后续的工作会比较困难，就先挂在GitHub上让他修改，一天之后他就修改好了。接下来因为侧栏是直接用字符串插进去的，几乎完全不可维护，因为侧栏要承载的内容很多，所以我觉得这个问题必须得先解决。一开始我打算重构到React/Preact这样的有虚拟DOM的框架，用了两个晚上，因为动画逻辑太（其实）复（只是我）杂（看不懂）以及我本来对React也不是很熟悉，所以进展很慢。到了昨天晚上老弟又来催，说最好周五也就是今天能上线，我看了下目前的进度，这么短的时间几乎不可能完成如此大规模的重构。就在这时我突然想到，以前了解过一种叫做template的元素能够解决这个问题（这个故事告诉我们，往往就是那些平时不知道从哪里了解到的奇怪知识能在关键时刻派上了大用场）。浏览器不会渲染template，然后JS可以复制出其中的元素然后添加到页面上，这就是template的用处。说干就干，我把所有的字符串形式的侧栏都改写成了template，然后再经过一波整理和重构，顺利地把侧栏的渲染迁移到了template。然后再用template来写侧栏的内容，就像直接写HTML一样（本来也是直接写HTML，属于是搁这搁这了），很快也完成了。就这样整个页面除了他还没来得及做的几个图标，就全部完成了，我一看时间都四点多了，完全没有感觉。今天早上起来之后看到他已经把几个图标做好了，我上传了图标，把nginx配置改好，经过了几次惊心动魄的线上事故（下面会说原因）之后，中午12点左右新页面成功上线了。目前还有几个小的bug，比如硬件讨论群那里的链接点不进去，再比如在iPad上试了一下图标可以上下滚动，以及他早上赶制的几个图标有点小问题，这些都已经在修了。

新页面的GitHub地址：https://github.com/stackinspector/ldtstore-homepage

nginx相关（配置文件版本0.4.3）

- 新页面的图片资源是放在一个仓库里然后用jsdelivr拉的，但是这样的话图片的路径就会很长，HTML没有办法定义常量，暂时没有好办法，所以只好增加了从/assert/*到jsdelivr CDN（https://cdn.jsdelivr.net/gh/stackinspector/ldtstore-assert/*）的重定向。之后可能会通过在nginx里替换来解决。

- 由于增加了图片资源重定向后客户端并发请求量激增（页面上有十几个图片资源，第一次访问每个都需要请求一次然后重定向到CDN），如果再保持原来的请求限制措施（全局限速10请求每客户端每秒）的话正常访问很容易就会突破限制（实测200r/s也不行，因为它不是“区间测速”而是“瞬时测速”），也是暂时没有好办法，所以只能先限制http上的流量而不限制https上的，因为根据日志分析，绝大多数的各类攻击请求都是打在http上的，而正常用户访问网站，除了第一次访问重定向到https以外，以后就都是https了（我开启了HSTS），之后再看这个问题怎么解决

- 由于独立出来后（原先页面的CSS和JS是通过我自己写的构建系统插入生成的HTML的，因为很短）的CSS和JS加载出现了异常，增加了显式声明UTF-8和之前一直遗漏掉的content-type

- 增加了bfs代理，为以后在页面上添加视频封面做准备