前言
折腾了整整一天，从凌晨到深夜，我在群晖 DS423 上为蜜蜂记账搭自建同步服务，结果因为一开始走错了方向，绕了无数弯路，最后才发现官方文档里早就写好了最简单的方案。写这篇记录，既是复盘，也给同样想折腾的朋友避个坑。
一、初衷：摆脱 WebDAV 的同步冲突
之前一直是用 Excel 记账，用起来实在不方便，只能在开电脑的时候才能记。问了豆包，豆包推荐了蜜蜂记账，最初豆包推荐的是 WebDAV 模式，但家里两台手机、一台电脑同时记账，会出现文件覆盖、数据错乱的问题。
豆包再次推荐可以自建 Supabase 服务，实现数据库级别的同步，无冲突、无覆盖，我立刻心动了，想着一劳永逸解决问题。
二、被带偏的一天：从 “正确道路” 走到 “死胡同”
1. 第一步就选错了路
一开始我直接问了豆包，它给我的方案是：手动搭建 PostgreSQL + PostgREST，再在 APP 里用 “自定义 Supabase” 模式连接。
我没多想就照着做了：
- 写 docker-compose.yml，拉取 supabase/postgres 镜像
- 配置端口、密码、环境变量
- 启动服务，确认容器都健康运行
- 用 psql 命令建表、建索引、建 anon 角色
- 给角色授权、配置 JWT 密钥
- 重启服务、测试连接……
2. 踩坑踩得怀疑人生
从中午到傍晚，我一直在和各种报错死磕：
API Key无效：换了 N 次 JWT 密钥，从原始字符串到生成的令牌，全试过了认证失败：创建 anon 角色、给权限、改 PGRST_DB_ANON_ROLE，都没用服务器返回500：空 JWT 密钥导致 PostgREST 崩溃端口冲突：3000 端口被其他服务占用，改了又改目录不存在：数据卷没创建，启动失败- 甚至怀疑过轩辕镜像源，提交工单反馈镜像拉取问题，结果客服说 “Docker Hub 不存在该镜像”
中间我甚至一度想放弃，回到 WebDAV，但又不甘心，想着 “再试最后一次”。
三、真相：我完全走偏了，官方有现成的路
折腾到深夜，我翻回了蜜蜂记账的官方文档，一眼就看到了《BeeCount Cloud 自建云》这篇文章。
原来，APP 里的 “云服务” 界面，除了 WebDAV 和自定义 Supabase，还有一个专门的【BeeCount 自建云】模式！
官方早就提供了专门的一体化镜像 tntthink/beecount-cloud，一键部署，内置数据库和适配 API，完全不用自己搭 PostgreSQL 和 PostgREST，也不用管什么 JWT、anon 角色、权限授权。
我之前做的所有操作，全是在绕远路，甚至是死路 —— 手动搭的通用 Supabase 服务，和 APP 的自建云模式根本不兼容，怎么改都不可能成功。
四、正确方案：10 分钟搞定官方自建云
1. 清空之前的错误配置
cd /volume2/docker/beecount
docker-compose down -v
rm -rf docker-compose.yml compose.yaml ./db2. 创建数据目录
mkdir -p /volume2/docker/beecount/data
3. 官方标准 docker-compose.yml
services:
beecount-cloud:
image: sunxiao0721/beecount-cloud:latest
restart: unless-stopped
ports:
- "8869:8080"
environment:
BOOTSTRAP_ADMIN_EMAIL: 邮箱
BOOTSTRAP_ADMIN_PASSWORD: 密码
volumes:
- ./data:/data
4. 启动服务
docker-compose up -d
5. APP 配置（直接成功）
web 端：http://192.168.1.***:****
打开蜜蜂记账 → 个人中心 → 云服务 → 选择【BeeCount 自建云】：
- 服务器地址：
http://192.168.1.***:**** - 用户名和密码：yaml 中设置的邮箱和密码
点击测试连接，秒成功！没有任何报错，也不用管什么 API Key、认证、权限。
6、设置外网访问
安装了蜜蜂记账，在内网可以正常访问，但是使用域名无法连接网站。还是问了豆包，才想到还要设置路由器的端口转发。
登录TP-Link AC 的路由器管理界面，在”虚拟服务器” 选项中将 8869转发规则配置上。搞定！
五、复盘：为什么会白折腾？
- 一开始就选错了方案：没先看官方文档，直接信了 AI 的 “通用方案”，而通用方案和 APP 原生不兼容
- AI 的局限性：它只给了 “能跑起来的技术方案”，但没考虑到 APP 的适配限制，也没提醒我有更简单的官方方案
- 盲目试错浪费时间：在错误的方向上不断修改、调试，越陷越深，最后才发现从一开始就错了
六、给后来者的避坑建议
- 先看官方文档，再问 AI：很多 APP 都有专门的自建云方案，不要直接上通用方案
- 不要盲目死磕报错：如果一个错误反复出现，先怀疑方向是不是错了，而不是一直改参数
- 简单的方案往往才是对的：一键部署的官方镜像，比手动拼接的通用服务靠谱得多
结语
折腾了一天，虽然走了弯路，但也搞懂了 PostgreSQL、PostgREST、JWT 认证这些东西，也算是没完全白忙活。
现在终于用上了稳定的自建云同步，再也不用怕数据冲突了。也提醒自己，以后折腾前，先看官方文档，再动手，别再犯 “盲信 AI” 的错误了。
