返回博客

元数据平台的 Schema 在运行时注册，grep repo 必然空手而归

接到任务：「给用户档案表加一个'学历层次'下拉字段，枚举从上游数据平台取。」我打开 IDE，熟练地开始 grep。

grep -rln "学历层次\|dict_education" data-platform/
# 啥也没有

换关键词，再试：

find data-platform/data/migrations -name "*dict*"
# 空
grep -rln "dict_" data-platform/src
# 空

整整找了二十分钟，repo 里没有任何 dict_* 表的痕迹。我开始怀疑是不是找错了仓库，于是把所有关联 repo 都翻了一遍——依然一无所获。

现象

在某个元数据驱动的内部数据平台（类似 Strapi / Directus 的低代码 admin 平台）里：

  • repo migrations 目录里只有 registry 自身的 schema（CREATE TABLE db_enum_registry ...），没有任何业务字典的建表语句
  • 调用方代码里拿枚举走的是 ?table=xxx 路径，xxx 在代码里是动态的，不是硬编码字符串
  • SWR key 形如 db:xxx，xxx 由配置驱动

根因

这类平台的元数据是 runtime artifact，不是 build-time artifact。

管理员通过平台页面（字典管理、内容类型编辑器等）点击「新建」，系统把字典表名、标签、展示类型等写进 db_enum_registry（或类似 registry 表）——这是一次数据库写操作，不会产生任何代码文件、migration 文件或 seed 文件。

所以：

管理员点「新建字典」
  → runtime DB 写入 db_enum_registry
  → 平台 API 动态响应 ?table=dict_xxx
  → 前端消费组件用 tableName 参数拉数据

❌ 不产生任何 .ts / .sql / .json 文件
❌ grep repo 永远拿不到 dict_xxx 的定义

典型的运行时注册平台还有：Strapi（strapi_core_store_settings）、Directus（directus_collections）、宜搭/JEPaaS 等低代码平台。

坑：继续 grep 不同关键词是无效努力

repo 里没有这些 schema 不是因为你关键词用错了，也不是因为文件被 gitignore，而是这类数据根本不以文件形式存在。继续在 .next/server、编译产物、或者其他 repo 里挖，结果是一样的。

更危险的反模式：凭直觉猜一个 tableName（如 dict_education）直接写进代码——运行时大概率 404，而且排查成本更高。

正解

repo grep 失败时，不要继续 grep，换路径拿运行时事实：

优先级 1 — 让用户用浏览器 DevTools 抓实际请求（最快、最准、不需要额外权限）：

1. 用户在已登录的 admin 页面打开对应 tab
2. F12 → Network → 找 /api/.../db-enums?table=XXX 的请求
3. 把 XXX 贴给你

如果需要拿字段元信息（如层级标签），让用户在 Console 跑：

fetch('/data/api/settings/db-enums?table=dict_education_levels')
  .then(r => r.json())
  .then(j => console.log(JSON.stringify(j.config)))

优先级 2 — 直接查 registry 表（需要 DB 读权限）：

SELECT table_name, label, display_type, level_field, level_labels
FROM db_enum_registry
WHERE is_deleted = 0
ORDER BY sort;

注意：registry 通常在上游服务自己的 DB，跨 service 未必有凭据。

正解：用 DevTools Network 面板一次拿齐所有 tableName

实测找 4 个业务字典的真实 tableName，DevTools 方案耗时约 3 分钟：用户依次点开 4 个 tab，Network 面板即时显示 ?table=xxx 里的 xxx，逐一记录即可。比 grep 20 分钟无果快得多。

长期解法

让上游平台暴露一个 GET /registry 接口，列出所有已注册的 table/type 及其元信息。下游消费方用 enumId 间接引用而非 hardcode tableName，这样消费方代码也不需要知道 registry 里存的是什么。

接触陌生元数据平台时，第一步就问一句：「这些字典是运行时注册的还是 repo 里定义的？」 一句话省 20 分钟 grep。

一句话外卖

元数据驱动平台的字典/内容类型是 runtime artifact，不是 build-time artifact——grep repo 的前提不成立，应换成查 registry 表或抓 DevTools 网络请求。