又不是屏幕，划痕有什么必要在意吗... 买保护套多花的钱，已经大于二手市场的差价了... 除非是极端强迫症，不然真的不是很懂

@vvxu27

5G 的研究论文一大把，读个一两篇你就没这么多问题了。

提醒一下楼主，10 代低压 U 在功耗充足的时候就是标压 U

可以看网上的评测，10 代 U 的 15W 功耗是一种性能 35W 功耗是另外一种性能，65W 又是一种性能。

所以笔记本散热在这个时候非常非常重要。

结论：无脑小新 pro13 系列，over。

图书馆自习是学生刚需，别信买台式机那帮人的话。
楼主既然不玩游戏，就买轻薄本吧。小新 pro13 系列选一款就是了。要省钱可以去闲鱼看看，有不少人首发价刚到手就出，封都没拆。选一款自己预算内的就行了。

@dusu 那 hll 就没有任何优势了。hll 本来就是用相对少量的定长内存统计大量的数据，但是当数据量很少时还不如 std::set 呢...
同时从信息论的角度来看，hll 平均每个元素不到 0.1 个 bit 时，必然无法完成集合的 exists 功能。作为对比，bloom filter 平均一个元素有几个 bit，已经基本压缩到极致了。

@dusu 一口老血喷到屏幕上...
第一，hll 可以基于高并发的原子操作，你刚好说反了
第二，hll 是概率算法，在后期 hll 自己的数据结构起主导后，对于每个桶，要么不更新，要么一次更新增加 N 个元素。打个比方，hll 就像一个精确到 100 的倍数的 distinct value 统计函数，你用它来统计某个数是否在集合中的话，错误率是 99%好吧。

用 decr 啊，先把商品数量仍进 redis

@dusu 什么鬼，hll 是用来计算 distinct value 的估计数量的，跟这需求不沾边。

bloom filter 平均一个元素占用几个 bit，不过确实是概率算法。
如果数据有范围，比如 N 个数据，出现在[0, 10N]区间里，其实 bitmap 就不错。
要保证精确的话，还是得 bloom filter 初筛，然后 kv 表查询。

楼主别想区块链了，共识机制要求大部分的用户永远在线，和你这个应用完全不搭。牺牲大量算力换来的安全可信共识对你这应用也没啥用。

最后，简化一下问题，把上下线改成机器可能随时静默崩溃，服务器改成固定的路由网络，你这个不就是要搞个分布式一致性协议吗。

不过大多数协议要保证正确性的话，对机器同时崩溃（或者说下线）数量是有限制的，你感兴趣的话可以去看一下

tokenizer 和 parser 是编译器的基本操作，这一块都要迁就机器只能说明太菜。
还拿 lisp 举例，当年是什么 CPU，多大内存？
低层次级别优化，都是先考虑 intrinsic，不行再上 llvm ir，手写汇编维护性是最差的，手动分配的寄存器也不见得比图染色算法搞得好。