运行了快 20 年，机魂觉醒了都，可以留个 CPU 纪念下

土豆兄弟 +1

8 年 Android 开发表示路过。现在的话建议起步就学 Compose 了，最近也有 Compose 兼容鸿蒙的新闻所以这是一个能够包揽移动端的技术。但并不是说原生的开发就没用了，对于权限、通知栏或者桌面小部件这种和系统强相关的功能的话还是需要有相应的原生开发的知识的。如果如果想要入门原生开发的话我不建议看书而建议直接实战，去开发一个 TODO 或者记事本，这样列表、数据库或者文件 IO 、异步加载和 View 基本都接触了，遇到问题了再去找书或者找博客来解决，解决问题的过程就是学习的过程。

如果担心性能问题的话可以考虑 Mac Mini M4 ，可惜我自组 NAS 的时候 Mac Mini M4 还没有发布，否则 J1900 继续服役单独作为存储设备然后 Mac Mini M4 作为计算设备就很美滋滋了。

Android 开发者路过。曾经买过实体机插 NAS 上当测试机，NAS 用 Zerotier 组网远程过去 scrcpy 可以解决从家外面访问的问题，但是用了大概一两个月后实体机的电池就鼓包了。后面重新组了 NAS 从 J1900 换了 i3-8100 + 32G + Ubuntu Server ，性能足够后发现还是用虚拟机更香一些，开发的时候可以用 ssh 隧道直接映射远程虚拟机到开发上，从此不再操心电池鼓包问题。

我觉得 Linux 或者 Mac 开发起来表现更好并不是因为人家桌面系统好，而是类 Unix 系统的命令行生态确实秒杀 Win 。为了命令行生态没必要强行搞桌面，所以最简单的方式就是 Win + WSL + VSCode 远程就行了。

@mahaoqu Win 主力台式可开发可游戏 + MBA 外出办公 + 自组 NAS 装 Linux 或者 PVE ，除了要多花点钱以外没啥问题。如果实在想省钱的话，那就配强力台式本然后上 PVE 然后黑苹果/Win/Linux 都来一个，搞一个 HDMI 硬件直通。

心得体会就是多显示器，查资料对比代码的时候屏幕可以不用切来切去，就算远程桌面也有多的显示器直接用上，开虚拟机的话屏幕够多也可以直接用。接着是主力开发机 CPU 好点加大内存，保证性能就是开几个虚拟机也没短板。之后可以虚拟机起步，预算够的话直接买新的设备更好，性能不错的小主机或者最近的 Mac Mini 4 都是不错的方案。

主力开发是 Win10 ，外出办公用 MacBook Air 然后还有一个配置还凑合的 Linux NAS ，因为都在一个局域网下连同一个路由器可以省略交换机，我是搞移动端开发的不过最近也在自己用 FastAPI 和 Docker 搞后台，所以也买了一个便宜的 Ubuntu 云服务器。实际体验的话，在开发过程中并没有感觉 Linux 或者 Mac 有显著提升的地方，但是在打包、部署和自动备份的时候有显著提升是没的说的。

用 Mac 或者 Linux 可以简单点解决问题，游戏的话现在大部分 Linux 也能解决的，不过这个有点答非所问了。我自己也用火绒好几年了，但是用的一直就是旧版本的也没遇到过强制升级的问题。难道是这几天改了更新或者推送政策了？

@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 端口

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