Authing 部署故障复盘：garble 混淆 × GORM AutoMigrate

日期：2026-11-01 影响：authing 模块（端口 9007）生产环境无法启动，所有依赖 authing 的登录/鉴权链路不可用 修复提交：9f6068af 严重级别：高（核心认证服务完全不可用）

---

一、现象

生产部署（deploy.sh --all）后，9 个后端模块中 8 个正常启动，唯独 authing 反复崩溃退出。logs/app.log 持续刷同一行错误：

level=ERROR msg="failed to auto migrate"
  err="ERROR: column \"ny_pi_qv_obr_x\" of relation \"authing_user\" contains null values (SQLSTATE 23502)"

进程在 InitDB 阶段被 logger.Fatal 直接终止（authing/backend/pkg/pg/db.go:44），端口 9007 从未监听。前端 /authing/ 能返回 200（nginx 静态文件），但后端 API 全部不可达。

---

二、这段代码是怎么来的

2.1 引入背景

authing 模块于 2026-07-28 由提交 88f4eff0 一次性引入（"feat: add authing module with system management pages and cross-service auth integration"）。该提交同时新增了：

• authing 后端（10 张表的 DDL/DML、gRPC、Wire DI、中间件）
• authing 前端（8 个系统管理页面）
• 将 authing 集成进 gateway/bms/pms/tms/wms 的跨服务调用

pkg/pg/db.go 里的 AutoMigrate 就是这个提交里一次性写死的，从第一版就存在，后续从未改动过。

2.2 为什么当时会加 AutoMigrate

代码作者的意图是防御性兜底：DDL 负责建表，AutoMigrate 负责"万一 DDL 漏了字段或类型不一致，启动时自动补齐"。这是 GORM 项目里非常常见的写法（很多教程/脚手架都这么写），单看这一行没有任何问题，甚至显得"更健壮"。

但放在本仓库的具体语境下，这个"健壮"是伪健壮，原因有三：

1. 与仓库既有约定冲突。本仓库其余 9 个 Go 模块（gateway/ums/pms/studio/bms/wms/community/packing/synapse-foundation）的 pkg/pg/init.go 全部没有 AutoMigrate，schema 完全由 sql/ddl.sql 单一来源管理（AGENTS.md 明确："DDL in <module>/backend/sql/ddl.sql"）。authing 是唯一例外，且文件名都不同（db.go vs init.go），说明它是独立手写而非从模板复制，没有继承"无 AutoMigrate"的约定。

2. 只迁移了一张表。db.AutoMigrate(&model.AuthingUser{}) 只迁移 authing_user 一张表，其余 9 张表（authing_tenant、authing_app、各 rel 表、8 张共享基础表）都不在迁移范围内。也就是说这个 AutoMigrate 既不能保证 schema 完整（漏了 9 张表），又引入了一个不必要的失败点——收益为零，风险为正。

3. 与 garble 混淆构建不兼容。这是致命的。authing 的 Makefile 有 build-obf target（garble -literals -tiny -seed=random），而生产打包 deploy/build.sh:42-43 在 OBFUSCATE=1 时对所有 Go 模块统一走 build-obf。garble 会重命名/混淆 Go 符号，破坏 GORM 依赖的 reflect 反射（GORM 靠反射读取 struct 字段名、tag、类型来推断 schema）。反射结果错乱后，GORM 对 authing_user 的 schema 推断出错，在迁移过程中生成一个内部临时列 ny_pi_qv_obr_x 做 NULL 约束检查，撞上 SQLSTATE 23502。

2.3 为什么 CI 没拦住

这是最关键的流程漏洞。对比两条流水线：

流水线	触发	构建方式	是否启动服务
ci.yml（go-authing job）	push/PR	make build（非混淆）	否，只 build+vet+staticcheck
package.yml（生产打包）	手动	make build-obf（garble 混淆）	否，只打包

问题链条：

1. CI 用非混淆构建，生产用混淆构建——两者二进制行为不同。CI 里 make build 产出的 authing 二进制反射正常，AutoMigrate 能跑通，所以 CI 永远绿。但生产 package.yml 走 build-obf，混淆后反射错乱，AutoMigrate 才炸。CI 验证的根本不是生产要跑的那个二进制。
2. CI 不启动服务——即使 CI 用了混淆构建，它也只 make build + go vet + staticcheck，从不真正 ./authing 跑起来连数据库。AutoMigrate 的失败发生在运行时（连库后执行迁移），静态检查完全看不到。
3. 打包流水线也不冒烟——package.yml 构建完直接打 tarball 上传，没有任何"启动二进制 + 连测试库 + 验证端口"的冒烟步骤。混淆二进制的第一次真实运行直接发生在用户的生产服务器上。

换句话说：没有任何一道自动化关卡运行过"混淆后的 authing 二进制 + 真实 PostgreSQL"，而这个组合恰恰是唯一的故障触发条件。

2.4 为什么人工审核没发现

• 单看代码无错。AutoMigrate 是 GORM 惯用法，code review 时如果只审"这行代码对不对"，答案是"对"。它的问题在于与仓库约定（无 AutoMigrate）不一致 + 与构建方式（garble）不兼容，这两个都是跨文件的上下文，容易在逐行 review 中漏掉。
• 没有"约定一致性"检查。仓库没有 lint 规则或 CI 步骤检查"所有模块的 pkg/pg 是否遵循同一模式"。authing 作为唯一例外，没有触发任何告警。
• garble 与 ORM 的兼容性是隐性知识。"符号混淆会破坏依赖反射的库"这一点不在 AGENTS.md、不在 README、不在任何文档里。作者加 AutoMigrate 时大概率不知道生产会走 garble；review 的人也不知道。
• 本地开发用的是非混淆构建。开发者本地 make run（非混淆）跑 authing 一切正常，AutoMigrate 从不报错，所以这个 bug 在开发期完全隐形，只有生产混淆构建才暴露。

---

三、排查过程（为什么难查）

步骤	动作	结论
1	看进程/端口	authing DOWN，9007 未监听
2	看日志	只有 failed to auto migrate，stdout 无输出（错误只写 app.log）
3	查报错列 ny_pi_qv_obr_x	表里不存在这列（\d authing_user 无此列）→ 开始怀疑"脏列"
4	发现残留列 zxkawl_pzp 并 DROP	删后仍报同样错
5	重建整个 authing 库（DROP+CREATE+DDL+DML）	仍报同样错 → 排除脏数据/残留列
6	全仓搜 ny_pi_qv_obr_x / zxkawl_pzp	代码/DDL/DML 全部无此字符串
7	查 GORM 依赖	标准 gorm.io/gorm v1.31.1，无加密/混淆字段插件
8	对比其他 9 个模块	只有 authing 有 AutoMigrate，其余全靠 DDL
9	定位根因	garble 混淆破坏 GORM 反射 → AutoMigrate 内部临时列名错乱 → NULL 约束失败

排查被误导的根因：GORM 报错里的列名 ny_pi_qv_obr_x 是它运行时内部生成的随机临时列名（用于 schema diff），不是数据库真实列。这个随机名让前 4 步全部跑偏成"找脏列"，浪费了大量时间。遇到"报错列在表里不存在"应立即怀疑 ORM 内部行为，而非数据问题。

---

四、根因（一句话）

garble 混淆构建破坏了 GORM 的反射，使一个本就不该存在的运行时 AutoMigrate 在迁移 authing_user 时生成错乱的内部临时列并触发 NULL 约束失败，logger.Fatal 终止进程。

三个必要条件缺一不可：

1. 代码里有运行时 AutoMigrate（且与仓库约定不一致）
2. 生产走 garble 混淆构建（破坏反射）
3. logger.Fatal 让迁移失败直接杀死服务（无降级）

---

五、修复

authing/backend/pkg/pg/db.go（提交 9f6068af）：

// 删除
if err := db.AutoMigrate(&model.AuthingUser{}); err != nil {
    logger.Fatal("failed to auto migrate", "err", err)
}
// 删除未使用的 import "authing/internal/model"

schema 统一由 sql/ddl.sql 管理，与其余 9 个模块对齐。

附带修复（同提交）：dashboard（Rust）config.rs 的 Config::load() 原来用 unwrap_or_default() 静默吞掉所有错误（文件缺失/解析失败/字段缺失都返回空 Config → port: 0 → 崩溃且无明确报错），改为显式 anyhow 错误，便于定位。

---

六、改进项（防止复发）

P0 — 必须做

1. CI 构建方式对齐生产：ci.yml 的 Go 后端 job 改用 make build-obf（或至少加一个 job 用混淆构建），确保 CI 验证的二进制与生产一致。这是本次最直接的漏洞。
2. CI 加运行时冒烟测试：至少对 authing（或所有含 DB 的模块）加一步：启动二进制 + 连测试 PostgreSQL + 验证端口监听 + 打一个 health 接口。AutoMigrate 这类运行时故障只有跑起来才能暴露。
3. 打包流水线加冒烟：package.yml 构建后、上传前，对每个二进制做一次"启动 + 连库 + 端口检查"，混淆二进制的第一次真实运行不应发生在用户生产环境。

P1 — 应该做

4. 全仓库禁用运行时 AutoMigrate：加一条约定（写入 AGENTS.md）+ 一条 CI grep 检查（grep -r "AutoMigrate" */backend/ 应为空），schema 变更一律走 DDL + 迁移流程。
5. Fatal 降级为可恢复：InitDB 里非致命错误（如迁移失败）应 Error 日志 + 继续启动（表已由 DDL 建好），避免单点错误拖垮整个服务。连接失败才 Fatal。
6. 文档化 garble 与 ORM 的兼容性限制：在 AGENTS.md 的 Gotchas 里写明"garble 混淆会破坏依赖 reflect 的库（GORM 等），含 ORM 的服务需验证混淆后行为，或避免在混淆二进制里做反射敏感操作"。

P2 — 建议做

7. 统一 pkg/pg 模板：所有模块的 pkg/pg 应从同一模板生成（文件名、结构、行为一致），避免 authing 这种"独立手写产生例外"的情况。可考虑用 codegen 或复制脚本保证一致。
8. 关键错误同时输出 stdout：authing 错误只写 app.log 不写 stdout，nohup 的 *.log 是空的，排查时容易漏看。建议 logger.Fatal/Error 同时写 stdout，便于 nohup 捕获。
9. 本地开发也走混淆构建验证：开发者在合并前用 make build-obf + make run 跑一遍，确保混淆二进制本地也能启动，把"混淆后行为异常"这类问题拦在开发期。

---

七、时间线

时间	事件
2026-07-28	88f4eff0 引入 authing 模块，db.go 含 AutoMigrate，CI（非混淆）通过
2026-08	首次生产部署（旧包），authing 可能已存在此隐患（或当时未走 garble）
2026-11-01	重新部署（garble 混淆包），authing 启动即崩，ny_pi_qv_obr_x 报错
2026-11-01	排查：删列→重建库→搜代码→对比模块→定位 garble×GORM 反射
2026-11-01	9f6068af 移除 AutoMigrate + dashboard 配置防御，push
2026-11-01	重新打包部署，authing 恢复正常