你确实发现了一个 bug 。。

查了一些资料，$20 付费之后就是真的永久，不会受到 3 月回收的限制。旧版本的页面已经下线，现在的 workflow 不再有办法将号码买成永久了，不过反之，更换号码现在是免费的了。

“不告知甲方”是说公司不告知甲方吗？那他离职后自己告诉甲方说公司给甲方的项目埋雷会发生什么？

当然是都要啊，各有各的优势。
卧室投影睡前看，客厅投影晚上看，游戏室再放一个 75 寸打游戏，几个 11~13 寸的平板吃饭蹲坑看。
租房的话如果对“大”需求，还是建议投影，毕竟拉窗帘比搬电视简单多了。

@zzyyqq 可能他们的暗示 996 太不明显了，我一直没发现🤣

一个公司那么大，无论多晚走办公室总会是有人在加班的，但是这等同与整栋楼都加班吗？

你确定显示出来的是 PDF 吗？

我觉得与其担心 VPS 的流量，不如担心你本地到 VPS 的流量。

@tool2d 哪跟哪啊，楼主写的哈希根本就不对，和完美哈希就没关系。

@3dwelcome 那你写啊，写完再测一遍性能，我赌比微软的 hashmap 慢。

@3dwelcome > 肯定包含数组反查了，这点不会取巧的。
不，你没有。你绝对写不出一个 find(string) 函数。

@3dwelcome 你可以有额外数据，但不能以 id 为 key 。
否则我只要一个改动，能把你现在的性能翻倍。
查找：findid = id.

@3dwelcome 你都有 lookup table 了，还要你这个 hashmap 干嘛？用户输入不带 seed ，key => seed 的过程不就是一个查找的过程，怎么你还要用另一个“完美无冲突”hashmap 解决吗？
这就好像你发明一个永动机，需要一个电扇吹一样。

@3dwelcome 你怎么把 keyseed mix 到原 key 里？ 你查询的时候谁帮你 mix ？比如说一个字典，文章还不能直接写英文单词了？还得 mix 你的 keyseed ？
既然你可以 mix keyseed ，你干嘛不直接 mix dataset 呢？

你查找的时候都知道 keyseed[id] ，结果的 id 都已经知道了还查询什么劲啊，直接 dataset[id] 岂不更快。

@3dwelcome 你有这个工夫，代码发出来不就完了

@3dwelcome minimal perfect hashing 和 perfect hashing 又是一个不同的问题。。
而且 perfect hashing 是加了限制条件的，和工程中用的 hashmap 又不是一样的问题。

即使针对 perfect hash 问题，你在主楼里也没说清楚问题描述。然后你的算法也不新，很多人随随便便都能想到。再者你也没有对算法进行抽象，不简练，你自己都没搞清楚这个算法的关键在哪。最后你不会用正确的工具描述分析这个算法，你没能拿出 code ，也无法分析时空复杂度。

我是没看出来这帖的目的是什么，被教育吗？