补充一下，我不是从百度上搜的，我是从淘宝店搜的，实际上不管你从什么渠道，甚至是有公司背书的专业团队，都有十分有可能遇到这种强卖“疏通剂”的情况，我是下单前已经和客服沟通好了，证据充足。

现在用所谓“疏通剂”的手段是个非常常见的手段，几乎所有疏通下水道的都会用这个手段，但实际上只是为了骗钱。

我之前遇到过，因为预约的时候就承诺不用任何疏通剂，结果来了后改口说不用疏通剂通不了，于是我就说报警、工商、消费者协会随便选，然后立马软了，约好收多少就收多少。

技术人员知识面不怕广，知识面越广，解决问题的思路越多。

如果你觉得深入了解对你的工作或你想实现的目标有帮助，你就深入了解一下呗。

只要分清主次就好。

目前开发 Web 全栈，体验上没啥区别，所以没必要套一层虚拟机。

便捷程度取决于你怎么用，正常使用话一个是在 Mac 上开 Docker daemon，另一个是先开 VM 再在 VM 的 Linux 里开 Docker daemon，（或者两者的 Docker daemon 都做成自动启动的），这么看来好像在 Mac 上直接用 Docker 更方便。

IO 性能方面，VM 多套了一层虚拟磁盘，猜测可能会有性能损耗，没实测过。

系统稳定性跟这俩方案没关系把，取决于你用的啥系统，以及系统使用状况是啥样的。

https://certification.ubuntu.com/desktop
Ubuntu 官方认证的硬件。

另外 System76 是专门做 Linux 电脑的，硬件软件都做。

台式机只要是主流厂商的硬件通常都没问题。
笔记本核心部件主流厂商大多也能兼容 Linux 发行版，有问题的通常是些定制的或杂牌的硬件，比如触摸板、各种指示灯。

最新出的硬件可能因为对应的 Linux 驱动还没有面世而无法正常使用，比如我 2015 年的时候攒的台式机，Arch Linux 就无法正常驱动我的 980Ti 显卡，但过了数月新驱动发布后，就可以正常使用了。

如果你用台式机的话（不纠结电源问题），也可以考虑虚拟机里跑 Linux，能解决所有潜在的硬件兼容性问题。

https://docs.mongodb.com/manual/core/index-compound/

“The order of the fields listed in a compound index is important. The index will contain references to documents sorted first by the values of the item field and, within each value of the item field, sorted by values of the stock field. ”

索引会先按照前面的字段排序，然后这个字段相同值的 documents 再按照后边的字段排序。

可以用 explain 做一下试验：
time 、lv 、lv-time 、time-lv 四种排列情况都建索引，然后执行：
db.getCollection('test').find({"time": {"$lte": 1}}).sort({"lv":1,"time":1}).explain()
最终返回的结果是：
winningPlan" : {
"stage" : "FETCH",
"filter" : {
"time" : {
"$lte" : 1.0
}
},
"inputStage" : {
"stage" : "IXSCAN",
"keyPattern" : {
"lv" : 1,
"time" : 1
},
"indexName" : "lv1time1",
"isMultiKey" : false,
"multiKeyPaths" : {
"lv" : [],
"time" : []
},
"isUnique" : false,
"isSparse" : false,
"isPartial" : false,
"indexVersion" : 2,
"direction" : "forward",
"indexBounds" : {
"lv" : [
"[MinKey, MaxKey]"
],
"time" : [
"[MinKey, MaxKey]"
]
}
}
},
可以看到命中的是 lv 在前、time 在后的索引。

蛋壳、自如这样的租房企业对办理这种业务都门儿清，你直接联系他们就行了。

IP 识别最广泛的就是查表法吧，有一张表，记录着 IP 段和地理位置之间的对应关系（这个数据有可能能是一些运行商的公开披露数据或者合作共享数据），一个 IP 过来后直接从表里查对应的地理位置。

这个方法的问题就是如果你的表格里 IP 段与地理位置对应是错误度的，解析出来的结果就是错的，所以需要及时校准数据，而因为 IP 是全球超多家运营商在使用的，所以难以做到精确和实时。

你看看你用的产品是不是可以手动设置地区。

我了解到的显卡就是围绕两方面的工作吧，一个是多媒体方面的，另一个是并行计算方面的。不考虑其他的非常规 Geek 用法的话。

游戏主要是利用的图形绘制方面的功能，这个功能也可以用于美术创作、3D 建模、CAD 等等需要为绘制图形进行大量计算的场景。

显卡提供视频的硬件编码器、解码器，虽然也有软解方案，但硬件处理性能更好，比如你看 4K 视频，如果核显硬解、CPU 软解性能都不足以流畅播放的话，比较好的独显可以胜任。另外很多视频转码工具也可以利用显卡里的编解码器加速转码工作。

NVIDIA 显卡里提供 CUDA 计算单元，可以提供比 CPU 强很多的并行计算能力，机器学习、加密货币等只是其应用并行计算的两种领域，还有很多其他的并行计算需求可以用 CUDA 高效完成。
相应的 OpenCL 是更通用的计算框架，可以利用很多种处理器进行计算，包括各家 CPU 以及显卡。

新房都是新的，通常产权时间是满的，但是可能不如旧房质量好。所以新房最好能找些懂行的人看看整体建筑是否靠谱，比如楼板和墙的厚度、材质，水电等技术设施是否安装合理等。

感觉这个贴会引战。。。

说“中医”和“西医”其实并不严谨，因为西方国家的传统医学也存在过不靠谱的治疗方法（比如移植羊蛋蛋给人来治疗不孕不育），严谨一些我们就说“中国传统医学（以下简称“传统医学”）”和“现代医学”吧（毕竟中国对现代医学的贡献也是非常大的）。

传统医学目前依然存在，是因为其并不是完全无效（否则就真的没人用了），正规的传统医学是以其独有的世界观来解释人体、健康、环境之间的关系的，只不过这种世界观并不以当今的自然科学为基石，在外行人看来更像是一个架空的世界观，而且传统医学的治疗依据难以被患者理解，所以患者只能看疗效来评估其有效性。

现代医学是基于自然科学的，每一个结论都有下层结论的支持，层层推导，所以能让人感到有理有据，但是人体是极其复杂的系统，内部各个因素互相影响，导致我们到现在也没有 100%掌握生命的原理，治疗方案和效果也并不能保证完全可靠。

我本人比较倾向于现代医学，主要是因为个人对生物学、医学十分感兴趣，对医生的治疗方案也能理解一二。
但相应的，对于一个对传统医学有一定了解的人来说，可能传统医学的治疗方案也能让其理解（我身边有这样的人）。

不管是传统医学还是现代医学，最重要的是医生是否靠谱；就像技术很烂的程序员用什么语言写的程序都一样烂。

如果是希望虚拟机负载高的时候保障宿主机的性能，可以在虚拟机的设置里调低性能限制，可以调核心数、CPU 占用率、内存大小，确保满负载给宿主机留下充足的性能。

另外如果对系统 API 依赖较少和不依赖图形界面的话也可以考虑容器化，容器会更轻量，而且也可以做性能限制。我自己用 j4105 攒的 NAS 跑 OMV 、Gnome(搭配 Kodi)以及 4 个 Docker 容器，不过跑的东西负载都不高就是了。

不过考虑到你的 nuc 只有 6 核 64G 的资源，要跑 6 台虚拟机，所以可能再搞一台还是有必要的。

如果需求特殊，必须要用 VMware 的话，没测过 Ryzen 3000 系列到底兼容如何（用过的可以来说一下），但我自己跑 Linux 和容器都没有问题，万全之策的话至强可能比较不容易翻车，但工作站平台的硬件不好淘。
ITX 攒出来很可能也放不进背包，除非完全定制散热和电源，不过拉杆箱应该是可以的，只要你不每天携带的话也可以考虑。

综合来看 1 和 4 可以考虑，如果有人知道 Ryzen 3000 系上用 esxi 没有坑的话 3 的性价比是最高的。

除了 nuc 以外，各个品牌也有迷你 PC 产品，比如技嘉的 BRIX 、华擎的 DeskMini 、华硕的 MiniPC 等等，体积够小，可以看看相关测评。

直接复制或链接到你的 node_modules 里就可以了。

在你项目目录里
```
# 确保下载的包目录名字为 phantomjs-prebuilt
# 直接复制到 node_modules 里
cp -r 你下载包的位置 /phantomjs-prebuilt ./node_modules/

# 安装依赖
npm i
```

不过有可能其他包也下不下来，这种情况要么挂代理，要么用 cnpm （淘宝源）吧。

基本思路就是在这个函数能被调用的整个生命周期里，开辟一个存储空间来存每次传入的 callback，然后每次调用这个函数都从这个存储空间里读出之前所有传入过的 callback 一起调用。

上面楼层都给出了实际的代码。

有一个问题需要注意，就是你开辟的存储空间是有限的，在长时间高频调用的情况下，理论上有可能达到上限而抛出错误，而且因为每次执行的函数数量递增，执行需要的计算量和时长也会逐渐增加。

从代码可读性上，可以调整代码结构或增加注释来让看代码的人很快意识到这个函数的特殊性。
比如可以创建一个 Class，实例化的对象的状态保存在对象内部，通过调用对象的方法来实现你的功能。

都散了吧，楼主本身就是来宣泄的，不允许其他的三观存在。开头已经说明白这个帖子就是“吐槽”，附言里直接开始攻击人了。

你试试，是不是真的会卡慢，我觉得 300 个属性其实还好。

如果真的卡再考虑优化，比如数据一次性获取，但是 DOM 按需渲染，你的思路是可以试试的。

说实话，用 Node.js 内置的 http module 手撸 API 也蛮快的，比如自己写一些 CI/CD 的 hook 。

轻量的话主流就是 koa 了，只有一个 context 核心，router 、bodyparser 等额外 use 几个 middleware 就行了。

当然，如果你懒得自己装 middleware 也可以用一些集成方案，比如 express 。

其他的就是哪个顺手用哪个，最好是不用遵循什么严格的架构设计的。

上千万数据做过遍历，没遇到过这个问题。。。

跑脚本的时候看一下数据库负载，用了聚合的话看看是不是需要 allowDiskUse，如果断开了看看脚本和数据库的日志，是不是需要调节一些超时时间。

另外 Python 脚本本身会不会因为资源不足而挂掉。