@silencelixing 当大玩具的思路没毛病。我之前了解的都是往生产力方向靠的，比如用来跑 Ollama 大模型部署家用的 AI 服务之类的，要折腾的话可以看下这个。

硬要折腾的话我能想到的方式就是用比如 j1900 自组一个 NAS ，只存储不转码，然后网线直连到 Mac mini 上用 SMB 或者 NFS 或者 iSCIS 之类的方式挂载成一个文件夹，之后再由 Mac mini 提供 JellyFin 转码服务。各设备独立也能避免 ALL IN BOOM 的问题。

Mac 搭配硬盘柜插线的方案固然可以但是可靠性和拓展性都比较一般，甚至说比较差都没问题，比起组一个 NAS 而言将之当成一个计算型的家用服务器定位更合适一些。

假如单盘损坏的概率是 x 有两个硬盘的话，Raid1 的和定期备份到另一个盘的数据暴毙概率都是 x²，但是后者可用容量是前者的两倍，对个人用户来说肯定是后者的更合适一些。

记得前不久站上刚有人讨论过这个问题？有个老哥说就是组 Raid 是为了保证比如 MySQL 这样重要的服务在运行时就算坏了一块盘也能够临时顶住服务，之后运维老哥就该备份全盘数据然后重新替换一整套的 Raid 并恢复数据和服务。不选择直接重建 Raid 是为了避免重建时仅剩的硬盘继续损坏导致数据暴毙。

换句话说 Raid 并不是用来代替备份的，而是相当于 ICU 一样在临终前有机会交代后事用的。

但是如果你不需要逻辑，只是要纯粹可以让客户端可以访问到服务器上的 json 数据的话，我个人觉得最简单的办法就是直接用 Nginx 管理静态的 json 文件数据。甚至数据不敏感而且并不怎么重要的话，你直接扔 gitee 或者 github 上然后有个 Raw 按钮，点击就可以直接下载了。

整个流程还要配置域名、防火墙、http 自带加密和后台校验、json 文件和日志的定期备份啥的。我是自己要开发一个应用的后台所以需要自己处理这一整套的东西。

最近刚好做过类似的东西，简单说下：

1. 用 FastAPI 和 Python 搭建简单的脚手架，用户以 JSONArray 的形式传入 文件名

2. 接口接收到文件名后从某个硬盘目录上去查找对应的 "文件名.json" 文件

3. Python 可以直接用 import json 包来解析文件成为 dict ，这一步也算是用来验证 json 的格式是否合法或者做一些校验

4. 将 dict 转化成 string 作为 body 和 200 状态码返回就行了

5. 用 docker 和 python 的镜像打包成 .tar 文件发送到你的云服务器

6. 云服务器 sudo docker load -i XXXX.tar 镜像，然后用 docker compose 配置端口映射到本地的 8000 并启动

7. 用 Nginx 配置当访问 /api/ 路径的时候，倒向本机的 8000 端口

很强的执行力，值得关注！

@sastar 感觉不错啊，这个待机功耗多少？

前一段时间刚自组 NAS 的路过，各种对比了一顿下来感觉就三种方案：

方案一，也就是我目前的方案，i3-8100 。不要选 i3-8100T ，带 T 只是限制了最大功耗而不是降低了待机功耗，待机没差别但真干活的时候还不如不带 T 的。淘宝价 120 上下。主板我选择云星 B365 ，ITX 板有一条 PCIE ，支持 D4 内存，6 原生 SATA ，2 M2 ，2 RTL8125B 2.5G 网口，这个主板兼容 6-9 所以你的 i5-8400 可以直接上机。我插了 2T HDD 两个和一个 M2 ，目前待机功耗 24W ，电源是海韵的所以转换率还不错。

方案二，N100 。性能和 i3-8100 基本是一个档的但是待机功耗可能更低一点，比起 i3-8100 来说支持 AV1 解码。由于本身缺少 PCIE 通道所以这个 U 本身 PCIE 通道少，不支持双通道内存，板 U 一体的，可以看看畅网的板子，大概 800 上下，但是记得好像用不了 D4 内存。

方案三，i3-12300T 。性能大概是 i3-8100 的两倍，但是相对的功耗就高一些，需要有多开虚拟机或者强劲性能的话选择这个也不错，直接就战未来。不过我我不需要这么高的性能和功耗所以没怎么了解过主板，目测应该用不了 D4 内存。楼主可以自行找找资料。

另外需要注意的就是要意识到环境中对于你人格的打压。中国的传统社会观念普遍存在着打压个体性的情况，包括告诉你自私是不好的，舍己为人是好的，先天下之忧而忧之类的，这种满口仁义道德的东西都是用来打压你的个体性使得你服从集体的。而题主现在的情况我的建议是，你应当先意识到 “自私是一件合情合理合法的自然的事，而且可能是好事”，自私是人性中天然存在的一部分。如果自私和无私是天平两端的话题主就在无私的那端走太远了，需要学会自私来平衡。

自爱的第一步，是要意识到自己值得被人所爱。理性上你可以直接认为被人所爱是天赋人权，人人都值得被他人所爱，但是感性上很难说服自己去相信这一点。可能像楼上建议的那样，先每个月固定设定一个 “给自己花钱开心就好” 基金，开始慢慢让自己接受 “给自己花钱让自己开心并不是一种罪或者是值得羞愧的事情” 。

童年缺爱，常规的情况是童年得不到关注，于是忽略自己的需求去满足环境的需求起码能够换得一个“乖孩子”的评价。别人说分享是美德于是就对他人特别好，别人说安静读书是好孩子就读书，别人说要谦让那就把好东西都给兄弟姐妹，好孩子不会让父母为难所以好吃的好玩的就算想也不敢提出来，久而久之解决得自己不配被他人所爱，也不配被自己所爱，所以连自爱都是很难做到的。这样成长起来的人很可能觉得快乐是一种罪。

@jeesk 本来就是一个非常小众的小工具，就算被破解也没什么太大的问题，用的人这么少连破解版都比较难以传播。现在主要在头疼国内后台的开发上。

@jeesk 目前的做法是在使用 https 的基础上对 post 请求的 body 用 aes 加密，然后 aes 的 key 用服务器的公钥加密扔 header 里面，后台也用一样的方法加密 body 然后用客户端的公钥加密 key 扔 header ，这个是双线 TLS 么？我是 Android 原生开发出身的所以对这些术语并不是非常熟悉。Header 里面同时带有 aes 加密的设备时间戳和 UUID ，时间戳和服务器允许若干分钟的时差，UUID 后面可以做频率限制。客户端也在 so 文件里面做了验证了。

@renmu 我是做 Android 原生开发出身的所以对后台和前端的开发都不甚了解，所以发出来问问看看这个操作是否可行。关于防止用户破解的：

1.用户要离线使用怎么办。用户不可能一辈子不联网，另外客户端本身没有什么有价值的东西，用户愿意一直离线使用也无妨。
2.Hook 掉轮询。用户有这个本事直接 Hook 判断是否已激活的方法就行了，没必要多此一举。
3.有多个激活名额。我看竞品的设计是一个激活账号只允许 3 台设备使用，这里就直接抄了。超出名额的部分的限制在后端做。

@renmu 确实没什么创新啊，只是想看看这种操作有没有可行性

@Repobor 这套机制对开发和用户来说似乎都不是很友好