但是如果你不需要逻辑，只是要纯粹可以让客户端可以访问到服务器上的 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 这套机制对开发和用户来说似乎都不是很友好

@InDom

3.修改邮箱。最开始构想这个方案的时候就是不想自己维护一套账号系统所以想要省略诸如找回密码的步骤的。人工处理的话起码先确定收件人，然后要求对方提供购买的微信截图，邮箱地址和截图中的付款订单号对得上就确定是原主，此时帮他人工修改无妨。当然用户也可能会这个过程中进行二次售卖，只不过加上人工的话流程会繁琐很多。

尝试过后来觉得自己维护一套自己习惯的配置需要耗费巨大的精力，如果不是真的喜欢折腾的话有点得不偿失。就我自己折腾过后的建议是，这玩意更适合配置 iterm2 或者 Windows Terminal 等支持下拉模式的命令行工具做一个全局随时呼出的记事本，并配合 Git 或者其他管理工具来同步备份笔记数据，偶尔改改系统配置文件复制点东西之类的。轻量级的开发无论是远程还是本地用 VSCode 都足够搞定，重量级的还是直接上 IDE 吧。

@baobao1270

1. 小工具基本没办法防止反编译啊，而且用户有这个能力的话那此时也就不是操心账号和付费系统的时候了
2. 抓包的话用 https 里面套了一层 RSA 加密，客户端和服务端互相持有对方的公钥的那种
3. 综合下来就是用微信登录和订单号作为记录最靠谱，还能预防二次转卖的问题

@ysy950803 看了眼通知滤盒，这个更简单连激活码都不做，直接用订单号作为激活码了。感谢提点，很有启发！

@baobao1270
1. 这个没毛病，赞同。
2. 小工具品类东西都在客户端上，后台也不提供服务的情况下登录了也没有更多功能，所以才考虑简化的。看了眼 logto 似乎能解决部分问题不过还是感觉略复杂，打算接微信登录算了。
3. Android 开发里面没听说过 ASM ，这个是前端的东西吗？
4. Mitm 也没听说过。
5. 国内基本是微信当邮箱用的，所以直接接入微信生态似乎是一个更好的选择