概览 — Better Admin

Better Admin 是一个同一套产品、同一套 UI、同一套业务逻辑、同一套数据库，分别用不同技术栈实现的全栈 Admin 系统。

它不是"几套不同的后台"，而是把同一份业务需求在 React、Vue、Next.js、Nuxt 与 NestJS 上各完整落地一遍，用来横向对照多栈工程实践。

一句话理解这个项目

React 版本是 UI Source of Truth。 页面结构、组件行为、视觉、交互与 Design Tokens 都以它为基准，Vue、Next.js、Nuxt 按它复刻 —— 功能对齐优先于像素级对齐。

应用	角色	数据访问路径
`apps/react`	UI Source of Truth，Hero UI 模板实现	→ NestJS REST API
`apps/vue`	按 React 复刻，Nuxt UI v4	→ NestJS REST API
`apps/next`	独立全栈，不依赖 NestJS	→ PostgreSQL 直连
`apps/nuxt`	独立全栈，不依赖 NestJS	→ PostgreSQL 直连
`apps/nest`	独立 REST 后端，只服务 React / Vue	→ PostgreSQL

五个应用都能独立运行、独立构建、独立部署。仓库不引入 pnpm workspace，也不因为放在同一目录而产生依赖耦合。

1 · 一个数据库，四端共用

全部版本共用同一个 Supabase 托管的 PostgreSQL，统一 Drizzle ORM。Supabase 在这里只当数据库用 —— 不使用 Supabase Auth、RLS、Edge Functions（唯一豁免是 v1.5.0 起的用户头像 Storage）。

浏览器端禁止直连数据库，连接串只存在于服务端环境变量。

2 · Contract 优先，OpenAPI 是唯一真源

API 设计先定义 Contract，再动手实现。契约真源是 apps/nest/openapi/openapi.yaml，五个应用必须遵循同一份契约：路径、方法、响应信封、错误码、分页参数逐字一致。

不允许为了"实现方便"自行改契约。改契约前必须评估五个应用各自受到的影响。

3 · 服务端强制校验权限

认证由应用自身实现（JWT 会话），不依赖 Supabase Auth。权限模型是 RBAC：用户 ↔ 角色 ↔ 权限位掩码，并支持菜单与权限关联控制。

前端路由守卫只是体验层，服务端必须独立做一遍 API 权限校验。