Fider v0.38.2 故障排查与 FAQ

Fider v0.38.2 故障排查与 FAQ 实录：启动配置（缺env panic/28P01/PG不可达/端口冲突/ghcr denied/网络名规范化）、邮件登录（userExists/SMTP静默/BASE_URL/无密码/JWT 401）、数据库存储与升级回滚六域故障的现象→定位→根因→解决，全部实测回显。

FiderFider自托管运维DockerPostgreSQL邮件2026/11/01

Fider v0.38.2 故障排查与 FAQ

目标：为 Fider v0.38.2 实例提供「按故障域组织、每条现象→定位→根因→解决」的排错手册，覆盖启动配置、邮件登录、数据库存储、升级回滚四大故障域与 FAQ 速查。本文全部报错与回显均在运行环境实测注入复现（取证日期 2026-11-01）：故障注入一律使用一次性容器或旁路库 fider_restore，未影响主栈服务。部署与日常操作基线见 《Fider v0.38.2 Docker Compose 部署指南》 与 《Fider v0.38.2 日常运维手册》。

一、环境信息

  • 操作系统：Ubuntu 22.04 LTS（x86_64）；Docker Compose v5.6.1
  • Fider：getfider/fider:v0.38.2（容器 fider-v0.38.2-server，版本横幅实测 v0.38.2-e492af4a30db30c104df3dfb9e0f04e55757ba9e，对外端口 8140，容器内监听 3000）
  • PostgreSQL：postgres:17（容器 fider-v0.38.2-db，实测服务端 PostgreSQL 17.11，数据目录 bind mount /opt/fider/pg_data，栈内主机名 db、网络地址 10.89.60.2）
  • 试用 SMTP：mailhog/mailhog（容器 fider-v0.38.2-mailhog，UI 端口 8142，收件端口 1025）
  • 站点：单租户 quzuo（tenants 表实测 subdomain=default）；管理员 root@quzuo.net；数据库口令 q1w2e3r4
  • 排错实验资源：旁路库 fider_restore（恢复演练产物，保留作故障注入靶库）、一次性测试容器（用毕即 docker rm -f）、管理员会话 Cookie /opt/fider/cookies.txt

二、排错方法论与工具箱

Fider 的故障九成暴露在三个面上：进程（起不来/重启循环）、邮件（登录链路断裂）、数据（迁移与库连接）。排查按 L1 存活 → L2 日志 → L3 配置 → L4 数据面逐层收敛，以下工具全部实测可用。

2.1 L1 存活：ping 与 /_health

docker exec fider-v0.38.2-server /app/fider ping; echo "ping_exit=$?"
curl -s -w "\nHTTP %{http_code}\n" http://192.168.1.172:8140/_health

实测回显：

ping_exit=0
{"status":"Healthy"}
HTTP 200

判读：ping_exit=0 即应用进程与 HTTP 层活着；非 0 或 HTTP 000 先查容器状态（docker compose ps），再按第三章启动类故障定位。注意 /_health 只证明 Web 层就绪，不代表数据库连接正常——启动期它甚至可能压根没起来（migrate 先于 http server，见 3.2/3.3）。

2.2 L2 日志：stdout 与 logs 表双通道

第一通道，容器标准输出：

docker logs --tail 4 fider-v0.38.2-server 2>&1

实测回显（节选）：

INFO [2026-11-01T12:40:55Z] [WEB] GET http://192.168.1.172:8140/api/v1/posts started
INFO [2026-11-01T12:40:55Z] [WEB] GET http://192.168.1.172:8140/api/v1/posts finished with 200 in 7ms (committed)
INFO [2026-11-01T12:40:55Z] [WEB] GET http://192.168.1.172:8140/ started
INFO [2026-11-01T12:40:55Z] [WEB] GET http://192.168.1.172:8140/ finished with 200 in 8ms (committed)

第二通道，logs 表（Fider 把运行日志同步写库，容器被删后仍可追溯）：

docker exec fider-v0.38.2-db psql -U fider -d fider -tc "select count(*) from logs;" -tc "select count(*) from logs where level='ERROR';" -tc "select count(*) from logs where created_at < now() - interval '30 days';"

实测回显：

   171

     0

     0

判读：当前 171 条、ERROR 为 0。日志标签含义：[WEB] 请求处理、[MIGRATE] 启动迁移、[BGW] 后台任务（邮件发送等，静默故障的踪迹常在这里，见 4.2）。

2.3 L3 配置：运行时环境变量盘点

Fider 只在启动时读取配置，排错时先核对容器实际生效的 env，而不是 compose 文件写了什么：

docker inspect fider-v0.38.2-server --format '{{range .Config.Env}}{{println .}}{{end}}' | grep -E '^(BASE_URL|DATABASE_URL|JWT_SECRET|EMAIL_)' | sed 's/=.*//' | sort

实测回显（变量名，值略）：

BASE_URL
DATABASE_URL
EMAIL_NOREPLY
EMAIL_SMTP_HOST
EMAIL_SMTP_PORT
JWT_SECRET

判读：六个变量就是 SMTP 邮件方案下的必填全集（3.1 详解缺变量的后果）。BASE_URL 与用户实际访问地址是否一致、DATABASE_URL 口令与库侧是否一致，是两类高频根因（4.3、3.2）。

2.4 L4 数据面：迁移版本与业务计数

docker exec fider-v0.38.2-db psql -U fider -d fider -tc "select count(*) as mig_count, max(version) as last_mig from migrations_history;" -tc "select (select count(*) from tenants) t, (select count(*) from users) u, (select count(*) from posts) p, (select count(*) from comments) c, (select count(*) from post_votes) pv, (select count(*) from blobs) b;"

实测回显：

        95 | 202606121200

 1 | 1 | 1 | 0 | 1 | 0

判读：migrations_history 的行数/最高版本是判断"库处于哪个 schema 代际"的唯一权威（v0.38.2 为 95 条、最高 202606121200）；升级、回滚、恢复演练后都回来查这一行对账（第六章）。

三、启动与配置类故障

本章六个场景全部用一次性容器/临时改动实测注入，报错回显为真实输出。

3.1 缺必填环境变量：配置解析阶段 panic

现象：容器起不来或秒退，日志只有一段 Go panic，没有任何 [WEB] 行。实测省略 JWT_SECRET 启动：

docker run --rm --entrypoint /app/fider getfider/fider:v0.38.2 --help

实测回显（输出节选，实测首尾）：

panic: Error Trace: 
	- failed to parse environment variables (app/pkg/env/env.go:170)
	- the environment variable "JWT_SECRET" is missing

goroutine 1 [running]:
github.com/getfider/fider/app/pkg/env.Reload()
	/server/app/pkg/env/env.go:170 +0x3a5
github.com/getfider/fider/app/pkg/env.init.0()

定位与根因：Fider 的环境变量校验发生在包初始化阶段，先于命令行解析——所以连 --help 都会 panic（3.1 实测命令即是证明：--help 未执行、进程先崩）。校验是逐层的：补齐 JWT_SECRET 后报 EMAIL_NOREPLY is missing，再补报 DATABASE_URL，SMTP 方案最后报：

panic: could not find environment variable named 'EMAIL_SMTP_HOST'

解决：按 2.3 的六个变量补齐后重建容器。判据：日志出现 http server started on :3000 即通过（2.1 的 ping 退出码 0）。

3.2 口令不一致（28P01）：应用重启循环

现象：docker compose ps 里 app 的 STATUS 反复显示 Restarting，日志反复刷同一段：

INFO [2026-11-01T12:18:16Z] [MIGRATE] Running migrations...
ERROR [2026-11-01T12:18:16Z] [MIGRATE] Error Trace: 
- failed to get last migration record (app/pkg/dbx/migrate.go:57)
- pq: password authentication failed for user "fider" (28P01)

定位：SQLSTATE 28P01 是 PostgreSQL 服务端明确拒绝口令——网络是通的（否则会像 3.3 那样 connection refused），错在凭据。对比两侧：app 的 DATABASE_URL 中 fider: 与 @ 之间的口令串（2.3 方法提取），与 db 容器 POSTGRES_PASSWORD 或库内实际口令是否一致。

根因两类：其一，compose 里两处口令手写不一致；其二，pg_data 早已用旧口令初始化过、后来只改了 POSTGRES_PASSWORD 环境变量——该变量只在首次 initdb 时生效（详见 5.2）。

解决：统一口令后 docker compose up -d app 重建；若属第二类，需进库 ALTER USER（5.2 实测流程与回显）。验证：docker exec fider-v0.38.2-server /app/fider ping; echo $? 回 0。

3.3 数据库不可达：connection refused

现象：与 3.2 同为 [MIGRATE] 报错、同栈帧 migrate.go:57，但第二行不同。实测把 DATABASE_URL 端口改成 PG 未监听的 5499 后一次性启动（连接串从运行中 app 容器运行时提取、仅替换端口，避免口令落进 shell 历史）：

DBURL=$(docker inspect fider-v0.38.2-server --format '{{range .Config.Env}}{{println .}}{{end}}' | sed -n 's/^DATABASE_URL=//p' | sed 's|:5432|:5499|')
JWT=$(docker inspect fider-v0.38.2-server --format '{{range .Config.Env}}{{println .}}{{end}}' | sed -n 's/^JWT_SECRET=//p')
docker run --rm --network fider-v0382-stack_fider-net \
  -e BASE_URL="http://192.168.1.172:8150" -e DATABASE_URL="$DBURL" -e JWT_SECRET="$JWT" \
  -e EMAIL_NOREPLY="noreply@quzuo.net" -e EMAIL_SMTP_HOST="mailhog" -e EMAIL_SMTP_PORT="1025" \
  --entrypoint /bin/sh getfider/fider:v0.38.2 -c "./fider migrate"

实测回显：

INFO [2026-11-01T14:17:59Z] [MIGRATE] Running migrations...
INFO [2026-11-01T14:17:59Z] [MIGRATE] Found total of 95 migration files.
ERROR [2026-11-01T14:17:59Z] [MIGRATE] Error Trace: 
- failed to get last migration record (app/pkg/dbx/migrate.go:57)
- dial tcp 10.89.60.2:5499: connect: connection refused

定位与解决：dial tcp <IP>:<port> 直接暴露了 Fider 解析出的目标地址——10.89.60.2 说明主机名 db 解析正常，错在端口/进程。依次核对：db 容器是否 Up（docker compose ps）、DATABASE_URL 端口是否 5432、app 与 db 是否同网络（3.6）。若 db 只是启动慢，官方裸 compose 靠 restart: always 重试自愈；部署篇推荐的 healthcheck + depends_on: condition: service_healthy 从根上消除该窗口。

3.4 宿主端口被占：port is already allocated

现象：docker run/docker compose up 直接失败，Fider 日志一行都没有（容器根本没创建成功）：

docker: Error response from daemon: failed to set up container networking: driver failed programming external connectivity on endpoint nifty_gould (341d3a0f19fa3f56180b446a1d2220a4352a5c7b06ba90eceaf907944005a2cd): Bind for 0.0.0.0:8140 failed: port is already allocated

定位：ss -ltn | grep 8140 看占用者；本实验环境实测宿主上 8141/8143/8145/8147 均被其他服务占用（curl 探测返回 Apache 默认 404 页），选端口要提前探测而不是撞了再换。

解决：换空闲端口映射并同步改 BASE_URL（两者不一致会造成 4.3 的邮件链接故障）。实测换 8150 后服务正常：

curl -s -o /dev/null -w "HTTP %{http_code}\n" http://192.168.1.172:8150/api/v1/posts

HTTP 200

3.5 拉取 ghcr.io 镜像报 denied

现象：docker pull ghcr.io/getfider/fider:stable 返回 error from registry: denied。

根因：Fider 官方镜像只发布在 Docker Hub（getfider/fider），ghcr 路径的仓库未公开，denied 是注册表对匿名拉取未公开仓库的标准响应，不是网络故障。

解决：docker pull getfider/fider:v0.38.2（本文环境实测成功）。若 Docker Hub 直连受阻，优先配置国内镜像加速，而不是改试 ghcr（部署篇第二章镜像选型有实测说明）。

3.6 compose 网络名规范化：network not found

现象：给旁路工具容器挂进 compose 网络时报错：

docker: Error response from daemon: failed to set up container networking: network fider-v0.38.2-stack_fider-net not found

根因：compose 项目名/网络名中的小数点会被规范化剥离。本项目声明的网络实名实测：

docker network ls --format '{{.Name}}' | grep -i fider

fider-v0382-stack_fider-net

解决：--network 一律用实名 fider-v0382-stack_fider-net（本文 3.3/6.2 等所有一次性容器实测均用此名）。最稳的写法是在 compose 里显式 networks.default.name 钉死实名并避免小数点。

四、邮件与登录类故障

Fider v0.38.2 的认证完全建立在邮件链路上（4.4），这一域的故障特征是接口不报错、错误沉在后台。

4.1 收不到邮件第一步：看 userExists

现象：用户在 /signin 输入邮箱说没收到邮件，界面却无任何报错。

定位：登录接口对"邮箱未注册"与"已注册"返回不同 JSON，先复现请求看返回：

curl -s -w "\nHTTP %{http_code}\n" -X POST http://192.168.1.172:8140/_api/signin -H 'Content-Type: application/json' -d '{"email":"nobody@invalid.test"}'
curl -s -w "\nHTTP %{http_code}\n" -X POST http://192.168.1.172:8140/_api/signin -H 'Content-Type: application/json' -d '{"email":"root@quzuo.net"}'

实测回显：

{"userExists":false}
HTTP 200
{"userExists":true}
HTTP 200

结论：userExists:false 时 Fider 根本不会发信（防用户枚举的设计），HTTP 仍是 200。"收不到邮件"先分清：邮箱没注册（让用户先走 /signup 或站内邀请），还是注册了但发送失败（4.2）。

4.2 SMTP 不可达：界面无报错、日志有痕

现象（实测注入）：一次性实例把 EMAIL_SMTP_HOST 指向不存在的域名 smtp.invalid.test，对已注册用户 root@quzuo.net 发起登录：

{"userExists":true}
HTTP 200

Web 层日志甚至显示请求完美收尾：

INFO [2026-11-01T14:17:34Z] [WEB] POST http://192.168.1.172:8148/_api/signin finished with 200 in 1ms (committed)

但 MailHog 计数 30 秒后纹丝不动（total: 4），用户永远收不到信。

定位：错误只出现在后台 worker（[BGW]）日志里：

docker logs fider-smtp2 2>&1 | grep -aA2 "failed to send email"

实测回显（输出节选，实测首尾）：

- failed to send email with template signin_email (app/services/email/smtp/smtp.go:105)
- dial tcp: lookup smtp.invalid.test on 127.0.0.11:53: no such host
INFO [2026-11-01T14:28:09Z] [BGW] Task 'Send sign in email' finished in 105ms (panicked)

根因与解决：发信是异步后台任务，失败不回传 HTTP 响应——这是 Fider 邮件排错最大的坑。SMTP 主机名解析失败（no such host）按 3.6/部署篇 4.4 核对主机名与网络；连接被拒/超时查 EMAIL_SMTP_PORT 与防火墙。修复后让用户在登录页重新触发即可，无需其他数据操作。

⚠️ 监控建议：把 grep "failed to send email" 或 logs 表 select count(*) from logs where level='ERROR'（2.2 实测当前为 0）纳入告警，别等用户投诉才发现邮件断链。

4.3 邮件链接域名与实际访问不符：BASE_URL 机制

现象：用户点邮件里的链接打不开，或跳到了另一个地址/另一个实例。

实测机制：邮件链接在发送时刻由该发送实例的 BASE_URL 拼装，不存库、不随后续改动回填。实测两个实例对照：

  • 主实例（BASE_URL=http://192.168.1.172:8140）发出的登录邮件，链接实测为 http://192.168.1.172:8140/signin/verify?k=YsK6bz7Fhnp51wMljnjdP2OddaE1HmlDpVUQYQwHlUkCBg91bke09mdZy21DOuSN；
  • 一次性实例把 BASE_URL 设为 http://feedback.example.com，对同一注册用户发起登录后 MailHog 收到的最新邮件，链接实测为：
http://feedback.example.com/signin/verify?k=txOhW8laeXq3Jeh5EDiP6Gn9KkG4JOqZvZb9KLNcLh954X54bu0nTkSpbsyZDUIt

结论：BASE_URL 改动会立即反映在此后发出的邮件上（并不存在"固化"问题），但已发出的旧邮件链接不会更新——换域名/换端口后旧邮件全员失效属预期，让用户重新发起登录即可。排错时对照三处一致：compose 的 BASE_URL = 反向代理对外地址 = 用户浏览器实际地址栏前缀，任何一处不一致都会在邮件链接上暴露。

4.4 找不到"忘记密码"：v0.38.2 没有本地密码

现象：新运维想找密码重置入口，或按其他系统的习惯去库里翻密码列。

实测：users 表全部列如下，没有 password 列：

docker exec fider-v0.38.2-db psql -U fider -d fider -tc "select string_agg(column_name, ', ' order by ordinal_position) from information_schema.columns where table_name='users';"

 id, name, email, created_at, tenant_id, role, status, api_key, api_key_date, avatar_type, avatar_bkey, email_supressed_at, is_trusted, security_stamp

结论：Fider 登录只有邮件魔法链接/一次性 code（实测邮件主题 Your sign in code for quzuo is 203796）与 OAuth 两类，没有本地密码体系。运维含义：SMTP 通道就是认证生命线（4.2 的静默故障等于"全站登录瘫痪但监控全绿"）；接管管理员身份 = 控制管理员邮箱。

4.5 更换 JWT_SECRET 后全员 401

现象：升级或整改安全配置时换了 JWT_SECRET，此后老会话调写接口全部被拒。实测用主实例签发的管理员 Cookie，请求一个换了另一把随机密钥的一次性实例（同库 fider_restore）：

curl -s -b /opt/fider/cookies.txt -X POST http://192.168.1.172:8150/api/v1/posts \
  -H 'Content-Type: application/json' \
  -d '{"title":"jwt-mismatch-probe","description":"probe","tags":[]}' -w "\nHTTP %{http_code}\n"

实测回显：

{}
HTTP 401

匿名读接口不受影响（实测 GET /api/v1/posts 返回 HTTP 200）。

定位与结论：会话 Cookie 由 JWT_SECRET 签名，换密钥后旧签名验不过 → 写操作 401。这不是数据损坏，让用户重新走邮件登录即可；但换密钥前应有预期：全员强制登出。若只是单实例换了密钥而多实例共享库，务必保证所有实例 JWT_SECRET 一致，否则负载均衡下用户会在"能登/401"之间随机漂移。

五、数据库与存储类故障

5.1 查 votes 表报 relation "votes" does not exist

现象：按直觉统计投票数：

docker exec fider-v0.38.2-db psql -U fider -d fider -c "select count(*) from votes;"

实测回显：

ERROR:  relation "votes" does not exist
LINE 1: select count(*) from votes;

根因与解决：投票表实名 post_votes（2.4 实测计数即用它）。写报表/巡检 SQL 前先 \dt 核对表名，24 张表里易踩的还有 comments/post_tags/blobs 这类复数命名。

5.2 改 POSTGRES_PASSWORD 不生效：pg_data 已初始化

现象：compose 里把 POSTGRES_PASSWORD 改成新值、重建容器后，app 仍报 3.2 的 28P01。

根因：postgres 官方镜像的 POSTGRES_PASSWORD 只在数据目录首次 initdb 时创建角色生效；/opt/fider/pg_data 已有数据时该变量被完全忽略，库内口令还是旧的。

解决（实测流程）：进库直接改角色口令——

docker exec fider-v0.38.2-db psql -U fider -d postgres -c "ALTER USER fider WITH PASSWORD 'q1w2e3r4';"

实测回显：

ALTER ROLE

然后把 compose 中 POSTGRES_PASSWORD 与 app 的 DATABASE_URL 口令同步为该值，docker compose up -d app 重建。验证：库内口令散列可查（实测 pg_authid.rolpassword 以 SCRAM-SHA-256$4096: 开头，PG 17 默认 SCRAM 加密），再从 app 侧跑一次 ./fider migrate（3.3 的一次性容器命令模板）确认认证通过。

5.3 附件去哪了：blobs 表与 BLOB_STORAGE

现象：用户上传了截图，在宿主 /opt/fider 下找不到任何图片文件。

根因：默认 BLOB_STORAGE=sql，附件以二进制行存进库内 blobs 表——实测本环境 blobs 计数 0（2.4 回显最后一列），宿主目录自然没有文件。备份必须走 pg_dump（运维手册第三章），只拷贝宿主目录会丢附件。

💡 技术拓展：Fider 文件存储三选一——sql（默认，附件进 PostgreSQL，备份一锅端，小站省心）、fs（落盘，需配 BLOB_STORAGE_FS_PATH 并挂载卷）、s3（S3 兼容对象存储，配 BLOB_STORAGE_S3_BUCKET/BLOB_STORAGE_S3_REGION/BLOB_STORAGE_S3_ENDPOINT_URL/BLOB_STORAGE_S3_ACCESS_KEY_ID/BLOB_STORAGE_S3_SECRET_ACCESS_KEY，变量名实测取自镜像内二进制）。本文环境用默认 sql；⚠️ 官方明示切换存储模式不迁移存量文件，开站初期就要定。

5.4 logs 表持续增长

现象：库大小随时间只增不减，pg_database_size 里相当比例是日志。

实测：2.2 查得 logs 表 171 条、30 天前 0 条（本环境新建不久）。该表无自动清理，长期运行需自行轮转，建议 SQL：

DELETE FROM logs WHERE created_at < now() - interval '30 days';

执行前用同条件 select count(*) 预估删除量（2.2 第三条实测命令即此用途），低峰执行。

六、升级与回滚类故障

6.1 stable 标签不是"最新正式版"

现象：把镜像从 v0.38.2 改成 stable 想"升到最新稳定版"，启动横幅却显示：

INFO [2026-11-01T14:13:08Z] [WEB] Version: dev-67c52826cca176724a59dd58b9795e1bc8d67bc8

根因：实测本地镜像清单——

docker images --format '{{.Repository}}:{{.Tag}} {{.ID}}' | grep getfider/fider

getfider/fider:v0.38.2 25d17db73c3d
getfider/fider:stable  eb95d0b4bf5d
getfider/fider:v0.38.1 904fde28e98a

stable 与 v0.38.2 摘要不同且横幅带 dev- 前缀：它是滚动 dev 构建，不是正式版的别名。

解决：生产升级以 GitHub Releases 的 vX.Y.Z 标签为准逐版钉住（运维手册 6.1 有完整升级三步），别把 stable 当升级目标。

6.2 降级"不报错"不等于能安全回滚

现象（实测注入）：把 v0.38.1 镜像跑在已被 v0.38.2/stable 迁移过的旁路库 fider_restore 上：

INFO [2026-11-01T14:14:30Z] [MIGRATE] Current version is 202606121200
INFO [2026-11-01T14:14:30Z] [MIGRATE] Migrations are already up to date.
INFO [2026-11-01T14:15:41Z] [WEB] Version: v0.38.1-938889b52707e900cc69f497ebd124dcf7aaf5ff
INFO [2026-11-01T14:15:41Z] [WEB] http server started on :3000
{"status":"Healthy"} HTTP 200

且用管理员 Cookie 发业务写请求（POST /api/v1/posts）实测返回 HTTP 200——旧版对这份新库读写完全正常。

根因与结论：migrate 只向前不向后，相邻版本（迁移文件同为 95 个时）schema 无差异，所以降级不报错。但一旦跨了含新增迁移的版本，新库里有旧版代码不认识的列/约束，旧版运行期 SQL 会随机报错——"这次能起"不代表"下次能用"。标准回滚方案永远是：compose 改回旧镜像标签 + 用升级前的 pg_dump 恢复数据库（运维手册 3.4 主库灾难恢复流程），而不是指望旧版兼容新库。回滚后按 2.4 对账 migrations_history 确认 schema 代际回到预期版本。

七、FAQ 速查

Q1：app 反复重启，docker compose ps 却看不出所以然？ restart: always 会把崩溃循环包装成"一直 Up"。直接 docker logs fider-v0.38.2-server 2>&1 | grep -m2 ERROR，按第二行区分三大根因：the environment variable "JWT_SECRET" is missing（3.1）、pq: password authentication failed for user "fider" (28P01)（3.2）、dial tcp 10.89.60.2:5499: connect: connection refused（3.3，端口/地址视现场而定）。

Q2：用户点邮件链接被弹回登录页/页面打不开？ 两类实测原因：链接域名与实际访问不符——发送时刻的 BASE_URL 决定链接，旧邮件不随改动回填（4.3）；或 JWT_SECRET 换过、会话整体失效（4.5）。都让用户重新发起登录拿新邮件即可。

Q3：接口 200、界面无报错，但用户就是收不到邮件？ 先看 /_api/signin 返回的 userExists（false 则压根不发，4.1），true 则查 [BGW] 日志里的 failed to send email with template signin_email 与 Task 'Send sign in email' finished in 105ms (panicked)（4.2）——Fider 发信失败是静默的，必须盯后台日志或 logs 表 ERROR。

Q4：管理员邮箱的人离职了，怎么接管站点？ v0.38.2 没有本地密码（4.4 实测 users 表无 password 列），身份完全绑定邮箱——接管 = 接管该邮箱的收信能力，或经现有管理员在站内变更成员邮箱后走新邮箱登录。

Q5：业务量统计用什么口径？ 用 2.4 的 psql 计数（注意投票表名 post_votes，5.1）。实测 METRICS_ENABLED 的 fider_posts_total 出现过"指标 0、库内实有 1 帖"（运维手册 4.2），指标口径与表行数不同步，只可看趋势不可当账本。

Q6：怎么确认升级/恢复后数据库处于正确代际？ select count(*), max(version) from migrations_history;（2.4 实测 v0.38.2 = 95 条 / 202606121200），与目标版本官方迁移文件数对账即可。

Q7：升级后发现新版有问题，直接改回旧镜像标签行不行？ 相邻同迁移数版本实测能起（6.2），但跨版本回滚不安全；标准做法是旧标签 + 升级前备份恢复（运维手册 3.4/6.3），升级前必做 pg_dump。

Q8：一次性容器挂不进主栈网络，报 network not found？ compose 网络名的小数点被规范化剥离，用实名 fider-v0382-stack_fider-net（3.6 实测），别用声明名 fider-v0.38.2-stack_fider-net。

八、参考链接

Fider v0.38.2 故障排查与 FAQ - Quzuo