设置个蜜罐页面吧，列表页面里面增加一个隐藏连接，链接的格式和正常的一样，但是在 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

所有的请求都往一个 ip 发，正常的请求不会这么发的。被认为是机器人也是很正常的。

才失联 20 个小时，睡过头了，生病了，孩子发烧，家里的狗丢了，一份糊口的工作而已，很正常啊。。。
就不能联系联系其他人？

打坐！

@subpo 打错了，不是 3000 多个，一个插线板 3000 多 RMB ！

@subpo 机柜上的插线板都要 3000 多个呢。。。。。。。

@Quaintjade no,no,no 这绝对不是小钱。真的会搞出人命的！
记得 10 年还是 11 年，各种云还没有很流行的时候。公司里面也有自己建的机房，大概有 80 多台机器。然后在某一个夜黑风高的晚上，大楼防雷没做好，一个雷劈下来。大概差不多 50 多台机器直接瓦特。。。回复设备+数据前前后后花了半个月时间。。

重点是你老板的人品怎么样，要是老板人品不好。时不时给你硬盘坏一个，时不时给你电源坏了，万一外面施工把光缆给你挖坏了。万一大楼的避雷做的不好，雷雨天一个雷劈到那就更加刺激了！

淘宝，社保挂靠！

@anguslg 没有 judge ，只是发表自己的看法。