前言

古话有云，长的越丑，命运越不待见，这不，jb 又来了，熟悉的 jb，熟悉的味道；

本来不太想写这文章，主要觉得是鸡毛的问题，没必要记录，但是想想，鸡毛虽小，但也算是一个坑，先撸一遍，加深印象吧，顺便给大伙笑话笑话一下~

上集回顾

前几天发了一篇关于 seo 耗时的问题，其实那个问题，是在 8 月份发生的，只是前几天才搬到 testerhome 上；

经过了 3 个月，研发大大把原来是外包做的单进程版本重构成多进程版本，重构好的质量好多了，而且产品数据也越来越好，因此这个项目也给另外的同学维护了，维护期间也就加一些广告等增加转化的需求，期间一直风平浪静，直到上周。。。

根源

大家都知道，seo 主要是利用搜索引擎的规则来提高网站在有关搜索引擎的内的排名；

然而，排名上去了，留存却成问题，但作为一个纯资讯网站，没啥功能吸引用户留存的，既然如此，就提高转化吧，争取把进来的用户洗到公众号或其他产品处，因此产品就提出了增加广告位、运营位放二维码的需求；

立项、开发、测试、验收、上线，功能没问题，这个功能运用至今；

上周某一天，产品说，商务&运营要求，广告图片替换下，这多简单的，直接替换，验证，秒级上线，结果，上线后的第二天，产品就来了；

产品：今天看了下数据，感觉昨天上线的版本有点问题哦，你看，UV掉到底了，而且从昨天16点就开始掉，17点就开始后基本为0了；

然后产品就给了一个图，从图中明显能看出，的确有问题，而且问题非常的大；

这个图是事后整理的，浅色表示 22 号，深色表示 23 号，数据已打码，问题不大，能看出趋向；

从上图明显看出，22 号约 17 点后，UV 出现跳楼式直线入地的情况；

二话不说，赶紧把研发拉过来讨论，讨论后，研发一脸懵逼，表情就好像这样，哈？

然后过了几秒钟，研发就说，不应该啊，就换个运营图片而已，这个是之前的代码了，之前都没问题，现在肯定没问题的啦；

这时候从测试的角度来看，的确如研发兄弟说的，换个图片而已，不至于这样吧，但是冥冥之中总觉得哪里不对，就说，兄弟，现在数据确凿，我们都逃不掉，要不回头检查下，会不会提交了不该提交的东西？

一直扯皮是没意义的，研发就老实回去看代码，几分钟后，研发胆战心惊的来到我的怀里；

研发：emmmmm，我大致知道问题了，上周跟研发B联调的时候，不小心把一行测试代码push到分支上了，从提交记录看，就只有两次提交，一次是修改图片，一次就是这玩意了。。也许，可能，就是这个导致的。。吧。。

当时听完后，就是这样的；

然后就表面淡定的说，兄弟，稳住，先把这段代码干掉，一起再观察下吧；

然后就是重新发布上线，观察数据，就出现上图的趋势：
23 号 9 点多后，数据呈上涨趋势，数据终于恢复了，不然，jb 再多也不够。。

故事到这里就结束了，产品说数据回来就好，就算回不来也没关系，反正转化那么低，大佬们只关注转化率（这心态是要炸了）；

研发一脸内疚，此时肯定要安慰下研发兄弟；
兄弟，别放心上，下次注意点就好了（毕竟，背锅的不是你）

而测试，只能自己安慰自己，幸好没出大事，幸好没出大事，幸好没出大事。。。

隐患

这个事情，有 3 个隐患：

• 数据是上线后就马上掉，但是直到上线后第二天，产品才反馈，如果产品那天刚好休息没人看数据，后果就不可想象；（缺乏预警功能）
• 研发 push 代码随意；（push 规范）
• 测试不知情；（信息缺乏）

想解决这问题，在小公司挺难的，只能说，提高出错门槛，增加预防手段，套路也很简单；

• 增加预警功能，这个数据是某度提供的，某度也提供预警功能，注册下手机号码，自己设置下就好了，如果要自己弄，也不难，就写个爬虫，定时爬数据，对比上次数据，出现多少占比后就预警，预警到微信、钉钉、短信、邮件，任君选择（反正代码自己写）；
• push 随意，这个只能找研发大佬沟通了，毕竟公司没有强制 review 的流程，也没可能因为这个事加这个流程，只能给研发大佬反馈，让研发注意下，当然也可以提一下增加 review 流程这事，做不做看大佬；
• 测试不知情，那就想办法让测试知情，之前 jb 写过另外一篇文章，不重复，贴链接，因公司用的是 gitlab，利用 gitlab ci，获取最新分支，每次 push 后钉钉通知，效果如何，有没有作用，看具体的测试同学，有了这个工具，以后研发 push 相关，一清二楚；
• 把这问题列入核心用例及自动化检查，确保后续不会再因该问题影响产品数据；

（说明下，上面贴的文章没在 testerhome 发布，所以贴的是自己原稿写的地址，算系列文章，要对 git、gitlab ci、.gitlab-ci.yml 有点了解才行，之前写的文章，懒得重新发布了，太多了，懒，而且都是学习的文章，只想在这贴有点用的）

上面的是 jb 的看法及做法，不一定对，欢迎大家一起讨论学习，毕竟不同角度看的问题也不一样；

到这里，好像故事要完了；

是的，没错，你再看回标题，跟 Meta referrer 标签有毛线关系？标题党？

回到标题

是否有人跟 jb 一样，好奇那段导致问题的代码是什么吗？

问了下开发，其实就是在 head 加了这玩意：

看到后，第一反应，这不是用于做防盗链吗？
然后就想起了之前偷偷爬小姐姐，第二天却发现满满是防盗链的悲伤故事；

但是，为啥这玩意会导致那么大问题？问了下开发，开发也懵逼，直接说不太清楚；

既然如此，那就翻翻资料吧，尝试总结下；

什么是 referrer

其实，只要是学过 py，并用来爬过小姐姐的朋友，都会知道 referrer 的重要性，这是防爬的第一道门槛，没有是不行的，但可以伪造哦；

那 referrer 到底是干嘛的？

通俗的说法就是，是一个来源，比如，去 qq.com，然后点击网页上任一的链接，跳转过去，决定就看到referer:https://www.qq.com/这样的信息；

当然，专业的说法就是这样：
Referer是 HTTP 请求 header 的一部分，当浏览器（或者模拟浏览器行为）向 web 服务器发送请求的时候，头信息里有包含Referer。

所以，这玩意就是一个来源；

那有啥作用？

作用

1）防盗链
上面说到了，这玩意很大一部分作用就是防盗链？
什么？怎么做到防盗链的作用？

很简单，referrer 是代表一个来源，如果我只允许自己的网站访问自己的图片服务器，那我的域名是 jb.com，那图片服务器每次取 referrer 时判断下是否是 jb.com 的域名，如果是则继续访问，不是就拦截，这不就是防盗链的效果了？很简单吧？

想破解也炒鸡简单，hardcode head 就好了；

2）防止恶意请求
这个其实跟上面是一样的，也是判断下 referrer，避免有人恶意搞事；

3) 统计
没错就是用来统计；

参数

回到这行代码：

可以看到，referrer 可以设置 content 属性，nerve 代表什么意思？还有其他属性吗？

属性值	结果
never	删除 http head 中的 referrer
always	不改变 http header 中的 referer 的
origin	只发送 origin 部分
default	如果当前页面使用的是 https 协议，而正要加载资源使用的是普通的 http 协议，则将 http header 中额 referer 置为空

这里面，origin 想说下，搞过爬虫的同学都知道，request header 可能会同时存在这 3 个参数：host、referrer、origin，这 3 个玩意有什么区别？上面的只发送 origin 部分的原因是什么？

• host 描述请求将被发送的目的地，包括，且仅仅包括域名和端口号。 在任何类型请求中，request 都会包含此 header 信息。
• origin 用来说明请求从哪里发起的，包括，且仅仅包括协议和域名。 这个参数一般只存在于 CORS 跨域请求中，可以看到 response 有对应的 header：Access-Control-Allow-Origin。
• referrer 告知服务器请求的原始资源的 URI，其用于所有类型的请求，并且包括：协议 + 域名 + 查询参数。 因为原始的 URI 中的查询参数可能包含 ID 或密码等敏感信息，如果写入 referrer，则可能导致信息泄露。

所以有些网站考虑到安全性，会考虑用 origin，而不是 referrer；

关系

上面说了一大堆，还是没看到 referrer 为什么会导致 seo 的数据有影响啊；

其实，非也，已经讲到了，referrer 是代表来源，referrer never 是删除 head 的 referrer，没有 referrer，那怎么统计？

所以这也就是为什么，把这行代码删除了，数据就马上恢复了，一开始很担心数据恢复缓慢，以为某度爬虫那边会有缓存策略（之前踩过的坑，开发删除了 robots.txt，爬虫没这玩意，就不知道怎么遍历你的网站，所以发现没有就不访问了，而且会存在缓存，就算马上恢复，需要等待某度更新或缓存失效时才再来）

小插曲

有同学会疑问，为啥文中有referrer和referer，是打错了吗？

非也，referer的正确英语拼法是referrer。
由于早期 HTTP 规范的拼写错误，为了保持向后兼容就将错就错了。其它网络技术的规范企图修正此问题，使用正确拼法，所以目前拼法不统一。还有它第一个字母是大写。
(网上看到就 copy 了，留意下)

小结

其实这个事是很小的一件事，很多同学可能觉得没问题就完事了，但是站在质量角度，这里面有很多问题，责任是各端都有，只是测试处于项目下游，永远都是受害者；

阅读完后，会 referrer 会加深点了解，至少以后爬小姐姐要记得带上哦；

遇到问题不用慌，了解原因，制定方案，也许不能落地，但思考了，结果就是属于你的了；

再多说几句

后面会项目比较忙，更新的频率会稍微慢点，目前计划在 testerhome 发的，都是一些测试相关的经历跟心得吧，其他更专业的，很多同学在社区发了；

目前关于测试在写的文章有两篇：
软件测试经验与教训 - 读后感，这本书有点意思、浅谈自动化测试，不会讲框架怎么用，尽可能站在不同的维度看自动化跟聊自动化，也请大家期待下，同时也是给自己压力，但修行未够，也希望大家多多提出意见；

除了测试，jb 在写的文章有很多，小程序、git、产品、py、shell、RN 等具体简单教程，但考虑到广告嫌疑，这里不贴，感兴趣的自行查询；

最后，谢谢大家~