@hsfzxjy
我想了下，发现父亲（ F ）这个关系，很难找到它的逆元素。下面是我的思考：

首先是明确，构成群的是关系，而不是人，比如(子-父)(子-父)=(孙-爷)，这里子不是特指某个人，而是泛指组成关系的某一方。按这个说法，「幺元为我」应该改成「幺元为自身」。

然后再考虑你定义的「父亲（ F ）」这个关系，它定义了关系的一方是另一方的父亲。但这里有个问题，F 的逆到底是什么，按照群的定义，F*(F^-1)应该得到 e ，即自身。如果说「儿子 = F^{-1}」，那么假设某个人代号为 p ，p*F*(F^-1)=p*e=p ，这里必须假设 p 是男的这个等式才成立，如果 p 是女的，p*F*(F^-1)=b ，b 男的，所以是 p 的哥哥或弟弟。

导致上面问题的原因是，「父亲（ F ）」这个关系，没有唯一的逆元素。

@hsfzxjy #15 “舅舅”这个元素怎么用“父”元素和“母”元素生成？😊

对应到数学理论，应该是群论。
举个例子，平面上的平移和旋转操作，形成了一个无限群。先平移后旋转，和先旋转后平移是不一样的。两次平移则可以交换。

规则一致，哈哈，这个一致是怎么个一致法儿？能在你的能力范围内，用代码简单实现这个规则，是吗？你的能力范围在哪儿呢？

天黑黑，是时候听一听 AI 孙燕姿的歌了

@Livid /go/qna

按 30%估算是 30 万，实际是 21 万。估算准确率还不错。

看了下，敏感词很可能是「政.府」。

@goodryb
问题在于，按照上面的分析，它这样加速爬，不管是单机加速爬，还是分布式加速爬，10 倍的加速，会给 v 站造成 10 倍压力，100 倍就是 100 倍压力。

这样走捷径，相当于是走了歪路了，把用户和站长都触犯了。推出新功能，完全可以循序渐进啊，比如 v 站有 90 万个历史帖子，但不必都爬完，就可以推出新功能。想挖掘历史帖子的话，可以逐步挖掘，比如先爬取 1/3 的历史帖子，这 1/3 的历史帖子(30 万条)，完全能够支撑新功能。后面再逐渐补充爬取剩下的 2/3 的帖子。

@shyrock 事件的经过大概是这样的：

v2ex plus 插件作者开发了一个关于 V2EX 的新功能 vDaily ，可以发布类似于 v 站帖子排行榜的功能，也有挖掘历史帖子展示出来的功能，所以它不光需要 v 站近期的帖子，还需要历史帖子的数据。

按照 plus 作者的说法，它向 sov2ex 作者借了一份爬取过的 v 站的存量帖子数据，但有些数据(点赞数、感谢数)不全。
https://www.v2ex.com/t/939486?p=2#r_13072169

所以，plus 作者决定自己爬取历史帖子数据。根据下面用户的反馈，这大概是在 2 个月前开始的：
https://www.v2ex.com/t/924796

问题在于，plus 作者完成这个爬取的过程，是借助 plus 插件用户：它用服务器下发给每个 plus 插件用户一些主题 id ，让这些用户在本地帮它完成主题的爬取，然后上传爬取到的主题内容到 plus 作者的服务器上。这就导致了刚才提到的那个帖子里，plus 插件的用户突然发现「最近查看过的主题」里面，出现了一些自己从来没有看过的主题。

plus 作者的这个决定，并没有征得 plus 插件用户的同意，没有显式给出这些用户自主选择的权利。

其实单 ip 爬取 v 站的数据，分布到 6 个月内，按照 90 万个帖子，180 天，每天大概 5000 个帖子，平均 20 秒请求一个帖子，对 v 站造成的压力应该不会增加多少。猜测 plus 作者可能是想快点爬完？

写自己的代码开心，这点没错，尤其是正在给公司写代码的时候，感觉最强烈。

@GalaxyVIP 就是自建的啊，看我#14 楼的回复。我也不知道为啥。Google 风控也不能让连着输入 20 多个验证码啊。我特意查了一下，digitalocean 的 vps 的 ip 应该是独享的，没有第二个人同时共用。

「让用户把附件中的 index.html 放到服务器上」，路子真野。。

可以看一下帮助节点。
@Livid /go/newbie