做产品或软件开发时，一个很坑但是偶尔能遇到的问题是：实现新功能时可能会引入新bug。如果测试例子不够或者复现条件苛刻，可能需要很久才发现出了问题，真是让人防不胜防。
就本站博客来说，目前已知出现过这些坑爹的事情，都是过去一两个月才被发现和解决：
- 用Goolge PageSpeed Insights分析网页加载速度，听从网站建议把 dashicon.min.css 文件移走。一个月后发现回到顶部图标异常，一番排查发现原来是css文件的锅，详情见 不要移除WordPress的dashicon.min.css文件；
- 为了测试Nginx的fastcgi缓存效果，就在location中加了指示缓存是否命中的header。后来无意间发现一些预设的header没有出现，又是一番看官方文档加排查才发现原因竟然是新增了header的缘故。详情见 小心Nginx的add_header指令；
- 本站主题改为BunnyPress后，不知道哪天脑子抽风在自定义中禁止jQuery。一个月后发现文章的评论功能不能用，文章下方的点赞按钮也不能正常工作。这个问题困扰了我一个多月也没找到原因，差点认为站被黑了。后来逐步对比前后台输出，才发现是jQuery没有引入导致，真是惊天大坑；
- 本站之前受到过CC攻击，因此研究了防CC措施，同时针对WordPress的弱点做了严格限制，详情参考 WordPress防CC攻击设置教程。在设置中，对搜索请求进行了重定向捕捉，当时不知道怎么想的，在捕捉的location中加上了
fastcgi_param REQUEST_URI /;一行。这个指令带来的后果是昨天发现搜索结果无法翻页，还以为是主题的问题。换其他主题发现问题依旧，意识到应该不是WordPress或者主题的bug。经过不断的排查，还特地去看WordPress文档进行hack修复，最终回想起防CC攻击设定的Nginx配置，原因才真相大白。这也是一个惊天巨坑，一般情况下不会碰到，也不会被注意到。
从上面例子可以看到，就是随手改一下东西，坑就已经埋下，而且还很难被发现。这些例子也让我更深刻意识到测试case和代码覆盖率在持续集成中的重要性。