盲信豆包害我白折腾一天：蜜蜂记账自建云踩坑全记录

前言

折腾了整整一天，从凌晨到深夜，我在群晖 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 ./db

2. 创建数据目录

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” 的错误了。

前言