爬慢一点！爬虫其实是个寄生虫，宿主死了，寄生虫就死了！

互联网上无效的垃圾信息太多了，就不要在制造垃圾了！

一次性加密。。俗称随机数！

这就和有些男人在啪啪啪的时候拍视频一个道理，口口声声说我不会发出去的，我不会给别人看的！结果姑娘就信了，然后就有了 91

记得当年第一次闯祸，把公司的生产库给 drop 了，也是多开 ssh 给闹的。所以现在都是只开一个 ssh，坚决不多开。

总结！ v 站的用户不是互联网小白，大家都是老司机了。不要用忽悠小白的手段来忽悠我们！

@SlipStupig 你这一整套组合拳太狠了。。

@federic 呀~~我也是 python 后端的坑！

设置个蜜罐页面吧，列表页面里面增加一个隐藏连接，链接的格式和正常的一样，但是在 css 中做限制不显示出来。
如果有 ip 访问蜜罐页面，直接小黑屋伺候。
正常用户是不会去访问蜜罐页面的，误伤率会比较低。

我活生生一个后端工程师，被这个帖子忽悠的觉得应该去学 iOS 开发~~~

不要用 rm -rf / 这个命令就可以了！

@beneo 亚马逊的处理方法，大概是这样的。
1：后端把 API 拆分
2：通过 API 网关对 API 进行聚合形成一个新的 API 来返回多个 API 的聚合信息
3：对外只发布 API 网关聚合后的 API

@beneo 关键词被淹没了~~

@beneo 我找一下那篇文章。

从后端的角度来说，一个 API 的请求返回值如果过大的话，拆分成几个 API 是合理、正确、明智的。
API 的返回体过大几个弊端：
1：最直观的感受就是页面加载速度会下降，前端必须要等待所有的数据都返回以后才能显示。
2：如果并发量大的话，很容易造成业务的堵塞。
3：维护不方便
所以拆分出来是很合理的解决方案。

但是从前端的角度看
1：一个 API 拆分成多个 API 以后，打开一个页面需要发送多次请求，增加前端的工作量这是肯定的。
2：网络延时也是会增加，前端说对用户体验不好也是确实的。
3：乱七八糟的 API 多了以后，前端也头疼。

所以之前 amazon 有一篇专门的分享文章来说明他们是怎么来处理这些问题的，具体的你可以搜索一下。
LZ 也可以去了解一下 API 网关，这应该可以解决 LZ 的问题。

key word: API Gateway