都这么想，问题在于这不是你能决定的，而是老板和人事决定的。

如果你会玩 switch 上的其他游戏的话，那可以买。直接无脑买日版、港版 switch 就行。
没有电视没关系，有显示器吗？无非就是屏幕小一点而已，不影响的。
如果连显示器都没有的话也没有关系，有笔记本电脑吗？笔记本电脑+采集卡一样可以玩，有那种二三十块的采集卡，刚好能达到 switch 的显示输出水平。

八爪鱼，下一个

@azh7138m #147 你这忽略前半句直接看后半句...？
“人家文章开头就说了是在爬虫的数据处理链路上用，得多大量级的数据才会碰到百万、千万 QPS 还必须硬扛过去的情况？”
应用场景不同没有可比性啊。

如果你不常用的话就随意，但是如果用这个作为主要的上网卡的话，建议还是留着。4G 不限量套餐在 5G 环境下可以达到被限制的带宽，但延迟方面是和 5G 套餐一样的。

@encro #144 一般是双 ID，一个 ID 是对方平台的数据原始 ID 、一个 ID 是用来去重的 Hash，去重依赖第二个，第一个主要用于筛选和清洗。
稍微加点东西就失效不就体现出这个 ID 的价值了吗？至少你能知道对方什么时候加了东西啊。

@encro #142 去重跟 ID 实际上关系并不大，只是说可以用 ID 做去重而已；动态规划链接时效也并不依赖 ID 实现。
而且你忽略了一点，ID 并不是一定只能有一个，即使是用 ID 做去重也是可以有多个 ID 存在的...另外使用 ID 做去重通常也不会用域名或 URL 做，而是直接对数据内容做一个 Hash，这样去重才能真正起到作用，被吐脏数据之类的也能明显地看出来。

@yeziqing #137 是啊，就是个单点的东西，如果要避免单点故障就只能舍弃掉 ID 的严格顺序性或者生成性能，没办法的。

@encro #138 另外，你所说的“通过 bloom filter 和站点域名来规划”跟文中所说的全局唯一 ID 连半毛钱关系都没有...不管是使用场景还是效果都完全不同。

@luren123 #136
@encro #138
不要硬杠，文章开头就提到了“在爬虫场景中，这条数据在进入数据库之前会进行数据清洗、校验、矫正、分析等多个流程，这期间有一定概率发生重试或设为异常等操作，也就是说在进入数据库之前它就需要有一个 ID 来标识它”，已经对场景进行了说明。这种东西也不存在仅限于爬虫场景可以使用而已，所以在一开始就限定场景其实是一种特别蠢的做法，你并不知道别人的其他场景会不会有类似需求可以用到。

对于一个需要监控、有着多个规范化操作且需要保证严格顺序性的流程来说，为了有个唯一的 ID 用来事后追溯，除了单点的发号器以外你没得选，没得选的核心点在于严格顺序性。如果你写爬虫没有遇到这种场景，那只能说明你的系统庞大程度、爬虫逻辑的复杂程度还没有到需要依靠工具帮你解决问题的情况。
另外，这个薄雾算法对序号的混淆特性主要体现在 ID 需要对外展示的情况下，如果不需要对外展示，那就单纯一个序号就完事了，并不影响使用。

---

举个比较极端、全面的例子：
某平台的反爬虫和风控非常恶心人，签名参数的加密算法每次都会变动、代码的混淆方式也每次都会变动，并且对方对 IP （ IP 质量、请求频率等）和设备（设备与 IP 的关联性、设备真实性、请求频率等）也有进行检测，整个流程是关联起来的，缺一不可。
这种情况下你写一个爬虫就需要有反混淆、提取加密算法、IP 分配、设备分配、IP 设备帐号三者绑定等多个模块，而这些模块都是部分通用的，你不会把他们全集成在一个爬虫程序里，而是分别提供服务。
那么问题来了，假设某一天你发现有某些数据发生了异常，你怎么查问题？没有全局唯一 ID 的情况下，即使有接入监控也很难查问题，查到吐都不一定能查出来是什么情况导致的；而在有全局唯一 ID 且所有模块都接入了监控的情况下，只需要查这一个 ID 就可以得到整个流程中的所有信息，排查起来会方便很多。

不要杠什么“这种情况不需要高性能的发号器”，你没有遇到不代表没有；
也不要杠什么“不会有这么多操作结合的情况”，很多模块是通用的，平台方有没有这么复杂并不影响爬虫方的复杂度；
更不要杠什么“人家都做了这么多限制你还爬，抓的就是你”，你并不知道人家是不在乎风险还是已经获得了授权，这跟你也没关系。

说白了，架构设计本身就是充满着妥协的，不结合实际场景来看没有任何意义。Snowflake 、MongoDB 的 ObjectID 这类的算法说白了也就是个时间戳、机器 ID 、序号、随机数之类的东西拼接起来而已，一样很简单粗暴，但这并不影响人家能在特定的场景下起到良好的效果。

如果是写爬虫，编程语言本身对你来说并不太重要，用到哪学到哪就好了，后面慢慢地自然就会理解含义。如果是有编程基础的话，那更加没必要特意学一下 Python，语法都大同小异。

@locoz #38 然后 roam 的引用相关功能都是支持搜索的，也就是说在写的时候可以：按下反斜杠 -> 选择引用方式 -> 直接搜索对应的内容 -> 选中后回车确定。非常方便。

@locoz #38 哦不对搞错了，直接((block_id))是包含进句子，{{[[embed]]: ((block_id))}}是单独一个引用块。

@ChristopherWu #32 Tiddlywiki 这种是文章级的粒度，基于文章级粒度的双向链接实质上跟你在写博客的时候加一个外链没有区别，只不过是多了个“被谁引用”的效果而已。

块级粒度和对应的卡片式笔记方式最好的地方在于：由于你在最开始记录的时候就是「一段话即为一个完整表述」，所以你可以在任意位置直接引用另一个主题下的某一段话，而不仅仅是一个链接到另一个主题的效果。

举个例子，上面是[[roam]]主题，下面这个是[[[[roam]]的优势]]主题：
roam 是一个很方便的工具，它的{{[[embed]]: ((上面的第二段话 block_id))}}而它的竟品{{[[embed]]: ((上面的第一段话 block_id))}}

直接重用之前整理好的描述，使你完全不需要重复描述，并且还能建立关联的关系。在写文章、写多个有关联性主题的概述之类的场景，这个效果可以说是杀手级的。
现在 roam 的竟品要么是没有按块级的粒度来搞，要么没有提供类似的块级操作功能，可以说是连抄都没有没抄到位...

roam 和其他笔记工具最大的特点和优势不在于双向链接，而在于把内容粒度细化到了块级（段落级），这直接就导致了玩法的不同和效果的差别。如果仅仅是标题双向链接的话，其实跟一般的 wiki 是没啥区别的…

@dyt5 #119 “企业文化”不一样，会导致同样的人做出来的东西也不一样。就像有些公司内部提个需求走流程都要走很久，有些公司集体确认一下没问题就直接加了。

@amusier #111 第四点 EMUI 现在是走官方渠道完全搞不了，万能的某宝也只能解决老机型，hhhh 已经不是麻烦能形容的了，几乎就没法搞。
@amusier #114 iOS 越狱后也能搞这些，就是越狱这操作不像 ROOT 、Xposed 之类的方便而已。

@dyt5 #107 功能上是各有千秋，像 EMUI 那个双指按压触发 OCR 的功能就很方便，但总体的用户体验上 MIUI 是碾压的...很多细节设计 EMUI 直接就没有，不是差一点或者好一点的那种区别了。
而且 MIUI 有个很关键的点，他们开发团队会做舆情监控、会快速解决用户提出的问题和建议，但 EMUI 的是直接过耳忘，甚至压根就不看。像前面我提的那个门禁卡录入应该允许用户直接记录卡 ID，本来也没当回事，结果过了一个多月突然发现可以直接记录卡 ID 了 https://i.v2ex.co/9kZ3y873.png

所以你要说 MIUI 小细节不到位，这一点是不存在的，小米是硬件方面细节不到位，比如边缝宽容易进灰之类的...

推送广告方面推荐使用「通知滤盒」，自定义过滤+折叠很舒服，然后也能用来留证据啥的 hhh