前段时间看到一篇介绍 WeekToDo 改造版的文章，作者在开源项目基础上加入了 AI 生成待办、五级优先级、S3 云同步等功能。其中 S3 同步这个特性很吸引我——毕竟本地存储虽然安全，但换电脑数据迁移确实麻烦。

不过作者在文中提到，S3 同步支持 AWS S3、MinIO、Cloudflare R2、Backblaze B2 等主流服务。我手头正好没有这些现成的云存储账号能满足我的免费、国内访问顺畅的要求，就想着能不能自己搭一个 S3 兼容服务，既省钱又可控。

于是就有了这次从零到跑通的折腾经历。这篇文章记录了完整的踩坑过程和最终方案，希望能帮到有同样需求的朋友。

资源链接

AI版weektodo地址：https://github.com/xiuji008/weektodo
AI版weektodo的Demo地址：https://xiuji008.github.io/weektodo/
VaultS3下载地址：https://github.com/Kodiqa-Solutions/VaultS3/releases

为什么选择 VaultS3

在决定自建 S3 服务后，我对比了几个开源方案：

VaultS3 最吸引我的几点：

1. 资源占用极低：空闲时仅 17 MiB 内存，适合在 Windows 上长期后台运行
2. 单二进制部署：不依赖外部数据库，下载即用
3. 内置 Dashboard：有 Web 管理界面，方便创建存储桶、配置权限
4. 功能完整：支持 IAM、CORS、版本控制、加密等

虽然项目文档坦承这是"一个人的项目"，但对于个人同步场景来说，功能够用，而且它的数据格式是普通文件 + BoltDB 索引，迁移和备份都很简单。

部署 VaultS3

1、下载与启动
从 GitHub Releases 页面下载 Windows 版压缩包后，解压得到 vaults3-windows-amd64.exe。

启动命令如下：

powershell

$env:VAULTS3_ACCESS_KEY="myadmin"
$env:VAULTS3_SECRET_KEY="mysupersecret"
$env:VAULTS3_DATA_DIR="D:\Vaults3\data"
$env:VAULTS3_METADATA_DIR="D:\Vaults3\metadata"
./vaults3-windows-amd64.exe serve

这里有个关键坑点：元数据目录的环境变量是 VAULTS3_METADATA_DIR，而不是直觉上的 VAULTS3_META_DIR。我一开始用了后者，导致配置不生效，服务回退到默认的 ./metadata 路径，凭证也一直加载的是旧的。

2、注册为 Windows 服务
直接运行的话，PowerShell 窗口一关服务就停了。用 NSSM 注册为系统服务可以后台运行、开机自启：

powershell

.\nssm.exe install VaultS3 "D:\Vaults3\vaults3-windows-amd64.exe" serve
.\nssm.exe set VaultS3 AppDirectory "D:\Vaults3"
.\nssm.exe set VaultS3 AppEnvironmentExtra `
  VAULTS3_ACCESS_KEY=myadmin `
  VAULTS3_SECRET_KEY=mysupersecret `
  VAULTS3_DATA_DIR=D:\Vaults3\data `
  VAULTS3_METADATA_DIR=D:\Vaults3\metadata
.\nssm.exe start VaultS3

启动后访问 http://localhost:9000/dashboard/，用设置的密钥登录即可。

3、配置 WeekToDo 连接
在 VaultS3 中创建存储桶（比如 week2do），然后在 WeekToDo 的同步设置中填写：

点击测试连接——失败。

踩坑过程

1、第一轮排查：审计日志显示"用户为空"
查看 VaultS3 的审计日志，发现所有请求的"用户"列都是 -，结果全部是 Deny，状态码 403。

这说明请求到达了 VaultS3，但没有通过身份认证。我尝试了默认密钥、自定义密钥，都不行。

2、第二轮排查：CORS 预检请求被拒
打开浏览器开发者工具，在 Network 面板中看到了关键信息：

3、请求方法：OPTIONS

状态码：403 Forbidden

原来 WeekToDo 在浏览器中运行时，发起的是跨域请求。浏览器会先发送 OPTIONS 预检请求，询问服务器是否允许跨域。而 VaultS3 默认不允许任何跨域请求，所以预检直接被拒绝，真实的 PUT 请求根本没有机会发出。

这也解释了为什么审计日志中"用户为空"——因为 OPTIONS 请求本身就不携带认证信息。

解决方案：配置 CORS
在 VaultS3 存储桶的 CORS 配置中填入：


json

[
  {
    "allowed_origins": ["http://10.1.1.31:8088"],
    "allowed_methods": ["GET", "PUT", "POST", "DELETE", "HEAD", "OPTIONS"],
    "allowed_headers": ["*"],
    "max_age_seconds": 3600
  }
]

保存后再测试，连接成功。

完整 SOP 总结

1、部署流程
下载 VaultS3 Windows 二进制并解压

设置环境变量（注意 VAULTS3_METADATA_DIR 的正确拼写）

启动服务，访问 Dashboard 验证

2、创建存储桶

配置 CORS（浏览器端跨域请求的必配项）

创建 IAM 用户和密钥（推荐最小权限）

在 WeekToDo 中填写连接信息

3、测试连接

注意事项

1、CORS 是浏览器端 S3 客户端的必配项

WeekToDo 在浏览器中运行时，所有 S3 请求都是跨域请求。allowed_methods 必须包含 OPTIONS，allowed_origins 要填写实际的访问来源，不能随意用 *。

2、环境变量名要准确
元数据目录是 VAULTS3_METADATA_DIR，不是 VAULTS3_META_DIR。写错会导致配置不生效。

3、IAM 默认拒绝策略

VaultS3 的默认策略是 default-deny。即使密钥正确，如果该密钥没有对目标存储桶的显式授权，请求也会被拒绝。

4、审计日志是排查利器

用户列为空 → 认证未通过（密钥或 CORS 问题）

用户列有值但 Deny → 权限不足（IAM 策略问题）

5、浏览器开发者工具是定位问题的关键

按 F12 打开 Network 面板，观察请求方法（OPTIONS 还是 PUT）、状态码、响应头，能快速定位问题。

一些感触

这次折腾最大的收获是：CORS 这个看似不起眼的配置，往往是浏览器端 S3 客户端连接自建服务的最大障碍。

回过头看，整个排查过程其实并不复杂，但如果没有审计日志和浏览器开发者工具，很容易在"密钥不对"这个方向上打转。VaultS3 的审计日志记录了每个请求的用户、操作、资源和结果，配合浏览器的 Network 面板，基本能定位到所有连接问题。

另外，VaultS3 的文档里有一句话让我印象深刻："Your data is not locked in a format anyone has to reverse-engineer." 对象是磁盘上的普通文件，索引是 BoltDB 文件，迁移就是 rclone sync 或 aws s3 sync。这种开放的设计，对于自建存储来说是很重要的安心保障。

工具准备好了，剩下的就看执行力了。