起因：手机存储空间又开始让我焦虑了
最近突然有了一种预感：iPhone 的本地存储空间，可能很快就不够用了。
平时拍照、记录生活，偶尔拍点视频，时间久了，照片和视频就会慢慢积累起来。单张照片可能占不了多少空间，但数量多了以后，也是一笔不小的存储开销。
而且，手机里的照片有些是日常记录，有些是旅行照片，还有一些只是当时觉得值得拍下来，留着以后回看的瞬间。
直接删除，多少有点舍不得。
但如果一直留在手机里，存储空间又会越来越紧张。
于是我就开始琢磨：
能不能把照片同步到云端，既保留这些记录，又能逐步释放手机的本地存储空间？
最直接的办法当然是使用现成的云相册服务。不过，最近一直在折腾 Cloudflare，也经常在 GitHub 上找一些有意思的开源项目，所以这次就想着，能不能顺便自己搭一个适合个人使用的云端照片管理方案。
最好能够做到：
- iPhone 上的照片可以方便地上传到云端。
- 照片能够长期保存，也能随时查看。
- 尽可能保留原始图片信息，包括拍摄时间和地理位置。
- 对 iPhone 的实况照片有比较好的支持。
- 存储成本尽量低，后续有需要时还可以扩展。
听起来好像不复杂。
但真正开始寻找项目以后，我才发现，普通图片上传只是最基础的一环，想把它变成一个真正好用的个人照片库，还有不少事情需要考虑。
第一个目标：大名鼎鼎的 Immich
既然要管理手机照片，我首先想到的就是 Immich。
GitHub 项目地址： Immich
Immich 是一个开源的自托管照片与视频管理项目。它不仅能够上传、浏览和管理照片，还支持手机自动备份、相册管理、重复照片识别、EXIF 元数据、地图、照片搜索，以及实况照片等功能。
简单理解，它并不只是一个存放图片文件的地方，而是更接近一个由自己掌控的 Google Photos 式照片管理系统。
这就比较符合我的设想了。
我想解决的本来就不只是图片存储，而是希望把手机里的照片逐步转移到云端，平时能够查看，需要的时候也能找回来。
如果从完整度来看，Immich 确实很有吸引力。
不过，研究了一会儿，我就遇到了第一个现实问题：
它需要一套能够持续运行的服务器环境。
这个服务器可以放在家里，也可以部署在云端。问题在于，不管放在哪里，都需要考虑 CPU、内存、存储空间以及后续的维护。
Immich 官方目前给出的硬件要求是至少 6GB 内存，推荐 8GB；CPU 至少需要 2 核，推荐 4 核。生成缩略图和转码视频还可能让照片库的存储占用平均增加约 10%～20%。(官方硬件要求)
这对于有自己的家庭服务器、NAS 或者合适云服务器的人来说，并不是特别大的问题。
但我当时的想法是，最好先用免费的 Docker 环境尝试一下。
实际研究后发现，手头能够使用的免费环境，资源与我希望获得的体验并不匹配。
如果只是为了存储几张照片，就要专门准备一套服务器环境，还要考虑持续运行、磁盘空间、备份和维护，投入似乎有些不划算。
于是，Immich 的研究就暂时停在了这里。
不是项目不好，而是目前的需求还不足以让我专门为它准备一套服务器。
不过，我也没有完全放弃它。
如果以后有了合适的本地服务器，或者照片和视频的数量真的积累到一定规模，我还是非常愿意部署 Immich 体验一下的。
第二个目标：寻找 Cloudflare 方向的图床项目
Immich 暂时搁置后，我又开始和 AI 讨论：
有没有更轻量、能利用 Cloudflare、同时又适合个人使用的图床或相册项目？
这次找到了 Afilmory。
GitHub 项目地址： Afilmory
Afilmory 给我的第一感觉就不错。
它本身是一个面向摄影作品的照片图库项目，提供照片展示、瀑布流布局、EXIF 信息、GPS 地图、图片分享等功能，还支持多种存储来源，包括 S3 兼容存储、GitHub 和本地文件系统。
另外，它还具备 HEIC/HEIF 等格式的处理能力，以及 iPhone 实况照片的检测和展示功能。
也就是说，它既可以作为个人照片展示站，也能作为整理、浏览照片的一套工具。(Afilmory 项目说明)
这就让我有了一个新思路：
能不能利用 Cloudflare，把图片上传和展示的流程做得足够轻量？
例如，让访问端使用一个简单的网页，图片本身存放在 Cloudflare R2 这样的对象存储中。需要查看时，通过相册页面浏览；需要添加图片时，再从手机上传。
这样就不一定需要先准备一台一直开着的家庭服务器。
对于我这种主要想保存个人记录照片的人来说，这种思路似乎更合适。
当然，这里需要区分一下：Afilmory 本身并不是一个纯静态的上传页面，它也有后端服务、数据库等组成部分。如果采用 Cloudflare 静态页面加对象存储的轻量方案，就需要另外规划上传接口、身份验证和文件访问权限，不能简单地把页面部署上去就认为整套图床已经完成。
不过，Afilmory 的结构和存储适配方式比较灵活，确实值得研究。
于是，我开始尝试围绕这个方向做一些基础验证。
基础验证：方案能够跑通，但还没有真正部署完成
目前，这个项目已经完成了一些基础测试，验证结果是通过的。
也就是说，我想尝试的基本技术路线是可行的，并不是完全停留在设想阶段。
但这里需要说明：
基础测试通过，不代表完整的个人照片备份系统已经部署完成。
真正准备长期使用之前，还有几个问题没有解决。
1. 免费存储空间够不够？
首先就是存储容量。
我最初设想的是尽量利用免费资源，所以也研究了 Cloudflare 的存储方案。
这里主要考虑的是 R2 对象存储。根据 Cloudflare 当前公布的定价，R2 标准存储免费层包含每月 10 GB-month 的存储额度，以及一定数量的免费读写请求；互联网数据传出本身不收费。超出对应免费额度后，则需要按照实际使用量计费。
官方说明：
10GB 对于测试来说已经足够了。
但如果真的准备长期存储手机里的照片和视频，就需要重新考虑了。
尤其是实况照片，除了静态照片本身，还涉及配套的视频数据。再考虑原图、缩略图、后续拍摄的新照片，存储空间的增长速度可能会比我预想的快。
虽然可以通过清理、压缩或引入其他存储来调整，但这样又会带来新的工作。
所以，免费存储可以用于验证方案，却不一定足以支撑我长期保存全部照片的需求。
后续如果继续做，我更倾向于先找到一种成本可控、后续方便扩展的存储方式，而不是一开始就把所有照片都迁移过去。
2. iPhone 实况照片的上传，才是比较麻烦的部分
这其实是我目前最在意的问题之一。
普通照片上传并不难。
但我使用的是 iPhone，平时拍摄的内容里会有实况照片。
实况照片并不只是普通的静态图片，上传、保存和展示时，还需要考虑配套视频以及两者之间的关联。
Afilmory 本身支持实况照片的检测和展示，但这并不代表我已经完成了适合自己使用习惯的手机上传流程。
我真正想要的是：
从 iPhone 里选中照片，最好点几下就能上传；实况照片也能正常保存和查看，而不是每次都要手动处理一堆文件。
如果每次上传都要先导出照片、再找对应的视频，最后还要确认两者是否正确关联，那整个流程就会变得非常繁琐。
这与我最初希望“方便、快捷地给手机释放空间”的想法就背道而驰了。
所以，我开始考虑能不能通过 iOS 快捷指令来简化上传流程。
3. iOS 快捷指令：已经做了一半，后来停了下来
我目前的一个思路，是借助 iOS 快捷指令，把选择照片、处理文件和上传这几个步骤串起来。
理想情况下，平时拍完照片以后，只需要从快捷指令中选择需要处理的内容，就可以完成上传。
如果能够把普通照片和实况照片都处理好，整个体验应该会方便不少。
不过，这部分目前还只是半成品。
我根据 AI 给出的步骤，自己一点点尝试，确实完成了一部分，但后面遇到一些需要反复调试和验证的环节。
由于手头没有方便的 macOS 开发与调试环境，很多步骤只能按照 AI 给出的说明手动操作，整个过程相对麻烦。
再加上当时并没有迫切到非解决不可的程度，研究到一半以后，我也就暂时停了下来。
说到底，还是那句话：
有想法是一回事，真正把它打磨成每天都愿意使用的工具，又是另一回事。
如果以后有更合适的调试环境，或者确实有更强烈的需求，我还是愿意把这条快捷指令继续完善下去。
4. 图片的位置信息，也需要进一步验证
另一个需要考虑的问题，是图片元数据。
平时用 iPhone 拍照，除了照片本身，还可能记录拍摄时间、设备信息和 GPS 坐标。
我希望照片上传以后，至少能够尽可能保留自己需要的拍摄信息。
如果以后能够通过地图查看照片拍摄地点，那就更方便了。
Afilmory 已经具备 EXIF 信息展示和 GPS 地图功能，但我仍然需要验证自己的实际上传流程是否会完整保留相关信息。特别是经过快捷指令处理后，原始照片的元数据有没有被修改或丢失。
同时，这里还有一个隐私问题：
如果照片带有精确的 GPS 坐标，未来公开分享时，就需要考虑是否应该展示这些位置。
因此，图片位置信息不仅是一个功能问题，也是一个需要认真处理的隐私问题。
这部分目前也还没有完全验证完毕。
为什么现在还没有正式部署？
说了这么多，可能有人会觉得，既然已经找到了项目，基础测试也通过了，为什么不直接部署使用？
其实原因很简单。
目前的需求还没有强烈到值得我投入更多时间。
第一，免费存储容量有限，长期使用还需要考虑扩容或其他存储方案。
第二，iPhone 实况照片的上传流程还没有真正做到足够简单，快捷指令也只是半成品。
第三，图片的 GPS 信息是否完整保留、如何展示，以及公开分享时怎么处理隐私，都还需要继续验证。
第四，也是非常现实的一点：我目前真正需要保存的个人记录照片并没有多到无法管理的程度。
如果为了一个当前还没有那么迫切的需求，投入大量时间搭建上传接口、处理媒体格式、调试快捷指令，再额外维护一套服务，似乎没有必要。
对我来说，技术项目本身确实很好玩，但不是每个想法都需要马上做成一个完整产品。
有些项目完成基础验证，知道方案可行，就已经达到了当前阶段的目的。
以后需求变大了，再继续投入也不迟。
最终选择：目前先放着，未来还是更倾向 Immich
经过这一轮探索，我对两个项目的定位也更加清楚了。
Afilmory 更适合继续研究轻量化的照片展示与存储方案。
它的灵活性很有吸引力，可以围绕对象存储、图库页面和图片元数据做不少尝试。如果以后只是想做一个自己的照片展示站，或者搭建一个更轻量的图片整理入口，它仍然是一个值得折腾的项目。
Immich 则更接近我最终想要的完整照片管理系统。
如果未来我有了合适的本地服务器，或者愿意为这件事投入稳定的硬件资源，那么 Immich 的手机备份、实况照片、地图、搜索和相册管理等能力，会更贴合我长期保存个人照片的需求。
不过目前，我还没有专门部署家庭照片服务器的动力，手头的个人照片记录量也不足以让我必须马上完成迁移。
所以现阶段的结论就是：
- 基础测试：已通过。
- Cloudflare 轻量图床方案：仍在研究。
- iPhone 实况照片自动上传：尚未完成。
- 图片 GPS 元数据与隐私处理：仍需验证。
- 完整部署：暂缓。
- 未来的长期照片管理方向：更倾向 Immich。
如果以后继续推进，我还需要进一步考虑照片的备份策略。毕竟，云端有一份照片，并不一定意味着它已经得到了可靠的备份；对于真正重要的照片，还应该考虑额外的副本。
写在最后
这次项目探索，最有价值的地方，其实不只是找到了两个 GitHub 项目。
而是把一个原本很模糊的想法，逐渐拆成了几个具体的问题：
怎么上传？
存在哪里？
怎么保留实况照片？
怎么保存图片的拍摄地点？
怎么控制长期成本？
如何让整个过程足够简单，真正融入自己的日常使用？
这些问题并不算特别高深，但真正做起来以后，才会发现它们共同决定了一个工具到底好不好用。
目前，这个项目就先停留在基础验证通过、方案仍在研究的阶段。
等以后照片多起来了，或者有了更合适的服务器和调试环境，再继续把它完善。
毕竟，技术项目不一定非得一次做完。
先验证想法，再决定要不要继续投入，也是一种很实用的开发方式。
而 Cloudflare，确实还是挺香的。
