按 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

@yujinchn776
@MrGba2z
我是自己搭自己用的，每月 5 ，6 美元哪。

@joefuzhou198x
@hsir
登录了，之前管用，现在也不行。

@churchmice
chatgpt 可以破解验证码啊，无论多么复杂的。(待验证)

「目标是。。通用型数据记录与分析工具。。通用型就是不针对具体场景。。这是我想到的目标用户」

我看了下楼主的 App ，楼主你没有把 App 的特色表达出来啊：展示的图片里面，没有展示最关键的模版功能。也没有一个官方网站来说明「通用型」这个特色是怎么用的，尤其是是怎么用模版来实现通用的。

「隔靴搔痒」，大量“炫耀”的篇幅只是勾起了痒，喧宾夺主了。偶尔点缀当然可以挑逗味蕾，可你只贴出账单，却不贴出如何拿到这些账单的经验，缺少营养。

前面几楼的回复不就是鲜明的例证吗。

@maxxfire 说得对。
这 8 篇文章看下来，给我的印象是：
蜻蜓点水
浅尝辄止
隔靴搔痒
俘于空中
品咂无味
惹人上瘾

8 篇文章的重点在于贴账单，炫美车美景美食，勾起欲望。缺少实例。唯一的产品例子，就是那个安卓桌面程序。

第一篇介绍 Broken Screen 这款应用的实例，暧昧不清，总让人觉得这是你开发的。朦胧美好的味道，这也就是卖课的高端境界吧，哈哈。

@pkoukk #72 对，闲鱼应该没啥问题。我之前一直以为确认收款的操作是闲鱼发给支付宝的。流水号一致的要求也挺合理。

@Rache1
「如果这个交易号暴露给了卖家，那么卖家也可以作为发起人了」，我这里说的卖家作为发起人就是指主题里的那种诈骗手段：卖家诱骗买家确认收货。这也可以看作是卖家作为发起方吧。前提就是卖家有这个交易号。

我理解了你的意思是不是说，支付宝担保交易这种，从头到尾，也只有一个交易号，并且这个号同时被买家、闲鱼、卖家共享？担保交易相对于直接交易，多了一个中间状态，对于买家来说，是已付款待确认，而对于卖家来说则是已付款未收款。是这样吗？

如果是这样，交易号是统一且共享的，那么是不适合作为 API 的参数来用的，比如对于买家来说确认收货的 API 。支付宝完全可以针对每一个交易号，再产生一个对应的确认收货号，并且仅下发给闲鱼。然后闲鱼才可以使用这个收货号，在 App 中让买家发起确认收货的操作。由于这个确认收货号只会在交易过程中才使用，交易完毕可以废弃，所以不影响最终的交易结果和数据归档。就相当于是一个对应于某种操作权限的 token 。

@codehz 但是确认收货的发起人肯定是闲鱼。从业务上来说，也只有闲鱼 app 上才有确认收货的入口才合理。闲鱼暴露给用户的，只有一个“确认收货”的按钮，用户经由这个按钮“代理”才可以触发收货，进而启动支付宝的支付密码确认。
主题提到的骗钱手段，能成功的原因，一是卖家伪装成闲鱼，向支付宝发起了确认收货的操作，二是确认收货所必须的信息(支付宝交易号)被暴露给了卖家。