所谓的 NAS 系统基本就是在通用系统的基础上提供了一些管理功能而已，具体还是看你需要哪些管理功能，是不是不需要 NAS 系统来满足。

如果只是 RAID 存文件然后加个 Nginx ，好像也没必要非要找个什么 NAS 系统，随便找个 Linux 发行版稍微配一下就行了。

六类就行，一般住房接线距离比较短，信号不容易衰减。

在大城市，做饭最大成本在于厨房，这几个平米的价格不便宜……

如果你有足够理由要利用上阵列卡，那么最大的问题就是驱动问题，这时候就是看你阵列卡的驱动支持哪些系统，就只能用哪些系统，基本没得选。再加上你要用虚拟化，你的卡和驱动支不支持直通，还得研究研究。

其实跳出来看的话，所谓的 NAS 系统倒不是必要的，因为 NAS 就是个存储池+文件传输协议，各种 NAS 专用系统也只是给你增加了各种功能可以更方便管理 NAS 或者跑些其他不属于 NAS 应用范畴的东西而已。

所以归根结底还是要看你的需求，你需求越细，可选择的范围就可以划得越小，也没准最后发现没有任何一个 NAS 系统能满足你所有需求，只能自己手动搭建。

@dknagi #20 软路由单独搞，是因为通常对网络设备的可靠性要求远高于普通服务器。
从我个人的经历来说，AIO 把软路由放里面，每次折腾服务器都会导致网络不可用，很烦人。单独设备跑软路由配置好扔在那就不用动了，不管我怎么折腾服务器，网络都始终可用。

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Number/MAX_SAFE_INTEGER

JS 里用的 Number 是由 ECMAScript 规范定义好的，使用双精度浮点型，而双精度浮点型是 IEEE 754-2019 定义的，有精度边界。
用数字之前先看一下是不是超过了 MAX_SAFE_INTEGER 就行了（相应的还有 MIN_SAFE_INTEGER ），ES 和 JS 里面已经提供了这个常量可以用来对比。

前端用 double 类型，后端也用 double 类型才算是合适；相应的后端如果用 int64 ，前端也得用 bigint 。使用其他语言也是一样的问题，就好比用 C 写的客户端使用 double 类型与用 int64 的后端通信。归根结底是数据类型一致可以直接避免所有问题。

唯一的问题是 JSON 支持的数据类型有限，比如不支持 bigint ，所以就需要前后端换成其他兼容的类型（比如字符串）来使用 JSON 传输，或者干脆不用 JSON 换其他交换格式。
JSON.parse()支持传入 reviver 函数来对 k/v 进行处理 https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/JSON/parse#description
当然也可以找一些现成的支持 bigint 类型的 json 序列化和反序列化库。

这俩我都在用米家的，2019 年用到现在，倒是没遇到啥问题。

看来你们应该还没有做过等保，这种被公安知道了可能会被责令停业整改的。

@yuyang1992test #18 我回复说了，看具体使用场景。

我们做的 APP 中有些书签功能就是记录在本地的，因为用户并没有跨端同步的诉求，而且多人共用的个别功能用户还要求不要多端同步。

如果你的产品设计上需要可靠保存这个信息，就记录到服务器上，如果不需要可靠保存，就没必要浪费服务器的空间和算力。

需要可靠保存的话，存在 Redis 里还需要给 Redis 做持久化，或者复制一份给数据库，否则 Redis 重启数据就丢失了。

你的需求有很多实现方案，具体用哪一种取决于你的详细需求。

只用来看小姐姐……

高频读取用 Redis ，低频读取存数据库，不需要跨端就记录到客户端/浏览器本地，部分场景还可以记录到 URL 里。

@zzz6519003 #9 啊？不是。
你是说我的头像吗？是朋友给我画的。

@Lunrry #9 多个网络的情况，比较理想的做法是做专用的通道来将监控数据集中收集。比如数据从每个网络以加密的方式推送到中心监控服务器。

你可以看看 Zabbix 的官方文档，看是否可以在每个网络内使用 Zabbix Proxy 来收集网络内的监控信息，然后再让 Zabbix Proxy 主动推送信息到网络外的中心 Zabbix 服务器。

遇到的问题会不一样，如果是自组遇到的问题可能就是偶发性掉盘、系统死机、软件升级报错等问题。

理论上来说，如果你技术水平无限好，是可以做出比市面产品更好的体验，但是所花费的精力和时间成本可能还不如直接买个成品，除非成品真的无法满足需求或者就是喜欢折腾。

具体还是看你的需求，如果成品满足需求就尽可能用成品，性能不够就选更高配置的产品，只要钱到位，什么问题都能解决。

不说缩写，就说全称，在不同团队内的工作内容也可能有些区别。

比如有的后端还包括运维工作，有的产品经理还包括测试工作，有的前端还包括 BFF 的工作。