从 Claw Cloud Run 迁移 Casdoor：一次被迫重构后的数据初始化修复记录#

最近因为 Claw Cloud Run 服务不可用（停止维护/疑似跑路），我被迫将一套运行中的系统整体迁移到新的服务器实例。

其中最折腾的部分并不是部署环境，而是：

Casdoor 在 data initialization 阶段直接 panic 🚨

本文记录完整迁移过程，以及最终修复 ID 结构问题的关键方案。

一、背景：原系统运行在 Claw Cloud Run#

原架构如下：

Casdoor（认证中心）
PostgreSQL
API 服务
前端服务

全部运行在 Claw Cloud Run 容器环境中。

直到某天开始：

控制台无法访问
服务不可更新
容器异常重启

最终确认：平台不可用，只能迁移。

二、迁移目标：新实例部署 Casdoor#

https://casdoor.ai/zh/docs/deployment/data-initialization

在新服务器上重新部署 Casdoor，并按照官方 data initialization 方式导入数据：

1
./casdoor --init_data=true

导入 backup.json 后直接启动。

三、第一次 panic：ID 格式错误#

启动后直接报错：

1
panic: GetOwnerAndNameFromId() error, wrong token count for ID

错误 ID 示例：

1
user-model-built-in

问题本质：Casdoor 强制要求 ID 格式必须是：

1
owner/name

而当前数据只有：

1
name

缺少 owner 结构，导致解析失败。

四、第二次 panic：多层 ID 污染#

在修复后再次启动，又出现新的错误：

1
built-in/built-in/user-model-built-in

问题变成：

token 数量超过 2（非法 ID）

原因是错误替换导致 ID 变成三段结构：

1
built-in + built-in + name

五、最终正确结构（关键结论）#

最终发现 Casdoor 的设计必须拆成两个概念：

1. name（定义本体）#

1
"name": "user-model-built-in"

👉 永远保持不变，是唯一标识

2. model（引用路径）#

1
"model": "built-in/user-model-built-in"

👉 必须包含 owner 前缀

六、正确修复方案总结#

✔ 正确结构示例#

1
{
2
  "owner": "built-in",
3
  "name": "user-model-built-in",
4
  "model": "built-in/user-model-built-in"
5
}

七、结构理解图#

1
┌──────────────────────────────┐
2
│        Casdoor Object        │
3
├──────────────────────────────┤
4
│ name                         │
5
│   └── user-model-built-in    │
6
│                              │
7
│ model reference              │
8
│   └── built-in/user-model    │
9
└──────────────────────────────┘

八、为什么会踩这个坑#

Casdoor 内部解析逻辑非常严格：

1
strings.Split(id, "/")

要求：

必须只有一个 /
必须严格 owner/name

否则直接 panic（没有容错）。

九、迁移经验总结#

1. 不要直接字符串替换 ID#

容易造成：

双 owner
三段 ID
结构污染

2. name 和 model 必须分离理解#

name = 唯一标识
model = 引用路径

3. 官方初始化 ≠ 可直接生产使用#

不同版本 Casdoor 数据结构可能不兼容。

十、结语#

这次迁移的核心问题并不是服务器，而是：

对 Casdoor ID 结构理解不完整

Claw Cloud Run 的不可用只是导火索。真正的问题在于数据结构层级没有拆清楚。

如果以后再遇到类似 panic，可以优先检查一件事：

你的 ID，是不是仍停留在“字符串拼接阶段”，而不是结构化阶段。