打造 Local-First 的图像档案：范围界定

Scoping a Local-First Image Archive

Source | HN Comments

文章探讨了构建“本地优先”图像档案的理念，旨在创建一个简单、持久、零依赖的图像管理工具。作者希望摆脱云端复杂系统，回归文件系统，将文件夹作为组织结构，纯文本文件存储元数据。该工具的核心目标是离线工作、不修改原始文件、不依赖服务器或数据库，并使用HTML、CSS和可选的JavaScript实现。作者计划使用Rust或Go重写原型，以实现更轻量级、更快速的本地应用。最终目标是提供一种简单的方式来浏览图像文件夹，不增加额外的复杂性。

打造 Local-First 的图像档案：范围界定

Mar 19, 2025

多年来，我一直在思考我们如何存储和访问我们的数字文件，特别是照片。一切都在朝着云端迁移，伴随着复杂的系统/应用，它们将本应简单的东西抽象化了：一个图像文件夹。

我不想要那样。

我想要一些简单的东西。不需要服务器，不依赖数据库，也不会把我锁定在任何特定的生态系统中。我想要仅仅能处理文件和文件夹的东西，可以明天就消失而不会留下任何痕迹，或者运行一次，结果就永远存在。

在使用 Node.js 粗略地完成了原型并看到了价值之后——这里是对我想要更好地构建它的原因的思路整理。

我的快速原型。一个图像档案查看器，可以通过点击一个 HTML 文件在浏览器中打开。

1. 大多数照片解决方案的问题 (Google Photos, iCloud Photos 等)

照片管理变得过于复杂，并且只专注于组织，而不是存档。我不是在贬低这些服务，它们对于管理你生活中的工作窗口照片非常棒，但我们真的希望 10 年、15 年、20 年前的照片存储在这些服务上吗？

一切都假设我们想要一个数据库、AI、同步以及 100 倍的功能。
大多数系统会重命名、排序或移动你的图像。
基于云的解决方案将你推向订阅模式和围墙花园（例如，Google Photos、iCloud Photos）。
如果你停止使用它们，你将丢失你的元数据、组织和编辑——最终得到一个混乱的、无组织的导出。

对于非技术人员（甚至对我自己来说），这并不理想。当你离开人世后，你的文件会发生什么？如果你的家人想在 10 年后浏览你的档案，他们能做到吗？

这应该是简单的。

一个结构良好的文件夹，无论是在几个外部驱动器上，还是在异地远程备份，都已经是一种很好的组织图像的方式。为什么要复杂化它？

2. 纯文本运动：文件为王

现在有一种回归纯文本的运动。笔记本、wiki、文档——人们正在抛弃数据库和专有格式，转而选择简单、可读的文件。

为什么？因为文件比应用更持久。

我希望图像也能采用同样的理念。文件系统应该是结构——而不是一些建立在其之上的抽象界面。

一个文件夹已经是一个集合。
一个纯文本文件 (meta.md) 可以存储可选的元数据，并且只需打开它就可以读取。
如果你移动或删除应用，任何东西都不会崩溃。

这不是关于重新发明轮子——而是关于从一开始就不把事情复杂化。

3. 本地优先、零依赖的图像档案

目标是一个工具，它：

✅ 完全离线工作——只需在浏览器中打开文件夹中的根 index.html 文件。
✅ 不需要服务器或数据库——纯粹的扁平文件。
✅ 永远不会修改或重命名文件——对你的图像、元数据和结构零风险。
✅ 不留下任何痕迹——如果你删除应用，或清除档案站点，你的所有内容都保持完整。
✅ 仅使用单个 CSS 文件进行样式设置——可定制，带有最小的默认值。

本质上，它只是一个图像文件夹的静态站点生成器，它存在于你的库中。你可以完全忽略它，仍然像往常一样访问你的照片，或者在你觉得需要时使用它。

4. 最小的 JavaScript (或完全没有)

默认情况下，它应该是纯 HTML 和 CSS，并且使用浏览器功能，而不是花哨的东西。JavaScript 应该是可选的——仅用于 UX 改进，例如：

一个更好的文件夹树 UI。
延迟加载大型图像。
小的可访问性增强。

如果禁用 JavaScript，任何东西都不应该崩溃。

5. 它的结构

文件夹组织

该项目没有使用数据库，而是使用文件系统作为数据库：

📂 Photos/
├── 📂 2024-Scotland-Trip/
│  ├── 🖼 image1.jpg
│  ├── 🖼 image2.png
│  ├── 📄 meta.md (可选元数据)
│  ├── 📂 .thumbs/ (自动生成的缩略图)
│  ├── 📜 index.html (自动生成的 UI)
│
├── 📂 2023-Italy/
│  ├── 🖼 photo.jpg
│  ├── 📄 meta.txt (纯文本元数据)
│  ├── 📂 .thumbs/ (自动生成的缩略图)
│  ├── 📜 index.html (自动生成的 UI)
│
├── 📜 style.css (全局样式)
├── 📜 index.html (根索引)

📂 Folders = 分类 📄 meta.md = 每个文件夹的可选元数据 📂 .thumbs/ = 系统隐藏的点文件夹，用于自动生成的缩略图，以帮助加快页面加载速度

没有数据库，没有外部依赖——只有文件。你可以构建它，把它放在一个 SSD 上，并在 10 年后拿起来，它仍然可以工作。

6. 它是如何工作的

一个小型的后台应用监视文件夹或手动触发。
当添加或删除文件时，它：
- 为每个文件夹生成一个 静态 HTML 索引。
- 创建 缩略图（但从不修改原始图像）。
- 使用 Markdown 或纯 txt 文件存储元数据。
在 浏览器 中打开文件夹以浏览图像。

没有复杂的设置，没有同步，没有额外的废话。

7. 为什么要远离 Node.js？

现在，我已经用一个 Node.js 脚本 进行了原型设计，它工作正常，但它 并不理想：

🚫 它很臃肿。
🚫 它需要 安装依赖项。
🚫 任何 UI 都可能依赖于 Electron。
🚫 它 不够轻量级，无法作为后台进程运行 (说的就是你，Electron)。

目标是用 Rust 或 Go 重建它，这将使它：

✅ 成为一个 单个、微小的可执行文件（约 5MB 或更少）。
✅ 快速且 低内存——在后台静默运行。
✅ 零依赖——只需打开应用，提供一个文件夹并运行。

Rust 会让它更快，而 Go 会让跨平台支持更简单。无论如何，目标是一个微小的、原生应用，它只做它的工作，然后退出。

8. 最后的想法：保持简单

这个项目是 有主见但简单的：

文件夹是王道——没有数据库，只有文件。
元数据是可选的——存储为可读的文本。
没有跟踪，没有云，没有膨胀。
删除应用不会留下任何痕迹。

它只是一个浏览图像文件夹的轻量级方式——不多也不少。

我将很快开始对 Rust 版本进行原型设计。如果这听起来很有趣，请告诉我。🚀