jinliming2

看着貌似 5.180.253.215 的端口一直是 28000 不变，而 37.114.49.176 的端口一直在变。
sudo lsof -Pi | grep 28000
看看呢？看看本地是不是有这么个进程？

用户的网络情况可能是很复杂的，即便是在没有防火墙的国家，也可能会遇到比如连接了需要登录的 Wi-Fi 之类的情况，所有域名解析都会被拦截并跳转到 Wi-Fi 登录页面，所以 ping 、tcp ping 、普通 http 请求都是不可靠的。

所以 #12/#14 正解，但是服务器竞速比较常用的方法是提供一个 http 的 /generate_204 接口（/generate_204 属于事实上的标准，虽然没有定义标准，但大部分网站选择遵守），这个接口没有任何逻辑，仅返回 HTTP 状态码 204 ，且没有 body 。业务需要判断接口返回的状态码是 204 而非其他。
在 /generate_204 正常返回之前，都属于网络未连接的状态，应当以一定时间间隔（通常时间间隔越来越大）重试，直到最先返回的就是最快的。后续定期检查更新网络状态。

@scienhub #26 文档的话，简单看了下他们的 TSDocs 貌似挺详细的？每个字段、函数的含义都有说明，在编辑器里鼠标移上去应该都有文档提示？
也有工具能够根据 TSDocs 生成统一文档站的。

然后，楼主的运行方法，tsc 只是把 ts 转成 js ，还是会依赖 node_modules 的。
按需打包的话，相当于仅保留用到的代码，带上 tree shaking ，最终你用到多少代码就得到多少代码，还会去掉注释，这样 TSDoc 就都没了，最终产物不会很大。

好奇去看了下，src 目录和 tencentcloud 目录是大头。
src 下是 ts 源码，tencentcloud 下是编译过给 Node.JS 用的 CommonJS 代码。
然后里面主要内容在 services 里，有各种服务，平均 100k 左右，整个合起来就那么大。
然后 services 里面具体的有的会带日期命名的多个版本，应该是对应给不同版本的服务用的？如果确实不同版本同时有人用的话，那保留多个版本也还算合理？虽然更常见的做法是拆分不同版本的包，但是对于这种云服务 SDK 来说，我觉得放在一起问题不大。
然后里面最大的文件大部分都是 models 文件，是数据类型字段定义。然后大头是字段的 TSDoc 文档注释。

然后 CHANGELOG 有 5M 大小，内容大头是 commit history 。

src 和 tencentcloud 同时提供我觉得没什么问题，有些人倾向于直接 Node.JS require 使用，就用 tencentcloud 下的 CommonJS ，而有些人倾向于按需打包，用 src 会好一些（用 CommonJS 也不是不行，但 ts 源码更好）。
不过他们 src 下的导出方法有点问题，有多个版本的时候是 import 两个版本，然后 export 一个对象包含两个版本的 key ，这导致按需引用会出问题，总是会把所有版本都导入。
examples 和 tests 目录不算大，大部分库也会带着提供，提供不提供都行的。一般闭源的库会提供，开源的库你可以在项目托管的地方找到，就没必要提供。
CHANGELOG 也是大部分项目都会提供的，但开源的也确实同样没必要。

关闭 shell 是否退出启动的进程，跟对应的程序有关。如果启动后就保持那个进程没有 detach ，那你退出 shell 对应的进程也就都关了，但如果程序启动之后 fork 了其他进程然后自己退出了，或者 detach 了，那就跟原始 shell 没关系了，退出 shell 对应的进程就不会被关闭。

是不是路径有空格、中文之类的🤔

RAID 和坏不坏没有直接关系吧？只是：
不做 RAID 大部分是单块硬盘，坏的几率很小；而做 RAID 肯定是多块硬盘，虽然其中每一块坏的几率很小，但是硬盘数量越多，越容易碰到坏硬盘的情况。
或者，可能做 RAID 大部分情况下多块硬盘是放的距离比较近的，机械硬盘共振会提升每一块硬盘坏的几率？

@mafuyu #15 看了下下面那个 apoke ，貌似就是我要的，新台币 7990 差不多要 1800 ，有点小贵，我再找找类似的产品。