使用手册：
https://docs.microsoft.com/en-us/windows-server/administration/windows-commands/robocopy
TL;DR 的命令例是(e 代表包含空文件夹，mt 代表线程数)：
robocopy e:\crowdsource-webapp e:\abc /e /mt:8
至于原理，其实很简单：多线程复制
下面截图的是复制大量小文件（node_modules）的成绩，作为对比的是，在windows 图形界面下，15 分钟只复制了 56%。而用 robocopy 10 分钟复制完成。
做了一天的 SSL 部署工作，会反思到 docker 在某些情况下是不是真的带来了便利。比如今天的工作，这个项目的 API 和 frontend 写在了一起，都打在一个 docker 里面。这是大前提。
于是做 SSL 的时候，API 端口和 frontend 端口要分别反代、配置 SSL、暴露给外网。换句话说，frontend 里面对 API 的访问需要基于暴露给外网的配置，而不是 docker 里面 localhost 的 API 端口。开发方面的麻烦其实还好。在部署上会比较讨厌，第三方用户拿到这个 docker image 之后并不能直接用，而是需要先把反代配置好。于是开箱即用便成了空话。
反过来想，其实这并不是一个贯彻 docker 思想的部署。docker 思想的核心是微服务化。API 和 frontend 拆开是更符合 docker 思想的方案。在我自己的项目里面，这一点会做得比较好。不过另一方面，如果拆开了，开箱即用仍然是一句空话。
深入这个问题的话，万恶之源是什么呢？ – SSL。如果 https 访问 http 的 API 没有问题，那怎么设计都是无痛的。
面向未来和解决方案的话，希望有办法在后端开发的时候直接可以方便地载入 cert，使得后端端口原生就是 ssl。以此来避免 mixed content（https 混 http 导致内容无法访问）的情况。
面向一并倒掉脏水和孩子的话，拥抱静态化可以解决所有问题~ 我爱 github 和 netlify~ 但 docker 仍然有无可替代的作用，比如我会希望通过不超过五步 step by step 的帮助，让任何没有技术背景的人能在本地部署一个独享的、高速的服务器（比如未来的 CBDB）。这是静态化无法做到的事情。