给你个建议：打开抓包工具，先抓一遍浏览器发出去的登录包，然后再抓一遍你自己程序发出去的登录包，接着拿这两个包进行对比，有差异的地方就是你需要注意的地方了。两个静态参数一样、动态参数生成方式一样的请求，是不可能得到不一样的结果的。

@cassyfar #122 直白跟抬杠是两回事，不要混为一谈谢谢。前面有很多直白的评论，人家没有忽略掉文章中所说的应用场景，而你是完全忽略。

他文章中没说“只是给爬虫做的”，但他是“面向爬虫场景做的”，能理解这个区别吗？原话写得很清楚：
“在爬虫场景中，这条数据在进入数据库之前会进行数据清洗、校验、矫正、分析等多个流程，这期间有一定概率发生重试或设为异常等操作，也就是说在进入数据库之前它就需要有一个 ID 来标识它。”

标题我说了，他确实标题党了，这当然有问题，但是这跟一个东西有没有价值毫无关系。看标题噱头比较大就觉得内容没价值的话，那你怕是会失去很多有一定价值的东西，毕竟标题起不好的文章连火都没机会火。

“只做到单主机 service”？文章最后那句“至于怎么选择，可根据实际业务场景和需求与架构进行讨论，选择一个适合的方案进行部署即可”你是没看到还是咋的？而且前面举例的美团和腾讯哪个不是按实际应用场景去部署的？不考虑实际应用场景强行套个自己的应用场景抬杠还有理了？

至于“迷信美团腾讯”就更搞笑了，你说只能这东西只能单机服务，我告诉你美团腾讯也这么搞，有问题？你自己也看到了人家美团知道可能会出问题，但人家还是这么用了，说明什么？嗯？

任何东西都不可能适用于所有应用场景，就像 Snowflake 在分布式使用的情况下做不到严格递增一样，你拿 Snowflake 往文章中所说的场景上套，一样会得到“毫无意义”这个结论，毕竟连个严格递增都做不到呢 hh 。

有点意思，可以把好久以前攒的地图都理一下了（虽然也不打开玩）

#3 +1，都在讨论的时候基本就是快出事情了，差不多就撤。

写个机器人一直获取评论和弹幕，然后自动删除不正常（ AI 判断）的内容？比较治根。

首先内容得对别人有价值，有了价值别人就会自发地帮你推广，像 opengps 老哥做的那个网站就很独特又有价值，我都看到好几次给他加友链、发朋友圈推荐的情况了。

当然你自己说的那几个方法也同样需要进行。文章写了没什么人看可以往各种群里、论坛里发一发，自然就有人跟你讨论了。

千万别学楼里一些（注意是一些）见个相关帖子就发自己博客链接的人这么玩，又令人厌恶又带不来多少流量。搞来搞去最后就变成抱团取暖，每天互点别人博客啥的都会搞出来…没有实际意义。

@byte10 #114 ObjectID 按文档里的说法分新旧两种版本，但两种版本都不适合：
1 、时间戳+机器 ID+进程 PID+随机数
做不到严格递增，只能靠时间戳做到趋势递增，完全不适合。
2 、时间戳+随机数+自增序号
和他现在这个很像，但随机数在高位，做不到严格递增。而且自增序号只有 3bit 可用空间，比 snowflake 的 12bit 还小，也不适合。

虽然他并不知道 ObjectID 实际也可以转化为类似的形式，但就实际需求来讲，ObjectID 仍然是不适合的选择。

@byte10 #114 对于他的需求而言，确实不行…入库才能生成这个倒确实是明显没有了解到位。

@D3EP #116 这种东西还是结合实际应用场景看。前面不是也说了吗？
首先他是在爬虫的数据处理链路上用，这种场景没有千万 QPS 的需求；

然后 Snowflake 多机使用性能肯定够他用，但是 Snowflake 多机生成 ID 的话又会有机器 ID 的问题，
做不到严格递增，他想要排除掉这个问题；

而如果单机部署成这种发号器的话，Snowflake 获取时间戳和末位序号范围过低的设计又可能会导致单机生成 ID 的性能满足不了他的需求；

结合这种需求想到用递增序号搞不是很正常？

然后他又会有数据对外展示的情况，考虑到这种情况加个随机数操作一下，让大部分人看不出 ID 怎么来的，也让别人的爬虫没法直接按着递增的 ID 爬自己的数据，这东西不就这么出来了？

至于实际部署时的可用性问题，微信那个不是就给出了个很合适的做法吗？直接做个主备不就完事了？反正单机性能已经完全足够使用了，又哪来的需求会需要将这个发号器也分布式化？爬虫有 IP 就行，跨机房大可不必。

还是那句话，不要忽略别人说的实际应用场景强行套上自己的需求…

@quericy #102 其实就他所说的「在爬虫的数据处理链路上用」这种应用场景而言，异地多机房部署出现的情况概率极低，使用时基本都是单机房下的分布式，瓶颈问题其实没那么严重；而且没有了多机房之后可用性问题也没那么严重了，所以问题也不大。不过对于后端的大部分服务而言，薄雾这东西可能确实没多大的必要使用，毕竟应用场景差异太大。

@cassyfar #111 你说的话确实像为了喷而喷，并且你明显没有好好看别人说的话。给你列一下主要问题：

1 、你上来第一句就在阴阳怪气地嘲讽，但后面指出的问题确实又并不符合人家所说的实际应用场景，而是以你自己以前的公司的那种场景作为基础在质疑百万、千万 QPS 怎么办。
这能怎么办？应用场景都不一样啊，人家文章开头就说了是在爬虫的数据处理链路上用，得多大量级的数据才会碰到百万、千万 QPS 还必须硬扛过去的情况？我之前（ 19 年左右）在一份报告上看到 360 搜索的爬虫每天爬的页面是 10 亿，均摊下来也就万级 QPS 就够用了。在这种应用场景下说百万、千万 QPS，是要上天？

2 、人家好好给你举例，问你「你认为怎么做才合适」、「你会怎么设计」的时候你啥都不说；人家文中和回复中都说了的“用了预存预取”你又完全不看，然后你就又开始对数据库操作部分开喷？
依赖数据库持久化、ID 递增的 ID 生成系统又不是只有他这一个，文章前面提到的美团和腾讯的做法中同样是有数据库 /硬盘 IO 操作和号段预存预取+缓存的机制，你要不顺便把他们也喷一喷？反正在你看来应用场景这种东西是不存在的，只要有数据库依赖就是“垃圾”呢。

3 、这是个人项目，不是团队项目，代码仓库都是放在个人名下的，文中的描述也是“我”而不是“我们”，他也从来没说过这是团队项目，哪来的“一群”、“你们团队”？

他标题党当然有问题，主流应用场景有差异的情况下不应拿性能做对比，毕竟没有多大意义，这点不可否认。但你所谓的“心气很高”、“反驳不了就扣帽子”的情况显然是不存在的，这说法放到你身上我觉得倒是挺合适...好好地就事论事不行，非要人身攻击；喷的点有问题还自我感觉良好，人家好好回了又不看，实在🐂🍺。

@TypeError #66 没懂，Google lens 在这起到什么作用？

@SilentDepth #94 机器 ID 比末位那个上限是 4096 的序号要高，排序时「机器 ID 更大」的值不就比「机器 ID 小」的值要更大了吗？虽然时间尺度上递增但是满足不了他想要的效果啊。
而且 Snowflake 之所以需要机器 ID 来保证多机同一时间发的同一批号不重复，不就是因为没法统一吗？现在他用一个独立的服务来控制，不就不需要机器 ID 也能保证不重复了吗？

@NightTeam #75 严格来说 MD5 没有破解、只有爆破，俗称彩虹表，也就是所谓的枚举所有可能性并生成映射表。而应对这种问题其实很简单，加盐就是典型的解决办法，比如 @shansing #92 所说的方法就是类似的操作。

@RemRain #68 md5(id)的做法可以是可以，但只能对外展示时使用，内部排序啥的没法用。而他的这个应用场景是想内外都用同一套 ID，所以并不能用 md5 来代替。

诶不对，要配置 host ？意思是要自定义 dns 吗？试试就普通路由模式，然后把 wan 口设置从 ppope 改成动态 ip 看看行不行。

没用过 Mac 的有线网络共享，不清楚具体是个什么操作，如果跟无线网络共享一样的话，理论上来讲你网线接到 lan 口把路由器作为交换机用应该不会有啥问题。

用 xposed ？直接 hook 一下，让微信的扫码模块认为是从摄像头取到的图像就好了。

问题不大，调整好心态再考一次就好了。不熟悉场地和车辆应该可以让教练带着去考场练习？深圳是可以这么操作的。
我考科目二也挂过一次，本来那时候是可以一次过的，结果碰到个半坡起步上到顶部熄火的人…直接给堵在那堵死了，浪费一次机会；第二次机会又因为上半坡的时候刹车松太快给电脑判挂了，心态都给搞崩。
然后第二次考没碰到奇葩，心态很好，就直接纯凭感觉一次过。我记得当时半坡下到 S 弯再到直角转弯那里我都是没刹车直接冲过去的，啥事都没有😂。就还是心态问题。

@xupefei #9 不会，正常情况下跟在内网环境使用差不多的，没有明显差异。