手机在兜里震了一下屏幕上跳出“存储空间已满”的提示这已经是这个月第四次了。我把抽屉拉开里面躺着七块硬盘两块从旧笔记本上拆下来的 2.5 寸盘、三块早年装机剩下的 1TB 机械盘、还有两块不知道装过什么的移动硬盘。每一块里面都散落着几年间拍的照片、剪辑到一半的视频、以及一堆名字叫“新建文件夹(3)”的东西。那一刻我意识到我缺的不是硬盘而是一个把“光影”——照片和影片——集中收拢、随时能取、坏一块也不至于全丢的地方。这套东西后来被我起了个名字叫光影猫一只蹲在电视柜角落、常年不出声、但家里所有照片和片子都归它管的小主机。下面这些内容就是我从画草图到跑满三个月、中间翻过车也返过工的全部过程记录。适合手里有几块闲置硬盘、想搭一个属于自己的个人 NAS 系统、又不想上来就买整机的人看也适合已经有一台机器但一直没真正用起来的同学里面关于目录规划、入库流程和备份分层的部分可以直接照着抄。1. 光影猫到底要干什么先把需求翻译成参数1.1 我最初写下的三个真实场景动手之前我强迫自己写下了三个具体场景而不是“我要一个 NAS”这种空话。第一个场景晚上十点躺沙发上用电视看自己拍的旅行视频和攒下来的片子不要插U盘、不要开电脑。第二个场景手机连上家里网络相册自动往光影猫里备份一份我不用管。第三个场景几年前的老照片想翻出来发给家里人用手机或平板就能找到、能预览。这三个场景决定了后面所有的选型需要长期在线的低功耗主机、需要能放多块盘的存储空间、需要能解码视频的硬件、需要能被手机和电视同时访问的共享协议。写场景这一步看着像废话实际上是整件事里最省钱的一步。我见过太多人上来就问“我要不要上八盘位”结果买回来两年的照片加起来还没填满一块盘。场景写得越具体后面砍配置的时候下手越狠。比如我第三个场景只是“翻找和预览”那就完全不需要考虑什么随机读写性能、也不需要全闪存机械盘顺序读取一两百兆的速度足够我在手机上滑缩略图了。真正的需求只分三类备份不能丢、观看要流畅、共享家里几台设备都能用。这三类对硬件的要求完全不一样混在一起谈就容易过度采购。1.2 从“想存多少”倒推容量和性能容量这块我给了一个简单粗暴的估算方式实测下来偏差不大。手机照片按每张 3~5MB 算一年拍 6000 张加上视频一年大约 80~150GB相机拍的 RAW 一张 25MB 左右一次出行 1500 张就是 37GB影片按 1080p 每部 8~15GB、4K 每部 40~80GB 估。再加上旧硬盘里那些存量数据我最后的结论是未来三年需要 6~10TB 的可用空间。这里有个关键概念要拎清楚可用容量不等于盘位容量总和。如果用校验盘方案四块 4TB 里有一块的容量是拿来做校验的可用大约 12TB如果用镜像方案四块盘的可用容量只有 8TB。所以算完需要多少还得回过头算需要几块盘。我当时的对照表是这样的方案盘数标称总容量实际可用坏一块的后果适合谁单盘直用14TB4TB全丢只能靠外部备份数据可再获取、只做临时中转两盘镜像28TB4TB可用但重建时无冗余数据重要、预算有限四盘校验416TB12TB可用允许再坏一块影音库照片主力存储四盘镜像416TB8TB双盘冗余更保守小容量高价值数据性能上我给自己定的底线是局域网内单路 4K 播放不卡、手机端刷缩略图不转圈、手机备份上传能跑到 60MB/s 以上。这个底线决定了必须有千兆以上网口也决定了处理器不能太寒酸——不是因为它算得快而是因为转码要靠它。1.3 我为什么没买成品整机也没上全闪存成品整机的好处是不用折腾开箱即用系统、套件、手机端都配好了。我最后没选它原因很实际手上那七块旧硬盘里有一半是不同容量、不同年份的成品方案对混合容量的容忍度普遍不高要么浪费要么得统一重买而且整机的扩展路径基本锁死三年后想要更多盘位只能整机换掉。全闪存我也试过一版用四块 1TB 固态组了个纯闪存池。速度确实爽手机相册秒开但一算账就清醒了同样花这些钱闪存能买到 4TB机械盘能买到 16TB。而我的使用场景里 99% 是顺序读写和大文件搬运闪存的随机性能根本用不上。折中的做法我最后采用了小容量固态做系统和热数据缓存大容量机械盘做仓储两边各干各的活。这台机器不是性能玩具它的价值在于“十年后我还能把照片翻出来”。所以每一个决策的优先级都是容量 可靠性 安静 速度。2. 硬件这盘棋小主机怎么配才不别扭2.1 处理器和主板够用和过剩的那条线处理器我踩过的第一个坑是“按跑分选”。第一版用的是一颗老款四核跑分不难看但它没有硬件解码单元播放某些编码格式的片子时全靠软件硬扛两个客户端同时看风扇就开始唱歌。换到带硬件解码的新一代低功耗平台后同样两部片子处理器占用从七成掉到一成出头整机功耗还降了几瓦。我的经验是这个场景要盯的不是核心数而是三件事有没有硬件解码单元决定能不能流畅转码、待机功耗够不够低决定它能不能常年开着、PCIe 和 SATA 通道够不够决定以后能不能加盘、加网卡。核心数四到六个完全够内存 8GB 起步、跑容器和相册索引建议 16GB。主板这块有个容易被忽略的点SATA 接口数量。很多小板子只有两到四个 SATA 口看着够用但你没有算上系统盘。如果系统装在独立的小固态上那四个 SATA 口实际只能接三块数据盘。我当时就是因为这个细节把原计划的两块盘方案改成了三块后来加盘时又被迫加了一张扩展卡。选板子时先把“系统盘 数据盘 一块预留”的接口数算出来再下单。2.2 硬盘分层新盘、旧盘各归其位硬盘上省钱是最容易后悔的地方。我给自己定了三条规矩。第一新盘只买 CMR 不买 SMR。SMR 盘的写入机制决定了它在大量小文件、频繁改写、阵列重建时表现极差重建一次可能从十几个小时变成好几天这段时间里如果再坏一块数据就没了。分辨方法很简单查官方规格里的记录技术或者看缓存容量和价格——同容量明显便宜、缓存特别大的多半有猫腻。第二同一阵列里的盘尽量同容量、同批次错开购买。同批次盘出厂时间接近、磨损接近容易在同一时间段集中出问题。我四块盘是分三次、隔了几个月买的虽然型号一致但生产日期拉开了差距。第三旧盘不清空就直接用是大忌。我那几块旧盘全部先跑了一遍全盘表面扫描和健康属性检查写入全盘再读回校验确认没有坏道和异常增长才允许进阵列。有一块 1TB 的老盘在这一步就被刷掉了读写测试到 60% 时速度断崖式下跌。如果它进了阵列后面就是无穷无尽的麻烦。2.3 机箱、电源和噪声它蹲在客厅安静是第一需求光影猫放在电视柜角落离沙发不到三米。所以噪声不是加分项是及格线。我实测过三种状态硬盘空闲时整机 28 分贝左右基本听不见四块盘同时寻道时能到 40 分贝上下晚上安静的时候能听见轻微的“咯咯”声风扇全速时最吵所以我干脆把风扇曲线调得很保守靠大尺寸低转速风扇慢慢吹。降噪上真正有用的三个动作硬盘加减震螺丝或橡胶垫机械盘的振动会通过机箱放大这一项效果最明显、机箱里别塞满留出风道比堆硬盘重要、把机器放在硬质平面上而不是地毯或软木上软质底面会把振动变成闷响。我还试过在侧板贴隔音棉效果一般反而让温度升了两三度后来撕了。电源这块我的建议是别买杂牌大功率。整机满载也就七八十瓦选一个品质靠谱的、额定 200~300W 的就够重点看转换效率和低负载表现。劣质电源在低负载时效率很差常年开着电费差距会慢慢显出来更麻烦的是它对硬盘供电不稳是硬盘早夭的隐形杀手。2.4 那几样别省的小东西第一个是UPS。我所在的小区一年跳闸两三次一次意外断电就够让阵列进入校验状态、跑上大半天。选一个能撑十分钟、带通讯接口的入门款配置成市电断开五分钟后自动关机这笔钱花得最值。第二个是温度监控。硬盘长期高于 50 度会明显缩短寿命我的目标是让所有盘稳定在 35~45 度之间。为此我在盘位前面加了一个低速风扇实测降了 6 度。第三个是标签。听起来很土但我给每块盘贴了编号、容量、购买日期机器里也做了对应记录。后来换盘的时候这个习惯帮我避免了一次拔错盘的险情。3. 存储底座盘怎么组、目录怎么摆3.1 三种组盘方式的取舍我为什么选了校验盘组盘方式的本质是在“容量、冗余、速度、折腾程度”之间选组合。单盘最简单容量全给但一块盘坏就是全部结束。镜像最稳两两成对任何一块坏了数据都还在代价是可用容量砍半。校验盘方案是拿一块盘的容量存校验信息任意坏一块都能恢复可用容量是盘数减一乘以单盘容量。我最后选了四盘校验。理由是我的数据里绝大部分是“写完就不动”的照片和影片属于典型的顺序读写场景校验方案在写入时的额外开销对我影响很小而它的容量利用率明显高于镜像。代价是重建时间长——四块 4TB 的盘其中一块坏掉后插入新盘重建我在实际测试里跑了大约 11 个小时这期间如果第二块盘也出问题那就真的没辙了。所以选用校验方案有个硬性前提你必须接受“重建期间是脆弱窗口”并且这个窗口里不要再有别的折腾。我的做法是重建期间不写入新数据、不跑校验任务、不关机让它安安静静跑完。有些人喜欢在重建的时候顺便整理文件这是纯粹的冒险。3.2 文件系统怎么选以及“阵列不是备份”这句话文件系统我给的建议是只要你的系统支持带校验和快照的现代文件系统就用它。原因很朴素——机械盘会出现“静默损坏”就是数据读出来了但内容已经错了普通文件系统发现不了。带校验的文件系统在读取时会比对校验值一旦发现不对就报错你至少知道自己哪张照片坏了而不是几年后打开发现是一团花屏。不过相比文件系统我更想强调另一件事阵列解决的是“硬盘坏了”不是“数据没了”。误删、勒索加密、系统崩了把整个池带崩这几种情况阵列一点忙都帮不上误删还会同步到阵列的每一块盘上。所以从第一天起我就把备份单独当成一件事来处理第 6 章会详细讲三层备份。还有个小细节别把系统装在阵列里。系统盘单独用一块小固态阵列只放数据。这样万一系统崩了要重装或者你想换个系统试试数据池完全不受影响插上就能识别。这一点在折腾阶段救命。3.3 目录结构与账号权限的实际设计目录结构我是返工过一次的。第一版按“年份”分结果影片、照片、文档全混在一起找东西全靠记忆。第二版改成“按用途分用途内按时间分”用起来舒服多了。实际结构大概是这样/data ├── photo # 照片主库按 年/月 分层 │ ├── 2019 │ ├── 2020 │ └── 2024 ├── video # 家庭录像、剪辑素材 │ ├── raw # 原始素材只写不删 │ └── export # 成片 ├── media # 影音库交给媒体服务器刮削 │ ├── movie │ └── series ├── doc # 证件、票据、资料扫描件 ├── backup # 其他设备的备份落点 └── temp # 中转区定期清理权限上我犯了新手常犯的错一开始所有东西都用管理员账号跑方便是方便但容器里的应用一旦出问题改文件权限会把整棵树搅乱。后来的做法是建三个普通账号一个给家庭日常读写一个给媒体服务只读一个给备份任务只写。管理员账号只在配置的时候用平时不登录。容器部署时还要注意用户 ID 和组 ID 要跟宿主机对应上否则会出现“文件明明在应用就是没权限读”的经典问题——我第一次遇到时排查了两个小时最后发现就是 ID 不匹配。3.4 快照、校验和定时任务怎么排快照我用得比较克制照片和文档目录每天凌晨做一次保留 30 天影音库一周一次保留 4 次。快照占的空间没有想象中大因为它是增量的但如果你频繁写入大文件快照会很快膨胀所以保留策略要盯着点。数据校验任务我安排在每周日凌晨四块盘跑一遍大概要几个小时正好是没人用的时候。这个任务的用处是提前发现“读不出来的坏块”而不是等你要用的时候才发现。第一次跑完它给我报了一个文件校验失败虽然只是张无关紧要的截图但那一刻我确认这套机制是有效的。定时任务这块有个提醒任务失败一定要能通知到你。我第一版的任务只在日志里记一笔结果有次备份连续失败两周我都不知道。后来改成失败时发一封邮件到常用邮箱或者至少写一个显眼的标记文件第二天打开面板就能看见。4. 照片和影片入库光影猫真正天天用的部分4.1 照片入库的完整流程和元数据整理照片入库看着简单实际是整个项目里最耗心思的部分。我的流程分四步收集、去重、改名、归位。收集是把手机、相机、旧硬盘里的照片全部集中到中转区去重用按文件内容哈希比对的方式把重复文件挑出来我第一批 4 万多张照片里找出了 6000 多张重复改名不改变文件名本身而是把拍摄时间写进 EXIF 并把文件修改时间对齐拍摄时间这样后续按时间排序才不会乱归位是按年月把文件移动到对应目录。这里有个坑要重点说时区。有些相机和手机导出的照片EXIF 里没有记录时区或者记录的是当地时间但没有偏移量导入之后可能出现整批照片时间偏移几个小时的情况跨年拍摄的照片甚至会掉到错误的年份目录里。我的处理方式是先抽样看几张跨年夜的合影确认时间对不对再批量导入。第一次没检查结果一批元旦拍的照片全跑到上一年去了手动挪了半天。另一个坑是动态照片。手机拍的那种“一小段视频一张图”的格式实际是两个文件配对的备份和去重时必须当成一个整体不然会出现有图没视频、或者视频孤儿文件的情况。开源相册工具一般能识别但前提是你别在导入过程中把它们的文件名改乱。4.2 影音文件的命名规范和刮削媒体库能不能自动识别全看命名。我一开始把文件叫“旅行记录最终版.mp4”媒体服务器当然认不出来。后来统一成一套规则类型命名格式示例电影片名 (年份).扩展名某部电影 (2018).mkv剧集剧名/季目录/剧名 S01E02.扩展名某剧/Season 01/某剧 S01E02.mkv家庭录像日期_事件_地点20240612_生日_家里.mp4整套规则的核心就三条剧集必须有季和集的编号、电影必须有年份、家庭录像用日期开头。前两条是给自动识别用的第三条是给自己看的。我给自己拍的东西从来不让它进刮削目录因为一旦被误识别成某部影片封面和简介全是错的还很难改回来。刮削这一步需要能连上公开的元数据源才能拉到封面和简介如果网络环境拉不到就别硬等直接用本地图片命名成poster.jpg放在同目录下多数媒体服务器都认。我有一段时间刮削全失败以为是软件问题折腾了半天才发现是目录权限不对读不到文件。4.3 手机自动备份怎么落地手机备份是整个系统里使用频率最高的功能也是最能体现“搭了有没有用”的功能。我最终用的是“手机端自动上传 服务端按日期归档”的组合相册里新增的照片在连着家里网络、插着充电的时候自动上传到中转目录服务端再按年月归档。配置时要注意三件事。一是限定只在局域网内上传别用移动数据不然出门一趟流量就没了二是设置上传后不自动删除本地照片这个开关一旦打开一次误同步就可能把手机里的原图删干净三是定期检查上传队列我有一次出门玩了十天回来发现相册备份卡在一个大视频上后面的照片全排在它后面等于十天没备份。后来我把视频单独设了一个队列大文件出错也不影响照片。实测下来家里千兆网络手机上传能跑到 60~80MB/s一次补传 3000 张照片大约十几分钟。这个速度对我来说完全够用。4.4 播放端和转码的现实考量播放这块的痛点是格式和带宽。我的规则是局域网内的电视盒子能直连播放就直连别转码手机在外面看才启用转码。原因是转码很吃处理器一部片子转码可能占掉三成以上的算力两三个人同时看就顶不住了。实测数据直连播放一部 4K 片处理器占用不到 5%几乎全速走网络转码成 1080p 给手机看占用 30% 左右风扇开始转但还能接受。所以硬件解码单元的意义就在这里有它转码轻松没它全靠软件算会直接把整机拖垮。另外两个小经验字幕格式要提前确认有些字幕格式播放端不支持会显示成乱码需要转成通用格式音频编码也要看老设备可能不支持较新的音频格式表现是画面正常但没声音这时候只能靠服务端转码。5. 局域网里的日常和出门在外的访问5.1 固定地址和三种共享协议的取舍光影猫在家里必须有个固定地址不然每次重启后手机上的连接就失效了。做法是在路由器里给它绑定一个固定 IP或者在系统里配置静态地址二选一别两边都配容易冲突。共享协议我三种都用了各管一段协议主要用途优点注意SMB电脑、手机文件访问兼容性最好各平台都认权限配置容易出岔子注意账号映射NFS局域网内播放器直连传输效率高协议开销小客户端支持参差配置稍麻烦DLNA电视直接发现媒体库免配置打开就能看不支持字幕外挂不能精细控制我日常用得最多的是 SMB因为手机和电脑都能直接连拖文件最方便。电视看片走的是媒体服务器自己的协议不直接读文件。NFS 只在需要大文件高速传输的时候用比如把一整批素材拷到剪辑机上。有个细节要注意SMB 的账号体系是独立的跟系统账号不是一回事第一次配置的时候要单独建一遍否则会出现“系统里明明有这个用户就是连不上”的情况。5.2 远程访问的几条路和风险边界出门在外想看家里的照片是很多人的刚需。可行的路径大致有三条我把它们和风险一起列出来第一条是在家里的路由器上做端口映射配合 HTTPS 反向代理。这条路的优点是延迟低、速度取决于你家的上行带宽缺点是把服务直接暴露在公网上必须做好密码强度、登录失败锁定、只开放必要的端口。我在这里犯过一次错图省事把文件共享的默认端口直接映射出去扫描器几分钟就找上门了日志里全是登录尝试。后来我把默认端口换掉、只开放加密端口、并开启了失败次数封禁情况才好转。第二条是用路由器或厂商自带的远程访问服务。好处是配置简单不用自己管证书和端口代价是数据要走第三方中转速度受限于对方服务器而且你不太清楚它的安全策略。第三条是自建一条加密通道把家里的服务和外面连起来。技术门槛高一些需要一台额外的公网中转或者组网工具但可控性最好适合有折腾意愿的人。我的实际选择是第一条但做了三道防护只开放加密端口、强制强密码加二次验证、开启登录失败自动封禁。还有一条底线管理后台绝对不对公网开放需要管理时就老老实实在家里操作或者用加密通道连回去。5.3 账号、权限和访问记录账号上我采用了“一人一号”没有共用账号。家里每个人一个账号各自有独立的照片目录公共目录所有人可读。这样做的好处是万一某个账号出问题影响范围是局部的坏处是要多花十分钟管理。权限的核心原则是最小够用看片的应用只能读媒体目录备份任务只能写备份目录日常账号不能碰系统配置目录。我第一次配置时图省事给了全权限结果有一次某个应用配置出错把媒体目录里的目录结构改了一遍修复花了一整天。访问记录也值得开。它能告诉你三件重要的事谁在什么时候访问了什么、有没有异常的远程登录尝试、某个应用是不是在偷偷扫描整个目录。我通过日志发现过一个手机端应用反复读取整个照片库原来是我开了“智能分类”但没设限制后台一直在做重复索引。6. 跑了三个月故障排查、实测数据和维护清单6.1 一次磁盘告警的完整排查链路第三周的时候系统发来告警说某块盘的重分配扇区计数从 0 涨到了 8。这个属性代表盘片上有扇区已经被标记为坏并重定向到备用区从 0 变成 8 是个明确的信号这块盘开始出问题了。我的排查链路是这样的。第一步先看是不是误报确认告警的盘是阵列里的哪一块检查阵列当前状态是否正常、有没有降级确认数据还是完整的。第二步看增长趋势把这个属性的历史记录调出来如果是一夜之间从 0 跳到 8比慢慢从 0 涨到 8 更可疑。我这次是一周内涨上去的趋势明显。第三步排除环境因素检查这块盘的温度是不是比别的盘高一截检查数据线有没有松动、接口有没有氧化。我把它和相邻盘的数据线对调了一次观察了一天数值继续涨说明不是线的问题。第四步跑一次完整的盘面自检这个任务耗时长一块 4TB 盘跑了大概七个小时结果是发现了更多待重定向的扇区。第五步决策开始把数据从这个盘上迁走趁它还能读也趁阵列还在健康状态。整个过程中我做对的一件事是没有立刻拆盘走保修。如果先拔盘再找替换阵列会立刻降级那段时间就完全没有冗余了。正确顺序是先备好替换盘、确认新盘检测通过再执行替换和重建。顺便说个反过来的坑有些人看到参数有点变化就紧张立马重建结果新盘本身没检测好重建到一半又出问题越搞越乱。换盘这件事慢就是快。6.2 温度、噪声、功耗的实测数字跑满三个月我把实测数据整理了一下供参考项目空闲状态四盘同时读写满载转码整机功耗22~26W45~55W65~75W硬盘温度34~38℃40~44℃41~45℃环境噪声1米约 28dB约 40dB约 44dB处理器占用3~6%15~25%60~80%按空闲 25W、平均每天有 3 小时在读写算一年电费大概 130 元上下按 0.6 元每度估。这个成本比我之前想开就开、想关就关的工作站低太多了——那台机器光待机就 80W。噪声方面白天完全无感深夜安静的时候能听到硬盘寻道的轻微声响。我为此把机器从电视柜里挪到了柜子侧面通风更好声音也散得开。6.3 三层备份本机快照、离机副本、离线冷备这是我整个项目里最看重的部分。阵列只管硬盘坏备份才管数据丢。我的做法是三层层层递进第一层快照。照片和文档目录每天打一次快照保留 30 天。快照解决的是误删、误改、应用出错写坏文件这类问题恢复起来只要几秒钟代价只是少量磁盘空间。第二层离机副本。每周日凌晨把照片、文档、影音库的清单增量同步到另一台放在书房的小机器上。同步方向是单向的只从光影猫推过去反过来不行。这一层解决的是整机故障、系统崩溃、阵列被误操作毁掉的问题。同步用的是标准增量工具命令大致长这样# 单向增量同步删除的文件也同步过去但保留30天删除版本 rsync -a --delete --backup --backup-dir/backup/deleted/$(date %F) \ /data/photo/ /backup/photo/ # 排除临时目录和正在写入的缓存 rsync -a --delete \ --excludetemp/ --exclude*.tmp \ /data/doc/ /backup/doc/配合定时任务每周日凌晨两点跑# 每周日 02:00 执行同步输出写入日志 0 2 * * 0 /usr/local/bin/sync-to-backup.sh /var/log/backup.log 21 # 每天 03:00 检查日志里有没有 error 或 failed 0 3 * * * grep -iE error|failed /var/log/backup.log notify-me 备份异常第三层离线冷备。每季度一次把最核心的东西——照片原图、证件扫描件、家庭录像——拷到一块移动硬盘上拷完拔下来放在另一个房间的抽屉里。这一层解决的是“同步把错误也同步过去”这种最坏情况如果哪天中了加密类的东西同步任务会忠实地把被加密的文件覆盖到备份机上只有离线盘能救你。三层里最容易被跳过的是第三层因为它最土、最不酷。但我确实见过同步镜像把病毒文件一起同步过去、最后两边的数据全废的情况。离线的意义就在于它不在线。6.4 维护日历和后续升级的节奏我给光影猫排了一张简单的维护日历贴在机箱侧面频率事项耗时每周看一次系统告警和备份日志5 分钟每月检查硬盘健康属性、温度、剩余空间10 分钟每季度离线冷备份一次验证能否正常读取1 小时每半年更新一次系统更新前先打快照30 分钟每年模拟一次恢复从备份里找回某个文件1 小时最后那一项“模拟恢复”是我认为最有价值也最少人做的一件事。备份能不能用只有恢复过一次才知道。我第一次做模拟恢复时才发现备份目录里的权限和原目录不一致恢复回来之后应用打不开文件白折腾一场。修好之后我才真正敢说“我的数据是安全的”。升级这块我的原则是能在周末做的事不要在工作日晚上做。系统更新、驱动变更、阵列扩容这类操作留出至少半天时间并且更新前一定先打快照、确认备份是最新的。我有一次在工作日晚上随手更新结果新版本跟某个组件不兼容折腾到凌晨一点第二天顶着黑眼圈上班。个人在实际操作中的体会是这套东西真正的门槛不在硬件也不在技术而在“愿不愿意把它当成一件长期维护的事”。硬件买回来装好只花了一个周末真正让它变得好用的是后面三个月里不断调整目录、修权限、补备份、记数据的那些琐碎时间。如果你的照片也堆到了“手机提示空间不足”的程度别再买第五块移动硬盘了找一台安静的旧机器从写清楚自己的三个使用场景开始一步步把它变成你的光影猫就行。