1. 为什么选 Prisma PostgreSQL 而不是“SpringMVC REST”或“Django REST Framework”刚接触后端 API 开发的人常被满屏的“SpringMVC 中的 REST”“Django 4.2 DRF 安装使用”刷屏——这不怪你。但我想先说一句实话如果你不是在 Java 企业级项目组里写增删改查也不是在 Python 数据科学团队里快速搭管理后台那盲目跟风 Spring 或 Django反而会让你卡在配置地狱里动弹不得。我自己就踩过这个坑去年帮一家做 SaaS 工具的初创公司重构内部服务原系统用 Spring Boot MyBatis光是解决maven artifact org.postgresql:postgresql:release cannot be resolved in ext这个报错就花了整整两天——不是代码问题是 Maven 仓库镜像、JDK 版本、Spring Boot Starter 依赖树三者咬合不上。最后发现他们连pom.xml里dependency的 groupId 都抄错了。而 Prisma PostgreSQL 的组合本质是把“数据库即服务”的理念落到了开发流中。它不抽象 SQL也不封装 JDBC 层它直接把 PostgreSQL 的表结构变成 TypeScript或 Node.js里可编辑、可补全、可类型校验的模型对象。你写prisma.user.findMany()IDE 就能立刻告诉你返回的是User[]字段有哪些、哪些可空、哪些带默认值——这不是魔法是 Prisma CLI 在你每次运行prisma generate时根据schema.prisma文件实时生成的类型定义。这种“所见即所得”的开发体验在 SpringMVC 里要靠 Lombok MapStruct 自定义注解 大量 XML 配置才能勉强逼近在 Django REST Framework 里则依赖ModelSerializer和ViewSet的隐式约定一旦字段名拼错或关系嵌套过深错误堆栈会把你扔进django.core.exceptions.FieldError的迷宫里。更关键的是 PostgreSQL 本身。热搜词里反复出现“PostgreSQL 和 MySQL 区别”很多人只记住“PG 更重、MySQL 更快”却忽略了真正影响开发效率的点PostgreSQL 原生支持 JSONB、全文检索、地理空间函数、物化视图、行级安全策略RLS而这些能力Prisma 全部能通过声明式语法直接调用。比如你要实现一个用户搜索接口支持按昵称模糊匹配 按标签数组包含筛选 按注册时间倒序用 MySQL 你得手写CONCAT(%, ?, %)FIND_IN_SETORDER BY created_at DESC还要担心 SQL 注入用 Prisma PostgreSQL一行就能写完await prisma.user.findMany({ where: { AND: [ { name: { contains: 张, mode: insensitive } }, { tags: { hasSome: [developer, remote] } }, { createdAt: { gte: new Date(2023-01-01) } } ] }, orderBy: { createdAt: desc } })这里tags: { hasSome: [...] }直接对应 PostgreSQL 的 JSONB 数组操作符?|mode: insensitive底层调用的是ILIKE全部由 Prisma 翻译成安全、高效的原生 SQL。你不需要背命令也不用查文档确认hasSome是不是写成了hasAny——因为 TypeScript 类型系统会在你敲错时就报红。所以当你看到“ubuntu 安装 postgresql 14”“docker postgresql 怎么添加 pgvector 扩展”这类热搜时别只当它是运维任务。它其实是你在设计 API 时已经为未来留下的技术伏笔今天装好 pgvector明天就能给用户搜索加上语义向量相似度排序今天配好 RLS明天就能让多租户数据隔离从“靠代码逻辑保证”升级为“数据库层强制执行”。Prisma 不是替代 PostgreSQL 的工具而是让你能真正用上 PostgreSQL 全部能力的翻译器。提示很多初学者误以为 Prisma 是 ORM。它不是。ORM如 TypeORM、Sequelize试图模拟面向对象模型去操作关系型数据库结果常陷入“对象-关系阻抗失配”Prisma 是Type-Safe Query Builder——它不隐藏 SQL而是用类型安全的方式生成 SQL。你永远可以打开 Prisma Studionpx prisma studio看到它实际执行的查询语句甚至直接在界面里编辑数据。这种透明性是 Spring Data JPA 的Query注解或 Django 的raw()方法永远给不了的。2. 从零初始化绕开“PostgreSQL 安装教程”陷阱的实战路径网上铺天盖地的“PostgreSQL 安装教程”90% 都在教你如何下载.deb包、改pg_hba.conf、设postgres用户密码——这些对开发 API 来说全是干扰项。我试过三种主流安装方式结论很明确除非你明确需要在生产环境部署 PostgreSQL 实例否则开发阶段必须用 Docker 启动一个干净、隔离、可复现的 PostgreSQL 容器。原因很简单ubuntu postgresql 二进制安装或源码安装postgresql会污染你的系统环境变量、/usr/local/目录和psql命令版本而postgresql zip 安装在 Windows 上更是灾难——你需要手动配置data目录权限、postgresql.conf的listen_addresses稍有不慎db tool 打开数据库提示下载postgresql驱动文件就成了家常便饭。我们直接上最稳的 Docker 方案。注意不是简单跑一个docker run -d --name pg -e POSTGRES_PASSWORDdev -p 5432:5432 postgres:15就完事。这个命令启动的容器缺少两个关键要素持久化存储和扩展支持。没有持久化你重启容器所有表结构和测试数据全丢没有扩展你后面想加pgvector做向量搜索或postgis做地图服务就得重建整个数据库成本极高。所以我的标准初始化流程是2.1 创建专用数据目录并初始化容器# 1. 创建项目专属的 PostgreSQL 数据目录避免污染全局 mkdir -p ./postgres-data # 2. 启动容器挂载数据目录 暴露端口 设置密码 启用扩展 docker run -d \ --name my-postgres \ -e POSTGRES_PASSWORDprisma_dev \ -e POSTGRES_DBapi_dev \ -v $(pwd)/postgres-data:/var/lib/postgresql/data \ -p 5432:5432 \ -d postgres:15 \ -c shared_preload_librariespg_stat_statements,pgvector \ -c pg_stat_statements.trackall这里-c shared_preload_librariespg_stat_statements,pgvector是关键。它告诉 PostgreSQL 在启动时就加载pg_stat_statements用于慢查询分析和pgvector向量扩展模块。即使你现在不用pgvector也建议提前加载——因为一旦数据库初始化完成再想动态加载某些扩展需要超级用户权限且可能中断连接。而pg_stat_statements则是你后续调试 API 性能的救命稻草当某个findMany接口响应变慢你可以直接连进容器执行SELECT * FROM pg_stat_statements ORDER BY total_time DESC LIMIT 5;立刻看到哪条 SQL 最耗时。2.2 验证连接与基础配置容器启动后别急着写代码。先用psql或 DBeaver 连上去确认三件事数据库api_dev是否存在且可访问docker exec -it my-postgres psql -U postgres -d api_dev # 进入后执行 \l # 查看数据库列表确认 api_dev 在列 \c api_dev # 切换到该库 \dt # 查看表初始应为空扩展是否已加载成功SELECT * FROM pg_extension WHERE extname IN (pg_stat_statements, vector);如果vector显示不存在说明pgvector扩展未正确安装。此时不要慌进入容器手动安装docker exec -it my-postgres bash # 在容器内执行 psql -U postgres -d api_dev -c CREATE EXTENSION IF NOT EXISTS vector;验证pg_stat_statements是否生效-- 先执行一条测试查询 SELECT 1; -- 再查统计表 SELECT query, calls, total_time FROM pg_stat_statements WHERE query LIKE SELECT 1% ORDER BY total_time DESC LIMIT 1;如果返回结果说明监控已就绪。注意很多教程教你在docker run时用-v挂载一个 SQL 初始化脚本如init.sql然后通过POSTGRES_INITDB_ARGS执行。这看似方便实则埋雷——因为 Prisma 的prisma migrate dev会自动创建_prisma_migrations表并管理迁移历史如果你的初始化脚本里也建了同名表后续prisma migrate resolve会报冲突。我的经验是数据库初始化交给 Prisma而不是 Docker。你只需要确保 PostgreSQL 进程起来、端口通、扩展加载好剩下的建表、索引、约束全部由 Prisma 控制。这样你的schema.prisma文件才是唯一真相源团队协作、CI/CD 流水线才不会因环境差异崩盘。3. Prisma Schema 设计从“Docker 部署 Nacos 连接 PostgreSQL”反推健壮模型看到热搜词“2.2.3 nacos 连接 postgresql【docker 部署 nacos】”你可能会疑惑这和我写 REST API 有什么关系关系大了。Nacos 是一个典型的微服务配置中心它的数据库设计尤其是config_info、tenant_info、group_info这几张核心表就是经过大规模生产验证的、高并发、多租户、强一致性的范本。我们不必照搬 Nacos 的所有字段但它的设计哲学值得直接借鉴用数据库原生能力解决业务问题而不是靠应用层硬编码。比如 Nacos 的config_info表有tenant_id租户ID、group_id分组ID、data_id配置ID三个联合主键字段并在(tenant_id, group_id, data_id)上建唯一索引。这意味着同一个租户下不能有重复的group_id data_id组合——这个约束数据库在插入时就强制校验比你在 Express 路由里写if (await prisma.configInfo.findUnique({ where: { tenantId_groupId_dataId: { tenantId, groupId, dataId } } })) throw new Error(已存在)要可靠一万倍。后者在高并发下仍有极小概率出现竞态条件race condition前者是 ACID 保证的原子操作。所以我们的schema.prisma第一版就该以“租户隔离”为起点。假设我们要做一个类似 Nacos 的轻量级配置中心 API核心模型如下// schema.prisma generator client { provider prisma-client-js } datasource db { provider postgresql url env(DATABASE_URL) // 关键启用 PostgreSQL 原生功能 directUrl env(DIRECT_DATABASE_URL) } model ConfigInfo { id Int id default(autoincrement()) tenantId String db.VarChar(128) // 对应 Nacos 的 tenant_id groupId String db.VarChar(128) // 对应 Nacos 的 group_id dataId String db.VarChar(256) // 对应 Nacos 的 data_id content String db.Text // 配置内容用 TEXT 类型存大文本 md5 String? db.VarChar(32) // 内容 MD5用于变更检测 createTime DateTime default(now()) // 自动填充创建时间 updateTime DateTime updatedAt // 自动更新修改时间 // 关键联合唯一约束等价于 Nacos 的联合主键逻辑 unique([tenantId, groupId, dataId]) // 关键为高频查询字段建索引 index([tenantId, groupId]) index([tenantId, dataId]) } // 新增租户模型支持租户元信息管理 model Tenant { id String id default(cuid()) name String unique description String? status String default(ACTIVE) db.VarChar(20) createdAt DateTime default(now()) updatedAt DateTime updatedAt configInfos ConfigInfo[] }这个设计里有三个容易被忽略但极其重要的细节3.1db.VarChar(N)而非String的显式长度控制Prisma 默认的String类型在 PostgreSQL 里会映射为TEXT。这看起来很省事但TEXT类型无法建高效索引PostgreSQL 对TEXT字段的索引效率远低于VARCHAR(N)。而tenantId、groupId、dataId这些字段恰恰是WHERE和JOIN的高频条件。所以我强制指定db.VarChar(128)既符合 Nacos 实际长度其tenant_id最长 128 字符又让 PostgreSQL 能为其创建 B-tree 索引查询性能提升 3~5 倍。你可以用EXPLAIN ANALYZE验证-- 对比以下两条查询的执行计划 EXPLAIN ANALYZE SELECT * FROM ConfigInfo WHERE tenantId t1; EXPLAIN ANALYZE SELECT * FROM ConfigInfo WHERE content ILIKE %test%;前者走索引扫描Index Scan后者只能顺序扫描Seq Scan——这就是VARCHAR和TEXT的真实差距。3.2unique([tenantId, groupId, dataId])的声明式约束这是 Prisma 最强大的能力之一把数据库约束写在应用层模型里。你不需要在 PostgreSQL 里手动执行ALTER TABLE ConfigInfo ADD CONSTRAINT ...Prisma 会在prisma migrate dev时自动生成并执行这条 SQL。更重要的是这个约束会同步生成 Prisma Client 的类型定义——当你调用prisma.configInfo.create({ data: { tenantId, groupId, dataId } })时如果违反唯一性Prisma 会抛出P2002错误并附带清晰的字段名而不是笼统的Database error。这极大降低了调试成本。3.3updatedAt与default(now())的时间戳自动化很多新手会写一个中间件在每个create/update前手动设置createdAt/updatedAt。这不仅冗余而且极易出错比如忘记在某个分支里设置。Prisma 的updatedAt是数据库层面的触发器行为每次UPDATE该行PostgreSQL 自动更新此字段无需应用层干预。default(now())同理是INSERT时的默认值。两者结合保证了时间戳的绝对准确性和一致性哪怕你的 API 有多个服务实例同时写入也不会出现时间错乱。实操心得我在一个项目里曾把updatedAt错写成updatedAt(), 多了一个括号。Prisma CLI 没报错但生成的 Client 里这个字段类型变成了DateTime | undefined导致所有update操作都必须显式传入updatedAt否则编译失败。后来才发现是语法错误。所以每次修改schema.prisma后务必运行npx prisma validate它会检查语法、类型兼容性和潜在陷阱。这个命令比prisma generate更轻量应该成为你保存文件后的第一反应。4. REST API 实现用 Express Prisma 构建可调试、可监控的端点现在数据库和模型都准备好了该写真正的 REST 接口了。热搜词里“springmvc 中的 rest”强调注解驱动“django rest framework”强调类视图而 Prisma Express 的核心优势在于极度轻量、完全透明、调试友好。你不需要理解RestController的生命周期也不需要搞懂APIView和GenericAPIView的继承链你写的每一行代码就是最终执行的逻辑。我们以最典型的 CRUD 为例实现/api/configs的完整端点。重点不是“怎么写”而是“为什么这样写”以及“怎么让它在真实场景中不掉链子”。4.1 基础路由与 Prisma Client 初始化// server.ts import express from express; import { PrismaClient } from prisma/client; const app express(); const PORT process.env.PORT || 3000; // 关键PrismaClient 必须是单例且需启用连接池 const prisma new PrismaClient({ // 生产环境务必开启日志便于排查慢查询 log: [query, error, warn], // 连接池大小根据你的并发量调整默认 10 // 对于中小项目5~10 足够高并发服务可设为 20 // 但切记过大反而增加数据库连接压力 // 可通过 SHOW max_connections; 查看 PostgreSQL 最大连接数 // 通常设为数据库 max_connections 的 70% 左右 // 例如 PostgreSQL max_connections100则此处设 70 // 但实际项目中我建议从 10 开始压测逐步上调 // 因为 Prisma 的连接池是懒加载的不活跃连接会自动释放 // 所以宁可保守也不要盲目设高 }); app.use(express.json()); app.use(express.urlencoded({ extended: true })); // 健康检查端点供 Kubernetes/Liveness Probe 使用 app.get(/health, (req, res) { res.json({ status: ok, timestamp: new Date().toISOString() }); }); // 核心配置列表接口 app.get(/api/configs, async (req, res) { try { const { tenantId, groupId, dataId, page 1, limit 10 } req.query; // 关键参数校验必须前置且严格 // 不要相信前端传来的任何字符串 const pageNum parseInt(page as string, 10); const limitNum parseInt(limit as string, 10); if (isNaN(pageNum) || pageNum 1 || isNaN(limitNum) || limitNum 1 || limitNum 100) { return res.status(400).json({ error: Invalid pagination parameters }); } // 构建查询条件对象 const whereClause: any {}; if (tenantId) whereClause.tenantId tenantId as string; if (groupId) whereClause.groupId groupId as string; if (dataId) whereClause.dataId { contains: dataId as string, mode: insensitive }; // 关键使用 take skip 实现分页而非 OFFSET/LIMIT 的原始写法 // Prisma 的 take/skip 会自动转换为 PostgreSQL 的 LIMIT/OFFSET // 但它更安全因为 Prisma 会校验 take 值是否为正整数 const configs await prisma.configInfo.findMany({ where: whereClause, take: limitNum, skip: (pageNum - 1) * limitNum, orderBy: { createdAt: desc } }); // 获取总条数用于前端分页控件 const total await prisma.configInfo.count({ where: whereClause }); res.json({ data: configs, pagination: { page: pageNum, limit: limitNum, total, pages: Math.ceil(total / limitNum) } }); } catch (error) { console.error(Error fetching configs:, error); // 关键Prisma 错误分类处理 if (error instanceof Prisma.PrismaClientKnownRequestError) { // P2002: 唯一约束冲突 if (error.code P2002) { return res.status(409).json({ error: Resource already exists }); } // P2025: 记录未找到 if (error.code P2025) { return res.status(404).json({ error: Resource not found }); } } res.status(500).json({ error: Internal server error }); } });这段代码里有三个必须掌握的实战要点4.2 分页实现为什么take/skip比手写OFFSET更安全很多教程教你在 SQL 里写SELECT * FROM config_info LIMIT 10 OFFSET 20这在数据量小时没问题但当OFFSET很大比如OFFSET 100000时PostgreSQL 仍需扫描前 100000 行才能拿到结果性能断崖式下跌。而 Prisma 的take/skip并不是简单翻译它背后是 Prisma 引擎的优化策略。更重要的是take参数会被 Prisma Client 的类型系统强制校验为number你不可能传入take: abc或take: -5这从源头杜绝了非法参数导致的 SQL 错误或安全漏洞。4.3 错误分类Prisma 的PrismaClientKnownRequestError是你的调试金矿Prisma 把所有数据库错误都归类为PrismaClientKnownRequestError并赋予唯一的code如P2002,P2025,P2010。这些 code 不是随机字符串而是精准指向问题根源Code含义应对措施P2002唯一约束冲突如重复插入返回 409 Conflict提示用户资源已存在P2025记录未找到如findUnique查不到返回 404 Not Found而不是 500P2010查询超时query timeout需检查 SQL 是否缺少索引或连接池是否耗尽如果你不捕获并分类这些错误所有数据库异常都会变成 500前端无法区分是“数据不存在”还是“数据库挂了”运维也无法快速定位是慢查询还是死锁。所以catch (error) { if (error instanceof Prisma.PrismaClientKnownRequestError) { ... } }这段代码不是可选项是生产环境的强制要求。4.4 日志与监控如何让pg_stat_statements真正为你服务前面我们在 Docker 启动时启用了pg_stat_statements现在要让它产生价值。在server.ts的prisma初始化里我们设置了log: [query, error, warn]。但这只是 Prisma Client 的日志它告诉你“执行了什么 SQL”却不告诉你“这条 SQL 执行了多久”。真正的性能洞察来自 PostgreSQL 自身的pg_stat_statements。我们写一个简单的监控端点// 添加到 server.ts app.get(/api/db-stats, async (req, res) { try { // 直接查询 pg_stat_statements 视图 const stats await prisma.$queryRaw SELECT query, calls, total_time, mean_time, rows, shared_blks_hit, shared_blks_read FROM pg_stat_statements WHERE query NOT LIKE %pg_stat_statements% ORDER BY total_time DESC LIMIT 10 ; res.json({ stats }); } catch (error) { console.error(DB stats error:, error); res.status(500).json({ error: Failed to fetch DB stats }); } });部署后访问/api/db-stats你会看到类似这样的结果querycallstotal_timemean_timerowsSELECT * FROM ConfigInfo WHERE tenantId $1 AND groupId $2 ORDER BY createdAt DESC LIMIT $3 OFFSET $4124712456.789.9912470这说明这个查询平均每次耗时 9.99ms总共执行了 1247 次累计耗时 12.4 秒。如果mean_time突然飙升到 500ms你就知道该去检查tenantId和groupId的联合索引是否失效或者是否有长事务阻塞了查询。踩坑实录我在一个项目上线后发现/api/configs接口 P95 延迟从 50ms 涨到 800ms。通过/api/db-stats发现SELECT * FROM ConfigInfo ...的total_time占了数据库总耗时的 92%。但奇怪的是mean_time只有 15ms。继续查pg_stat_statements发现calls字段在 1 小时内暴涨了 10 倍。原来前端有个轮询逻辑每 5 秒请求一次/api/configs且没带任何tenantId参数导致查询全表扫描。解决方案很简单在路由里加一层缓存res.set(Cache-Control, public, max-age30)或强制要求tenantId为必填。这个案例说明API 的性能问题70% 出在调用方而不是实现方。Prisma 和 PostgreSQL 提供的监控能力就是帮你快速锁定“谁在滥用接口”的证据。5. 迁移与部署从prisma migrate dev到生产环境的平滑过渡很多教程停在prisma migrate dev就结束了仿佛开发完成就万事大吉。但现实是残酷的你本地prisma migrate dev生成的迁移文件直接扔到生产环境大概率会失败。原因有三一是生产数据库已有数据CREATE TABLE会报错二是prisma migrate dev默认开启--create-only它只生成 SQL不执行三是生产环境需要严格的回滚机制而dev命令没有。所以我们必须建立一套从开发到生产的标准化迁移流程。这个流程的核心原则是迁移脚本必须幂等执行过程必须可审计失败必须可回滚。5.1 开发阶段prisma migrate dev的正确姿势在项目根目录先创建.env文件# .env DATABASE_URLpostgresql://postgres:prisma_devlocalhost:5432/api_dev?schemapublic DIRECT_DATABASE_URLpostgresql://postgres:prisma_devlocalhost:5432/api_dev?schemapublic注意DIRECT_DATABASE_URL的作用它绕过连接池用于prisma migrate命令直连数据库避免连接池干扰迁移过程。然后执行# 1. 首次初始化根据 schema.prisma 生成迁移文件 npx prisma migrate dev --name init --create-only # 2. 查看生成的迁移文件位于 prisma/migrations/... ls prisma/migrations/ # 3. 手动检查迁移 SQL非常重要 cat prisma/migrations/20231015123456_init/migration.sql # 你应该看到类似 # CREATE TABLE ConfigInfo ( # id SERIAL PRIMARY KEY, # tenantId VARCHAR(128) NOT NULL, # ... # ); # CREATE UNIQUE INDEX ConfigInfo_tenantId_groupId_dataId_key ON ConfigInfo(tenantId, groupId, dataId); # 4. 确认无误后执行迁移这一步会实际修改数据库 npx prisma migrate dev --name init关键点在于--create-only。它强制 Prisma 只生成 SQL 文件不执行。这给了你人工审查的机会。我见过太多人跳过这步结果migration.sql里生成了DROP TABLE语句一执行线上数据全没了。所以--create-only是你的安全阀永远不要省略。5.2 生产部署用prisma migrate deploy替代dev生产环境绝不能用prisma migrate dev。它会尝试创建新迁移文件而生产数据库的 schema 是受控的不允许随意新增。正确的命令是# 在生产服务器上执行 npx prisma migrate deploy --schema./prisma/schema.prismamigrate deploy的行为是扫描prisma/migrations/目录下所有已存在但未在目标数据库\_prisma_migrations表中标记为“已执行”的迁移文件然后按顺序执行它们。它不会生成新文件只执行已有文件。这保证了部署的确定性。但deploy也有风险如果某次迁移执行失败比如 SQL 语法错误_prisma_migrations表里会记录rolled_back: true下次deploy会跳过它导致 schema 不一致。所以生产部署必须配合 CI/CD 流水线且每次部署前先在 staging 环境完整跑一遍migrate deploy验证通过后再推 production。5.3 回滚方案当migrate deploy失败时如何救火Prisma 官方不推荐“自动回滚”因为数据库迁移的语义太复杂比如ADD COLUMN可以回滚但DROP COLUMN就不行。所以我们的回滚策略是基于备份 手动 SQL。每日自动备份在 Docker 容器里用pg_dump定时备份# 在宿主机 crontab 里添加 0 2 * * * docker exec my-postgres pg_dump -U postgres -d api_dev /backup/api_dev_$(date \%Y\%m\%d).sql迁移前快照每次执行prisma migrate deploy前手动备份当前状态# 获取当前 migration hash CURRENT_HASH$(cat prisma/migrations/$(ls prisma/migrations/ | tail -1)/migration_lock.toml | grep hash | cut -d -f2 | tr -d ) # 用 hash 命名备份 docker exec my-postgres pg_dump -U postgres -d api_dev /backup/pre_deploy_${CURRENT_HASH:0:8}.sql失败时恢复如果deploy失败立即执行# 停止应用 pm2 stop api # 恢复到上一个已知良好状态 cat /backup/pre_deploy_XXXXXX.sql | docker exec -i my-postgres psql -U postgres -d api_dev # 重启应用 pm2 start api这个方案看似原始但胜在可靠。比起依赖 Prisma 的“智能回滚”手动备份恢复的失败率几乎为零。毕竟数据库的底线是数据不丢服务可恢复。其他都是锦上添花。最后分享一个小技巧在prisma/migrations/目录下我习惯创建一个README.md记录每次迁移的业务背景。比如## 20231015_init - 目的初始化配置中心核心表 - 影响新增 ConfigInfo 表删除旧版 config 表已在 v2.0.0 下线 - 风险无全新表 ## 20231020_add_tags - 目的为 ConfigInfo 支持标签数组 - 修改新增 tags 字段类型为 Json - 风险现有数据 tags 字段为 NULL前端需兼容这份文档是给三个月后的你和给新加入的同事最好的入职指南。它比任何代码注释都管用。
