我只存 RAW 不存 JPG （相机也只记录 RAW ），拍完放到 NAS 上去，电脑不留。
1 年 1T 其实也还好，一块 16T 的盘都够存个十来年了。

至于“管理”，我的做法是：
1. Windows 映射远程驱动器，把 nas 的目录映射成一个本地的磁盘
2. LightRoomClassic 导入远程目录的照，同时生成智能预览
3. 照片修好后直接保存，会在照片相同目录记录 xmp 文件
4. 有特别喜欢的照片可以用“加旗标、评星级”的方式标记照片

这样后面电脑不连 NAS 的时候因为有“智能预览”也能看照片，如果需要高清的导出，可以映射磁盘后导出。
在 Mac 上没找解决办法，因为 mac 没办法映射网络驱动器。

JBOD = just a bunch of disks ，物理设备，你可以理解成是“盘柜”，没有 raid 的功能，没有 raid 功能，没有 raid 功能。
再多说一句，我知道的家用成品 NAS 都是软 raid ，最起码我用的是软 raid 。
然后存储池是个逻辑概念。
如果拿 LVM 来比方（只是打比方）
单个硬盘好比 pv ，raid 好比 vg ，存储池好比 lv

就算是固定 IP ，也是限制对外的 80,8080,443 端口的。

@zhangjiashu2023 这不是 waf 的问题，而且 waf 是很耗性能的。

服务器层面
先从外网用 nmap 之类的工具扫一下看看对外开放了哪些端口，然后一个个去分析，没用的关了。
打开系统的防火墙，只对外开放需要的端口。
类似如 ssh 这样的服务如果非要外网访问，把 22 端口改成其它的一定程序上也有效果，关闭密码登录验证方式。其它服务思路也类似。

应用层面
你说的是一个典型的前后端分离的常规部署方式，没啥问题，但是也解决不了什么安全方面的问题。
安全上我觉得得具体看你的系统本身写的时候考虑的全不全了，像 SQL 注入，XSS 之类的，可以自己去扫一下，该解决的解决，waf 并不能完全解决问题。
然后就是应用的日志，记录好，记录全。Nginx 的日志也打开，定期看看有没有什么可疑的访问方式。

不对
你前端好比是 nginx ，那也必然要反向代理到后端啊，不然两个地址一直跨域访问吗？
这里只考虑应用级别的渗透，那操作的目标本来就是你的前端地址，然后 nginx 反向代理到后端，不是同样可以访问到后端么。
最简单的渗透用 burpsuit 之类的代理一下接口就全出来了。

自己买个硬盘靠谱

我觉得 C/C++“交叉编译”的意义不大。
通过 cmake 构建的如果写的严谨，理论上可以在不同平台下面编译，但也只是理论，
因为打个比方说 setsockopt 函数，在 windows 、linux 、mac 下面都有，但是有区别，一套代码想都支持，要解决这种情况太多了。
C/C++可能会依赖不同的动态链接库(.so .dll .dylib)，这个也是交叉编译的一个坎儿。
我觉得 cmake 挺好，比直接写 Makefile 简单，而且在 win 环境还能生成 msvc 的解决方案文件。

我觉得还是得看这些文件存储以后具体会有什么样的操作吧，根据实际的情况去选择。
如果是一个“小说”的“系统”，我觉得不会是某一种存储方案。
文件的基本信息需要放到关系型数据库里，文件本身其实我是倾向于放到对象存储里面，根据文件总量、单个文件大小、并发量还有能够接受的延迟，去选择具体的对象存储。
单纯从使用上说我从 S3, MinIO, Ceph 这三个里面去选，因为 api 基本兼容，后面不管换啥，代码都不需要修改。

成本 NAS 做 raid5 ，每天定时增量备份到 TrueNAS ，然后照片每年会记得成蓝光盘。

Js 跟 C 没有啥可比性，运行机制不一样。就像上面说的完全不是一个赛道上的。

程序员而已哪来这么强的优越感

glfw ，或者直接 vtk

是有这个现象。
电脑上不想装那么多乱七八糟的东西，而且鼠标键盘用浏览器也没觉得麻烦。
手机上浏览器使用就不如电脑方便，应用之类的套不套壳无所谓，好用就行。

Java 不是也支持了 var 声明变量么,C/C++里现在也有 auto ，我是一直挺反感这个的.
一方面像 js 这种往 typescript 这方向走，另一方面本来是强类型的又非要引入弱类型的风格。

应该是看具体产品和平台的设计吧
我 C621A 平台，16 条最大全插满也能跑 3200MHz

只是测试开发的话，如果身边有一些个旧电脑是不是可以利用一下