Bandizip X

@snnn 函数指针不能绑定局部产生的参数，这个很麻烦。还是 std::function 好使。

不过 @fyyz 像函数对象这种可能会有很大的上下文的对象，我觉得还是用 shared_ptr 更好，不然会产生对闭包的多次拷贝。如果闭包还有文件对象什么的，不是要跪了。

写好单元测试，用好连续集成，没了。

如果是一个买来看看视频收收邮件写写文件，嗜好是拍照所以照片一大堆的人选 8g + 512g 我一点都奇怪。

但是楼主你这个工作内容还选 8g，我只能说，你开心就好。

我觉得楼主和你的小伙伴最好注意一下“副作用”有关的各种约定。

面向对象设计中，为了让调用更安全，函数语义上最好隔离“读取”和“写入”。换句话说，叫做 get_xxx 的，语义上应该只返回状态而不更改状态，叫做 set_xxx 的则只更改状态而不返回状态（返回 self 例外，这是链式调用）。

缓存策略是另一回事。它应该对调用者透明。换句话说，你要是不高兴现在的缓存策略，可以随时更换，而不影响接口语义。所以你第一个版本是不对的，因为调用者需要明确知道 get_term 引起一次缓存，这个接口设计是不合理的。

永远不要让外部调用者接触类内部的缓存策略。

第一个版版直接枪毙。

第二个版本，_get_term 命名不合理。get_XXX 一般默认不引起副作用，哪怕是私有（保护）函数。

p.s. 为啥第二个版本不初始化 now_weeks = what_day = None，通过 is None 决定是否调用 _get_term，而要一个单独的 __get 标志位？

@murmur 说得好，操作系统不是问题，问题是你的预算多少。

如果你有预算，我会推荐 Macbook Pro。如果没有，一个简单方案是 Ubuntu Server 虚拟机，然后在 Whatever 你喜欢的操作系统里面写程序，在虚拟机里面调试。有些 IDE 比如 WebStorm 支持自动上传到 Linux 服务器，所以还是挺方便的。

别尝试虚拟机 macOS，最没有意义的事情之一。

@tianxiacangshen 我其实也是讽刺地加上那一句的。。。

@tianxiacangshen 系统会自动平衡的，你要担心不够用再加大总容量呗。

CN IP 这套我觉得太 overkill 了，规则太多不好。事实上你不需要这么大的路由表，只要把大公司和主要 CDN 的 IP 段加到路由表就 okay 了。我自己维护了一份，不到 2K 条规则，很稳。

怎么搞到规则集呢？给你一点参考。首先是 ASN 大法好：

facebook = AS32934
twitter = AS13414
wikipedia = AS14907
dropbox = AS19679
google = AS15169
automattic = AS2635 # WordPress, Gravatar, etc.
atlanssian = AS40034 # SourceTree, bitbucket
microsoft = AS8075
msedge = AS8068
tumblr = AS33612
yahoo_japan = AS4694
akamai = AS16625

你通过 whois -h whois.radb.net '!gAS32934' 这样的命令就可以通过 ASN 查 IP 段。

然后是 Google IP，通过这些命令查：

dig TXT +short _netblocks.google.com
dig TXT +short _netblocks1.google.com
dig TXT +short _netblocks2.google.com
...

dig TXT +short _netblocks9.google.com

最后是 AWS：

https://ip-ranges.amazonaws.com/ip-ranges.json

你通过某个库把查到的 IP 合并一下，就搞定了。绝对比 CN IP 那一套小很多。

当然你得先确认服务商给你的是真内存而不是虚拟内存。阿里云……嗯，就看你信不信了。

有预算就别裁内存。这东西一般来说当然越大越好。