不懂后端，只会 TypeScript，想独立做完整项目？这套全栈底座就是给前端准备的
废话不多说，直接上干货。
你有没有遇到过这些情况？
有人找我做小程序，前端页面没问题，但我不懂后端，这个活不敢接。
有人找我做 B2B 官网，页面我能写，后台和接口没人做，最后还是接不下来。
领导让我独立完成一套“业务 C 端 + 管理后台 + 服务端”，可我只会 Vue 或 React。
AI 能帮我生成几个接口，但数据库怎么设计、JWT 怎么鉴权、权限怎么控制、代码应该放在哪里，我心里根本没底。
你缺的可能不是前端能力。
你缺的是一套已经把后端基础能力跑通，而且前端开发者能够看懂、敢于继续往下写的全栈工程。
不用急，这正是 LY Fullstack 想解决的问题。
它已经打通了管理后台、管理 API、默认 C 端 API、PostgreSQL 数据库、登录鉴权、RBAC 权限、动态菜单、测试、CI 和本地初始化流程。你不用再从空目录研究“一个后端项目到底应该怎么搭”，可以直接从自己的业务开始。
只会 TypeScript，也没有关系。
C 端继续使用你熟悉的 Vue、React、Nuxt、小程序或者其他技术栈；仓库不会替你定义具体的 C 端产品，但提供了一个基于 NestJS 的默认 C 端 API，作为新增真实业务模块时的服务端起点。前后端仍然使用同一种语言，你可以沿着一条真实可运行的业务链路，边开发、边理解后端。
更重要的是，它不只是对开发者友好，也是一套 AI 友好的工程底座。
仓库里已经准备了 AGENTS.md 和十几份开发规范。目录怎么划分、接口放在哪里、数据库怎么修改、Element Plus 主题怎么覆盖、一个功能做完需要通过哪些检查，都已经写进规则。
你不需要让 AI 在一个空仓库里随意发挥，而是让它先读规则，再沿着项目已经确定的边界工作。
你负责判断要做什么，底座告诉 AI 应该怎么做。
这不能让你一夜之间变成资深后端，但足以让一个熟悉 TypeScript 的前端，放心大胆地迈出全栈开发的第一步。
它不是一套预置所有业务的后台系统
这里需要先明确：LY Fullstack 不是一套预置了所有业务功能的后台管理系统，而是一套帮你提前完成全栈基础建设的工程底座。
服务端怎么搭、管理后台怎么建、登录鉴权怎么做、用户角色菜单怎么关联、数据库怎么初始化、请求和错误怎么处理，这些每个项目都会重复遇到的基础模块，仓库已经替你准备好了。
在这块底座上，你可以直接开发自己的小程序、企业官网、个人产品或者其他 C 端业务，再为真实业务增加对应的管理模块，而不必每接一个项目，都从零搭一遍服务端和后台管理基础框架。
它真正节省的不是写几个页面的时间，而是从空目录走到“终于可以开始开发业务”之前，那段重复、琐碎又最容易踩坑的工程建设时间。
不过，通用底座不等于毛坯工程。
LY Fullstack 的后台 UI 一点也不含糊。登录页、工作台、深浅主题、图表、表单、表格、弹窗和反馈状态都建立了统一的视觉规范，不是随手拼出来的一套 Element Plus 默认页面。
如果你的项目本身就是一套前后端一体的管理系统，不需要额外开发小程序、官网等独立 C 端，那么现有的 admin 和 admin-api 同样可以开箱即用。接上你的业务表和业务模块，就可以直接进入功能开发。
它既可以成为 C 端业务背后的管理底座，也可以直接成为一套后台管理业务的项目起点。
先看它现在是什么样
这是 LY Fullstack 当前的深色工作台：
浅色主题也做了单独适配，不是简单把黑色背景换成白色：
我知道，GitHub 上从来不缺“看起来很完整”的后台截图。
所以这次我更在意的不是菜单有多少，而是截图背后的流程是不是真的。
现在仓库里已经跑通了这些能力：
- 管理员登录、会话恢复、退出登录和修改密码。
- 用户、角色、菜单组成的 RBAC 权限闭环。
- 用户绑定角色，角色分配菜单和按钮权限。
- 数据库菜单驱动前端侧边栏和动态路由。
- 用户、角色、菜单的真实增删改查。
- PostgreSQL 数据库迁移、初始化和种子数据。
- 默认 C 端 API 的健康检查、公共字典和公共配置读取。
- 单元测试、Playwright 浏览器测试和 GitHub Actions CI。
- 深浅主题、统一反馈、版本检测和更新提示。
工作台上的统计数据只是为了展示 UI；用户、角色和菜单管理则来自真实 API 和真实数据库。
一个前端拿到它，究竟能做什么
假设你接到了一个企业官网。
C 端可能用 Nuxt，也可能只是普通 Vue；官网要展示产品、文章和询盘，背后则需要一个管理后台维护这些数据。
如果从空目录开始，第一步甚至还不是写业务，而是先搭框架、做技术选型。
前端你很快就选了自己熟悉的 Vue，但轮到服务端框架、数据库、ORM 和项目结构时，才发现自己真正有把握的似乎只有 Vue 和 TypeScript。即使最后决定使用同样基于 TypeScript 的 NestJS，后面仍然有一整条工程链路需要从零建立：
前后端项目结构怎么组织
服务端模块应该怎么划分
管理员怎么登录
Token 怎么校验
用户和角色怎么关联
菜单权限怎么控制
数据库怎么建表和迁移
接口异常怎么统一返回
前端请求失败怎么统一提示
项目换一台电脑怎么初始化
等这些事情全部做完，真正的“产品管理”和“询盘管理”可能一行还没写。
LY Fullstack 想省掉的，正是这部分每个项目都会重复、第一次做又很容易出错的工作。
拿到仓库后，你可以保留现有的 admin、admin-api 和默认 api，然后直接在 apps/api 中增加自己的 C 端业务模块；只有在业务确实需要新的独立部署边界时，才使用 pnpm new:server 创建另一个服务端工程。客户端则继续根据真实场景选择 Nuxt、Next.js、小程序或者其他技术栈。
它没有提前猜测你的 C 端到底是什么。
因为个人产品、企业官网、小程序和内容站的页面形态与业务模型完全不同，硬塞一个所谓“通用 C 端产品”，最后大概率只是另一个需要删除的空壳。
但“不定义 C 端”不等于完全不提供 C 端服务端基础。现在的 apps/api 刻意只实现了健康检查、公共字典和公共配置读取，没有虚构终端用户、订单、内容等具体业务。它的价值不是替你决定产品，而是用这几个基础 API 建立一套可以沿用的实现范式：应用配置与安全启动、NestJS 模块组织、Controller 与 Service 分层、Prisma 数据访问、跨端安全类型以及对应测试。再配合仓库中的开发约束，后续增加真实 C 端业务时就有清晰的落点，不容易随着功能增长逐渐膨胀、失去边界。
但无论 C 端是什么，管理员登录、用户、角色、权限、数据库和后台 CRUD 往往都要再做一遍。
LY Fullstack 先把这部分做成了可以复用的管理核心。
为什么它对前端更顺手
我不是在说，只要会 TypeScript，就可以完全不理解数据库、安全和后端设计。
这种承诺不负责任。
LY Fullstack 真正降低的是开始实践的门槛。
前端开发者不需要先换一门语言，也不需要在写出第一个接口前，先掌握一整套庞大的后端生态。前端和后端都使用 TypeScript，你可以先用熟悉的语言理解请求如何进入 Controller、业务如何落到 Service、数据如何交给 Prisma，再逐步理解认证、权限和数据库事务。
很多概念并不是完全陌生的：
| 前端熟悉的东西 | 在项目里继续理解的东西 |
|---|---|
| 页面路由和路由守卫 | 后端 Controller 和 Guard |
| 组件与 Composable | Module、Service 与依赖注入 |
| TypeScript 类型 | DTO、接口契约和数据库模型边界 |
| Axios 请求封装 | 统一响应、异常处理和身份校验 |
| 前端工程化 | migration、seed、测试、CI 和部署 |
它们当然不是一回事，但使用同一种语言，可以少一次思维和工具链的剧烈切换。
更重要的是，你面对的不是一堆互不相干的教程代码，而是一条已经连起来的链路：
页面表单
→ 前端 Service
→ HTTP API
→ NestJS Controller
→ 业务 Service
→ Prisma
→ PostgreSQL
沿着一条真实链路学习，比先看完几十个孤立概念，再尝试把它们拼起来，更容易建立完整认知。
LY Fullstack 不是让前端绕过后端，而是让前端从自己最熟悉的 TypeScript 出发，真正走进后端。
我不想再做一套只能演示的模板
这个项目并不是为了写文章临时搭出来的。
它的第一批工程经验，并不是来自对脚手架的想象，而是来自一个我借助 AI 独立完成产品设计、前端开发、后端开发并最终真实交付的项目。公开之前，我删除了客户名称、业务数据、图片、域名和所有专属逻辑，只保留在真实开发中反复使用过的部分：
- NestJS + Fastify 的服务端基础结构。
- PostgreSQL + Prisma 的数据库流程。
- 登录、JWT、账号状态复查和密码修改。
- Vue 管理后台的请求层、路由、CRUD 和反馈模式。
- pnpm Monorepo、测试、CI 和本地初始化流程。
- 前端、后端、数据库与 AI 协作规则。
提取过程也不是复制粘贴。
这个仓库中途推翻过不少看起来“更完整”的决定：
- 原本考虑只放一个没有实际能力的空 C 端 API，后来将它调整为默认业务 API 底座：保留通用读取能力和完整实现规范，但不预置任何具体 C 端业务。
- 原本考虑同时维护 Vue 和 React Admin，后来只保留一套能认真维护的 Vue 实现。
- 原本想把 Axios 抽成跨框架子包，后来发现没有第二个真实消费者，这只是过度设计。
- 原本参考过现成后台 UI，最后全部清空，重新建立自己的主题和页面风格。
一个底座真正重要的，不是预置多少未来可能用到的东西，而是知道哪些能力应该留下，哪些抽象还没有存在的资格。
三条命令，先把项目跑起来
本地准备好 Node.js、pnpm，以及一个可用的 PostgreSQL 17 环境后：
pnpm install
pnpm setup
pnpm dev
pnpm install 负责安装依赖，不会偷偷帮你创建数据库。
PostgreSQL 17 可以直接安装在本机，也可以由项目通过 Docker Compose 启动，两种方式选择一种即可。如果本机既没有可用的 PostgreSQL，也没有安装 Docker，初始化流程就无法完成。
pnpm setup 会询问 PostgreSQL 密码、数据库名称和管理员初始密码。它会优先复用本机 127.0.0.1:5432 上的 PostgreSQL；没有检测到本地服务但 Docker Compose 可用时，则自动启动项目内的 PostgreSQL 17 容器。数据库就绪后，脚本会创建数据库、执行 migration、初始化表结构与基础 RBAC 数据。
pnpm dev 会让你选择需要启动的应用。
启动后打开 http://localhost:8081，使用 admin 和刚刚自行设置的密码登录。
这几步看起来简单，背后解决的是很多全栈项目最容易劝退新人的问题：环境变量到底放哪里、数据库怎样第一次创建、表结构如何同步、初始管理员从哪里来、换一台电脑为什么跑不起来。
当这些流程能够重复执行，你才可以把注意力放回业务本身。
为什么现在没有上微服务
如果你只是想完成第一个全栈项目，其实可以先跳过这一节。
但既然它是一套准备长期维护的工程底座，我仍然需要交代清楚它的架构边界。
当前版本采用的是 Monorepo 管理多个应用，单个服务内部使用模块化单体 的架构，不是微服务。
仓库中的 admin-api 和默认 api 是两个可以独立启动、独立配置和独立部署的 NestJS 应用。admin-api 承担管理端登录、RBAC 和系统管理，api 为未来的真实 C 端业务提供服务端底座；两者保持认证与应用边界，不把管理端会话直接混入 C 端。
但“存在多个可独立运行的应用”不等于已经采用微服务。每个服务内部仍然按照 NestJS 模块组织相关能力，当前也没有引入 API 网关、服务注册与发现、服务间消息通信、分布式事务和链路追踪等微服务治理设施。这样的结构既避免把所有后端职责堆进同一个进程，也不需要在业务规模尚未出现之前承担分布式系统的复杂度。
对于个人开发者、小团队和大量中小型项目，真正的问题通常不是“服务拆得不够多”，而是：
- 登录和权限是否可靠。
- 数据库能不能稳定迁移。
- 代码放在哪里有没有统一边界。
- 项目离开作者电脑还能不能运行。
- 测试、CI 和部署有没有形成闭环。
这些问题没有解决，先拆微服务并不会让项目自动变高级，只会把一次本地调用变成一次网络调用，再增加一套分布式系统需要处理的问题。
NestJS 本身支持微服务。未来 LY Fullstack 也会单独规划微服务版本，但不会为了显得“架构先进”，把当前这个面向个人、小团队和中小型业务的版本强行拆碎。
架构不是越重越专业。用足够简单的方案解决当前规模的问题，本身就是专业判断。
它已经完成什么，还有什么没完成
目前，登录、RBAC、动态菜单、系统管理、主题系统、数据库初始化、单元测试、浏览器测试、CI 和部署文档已经进入仓库，v0.1.0 已经发布。
但它不是一个什么业务都做完了的成品系统。
它没有替你预置商城、内容管理、多租户、工作流，也没有公开在线 Demo——服务器还没有准备好，我不会把计划中的能力写成已经完成。
它更像一块已经接通水电、打好地基的场地。
你不必再从登录、权限、数据库和工程配置开始挖土，但最终要建企业官网、小程序、个人产品还是内部工具，仍然取决于你自己的业务。
这也是我认为开源底座最合适的边界：
把所有项目都可能重复的部分认真做好，把只有真实业务才能决定的部分留给使用者。
最后
LY Fullstack 不是为了证明“前端也能随便写后端”。
恰恰相反，真正做过一次完整项目之后，你会开始理解：登录不只是发一个 Token，权限不只是隐藏按钮，数据库不只是建几张表，部署也不只是把 dist 上传到服务器。
但这些知识不一定要在动手之前一次性学完。
如果你已经熟悉 Vue 和 TypeScript，想独立做一个完整项目，却一直不知道后端该从哪里开始，那么这套项目就是为你准备的。
你可以先把它跑起来，看看一次登录如何经过前端、接口、Guard、Service 和数据库；再试着增加一个属于自己的业务模块。
从“能写页面”走到“能交付完整项目”，中间缺的往往不是另一门语言。
缺的是一条可以真正走一遍的路。
项目地址：
如果你真实运行时遇到问题，可以直接提交 Issue。一个开源项目是否真的对新人友好，不应该由作者自己宣布，而应该由第一次接触它的人来验证。
下一篇
下一篇不急着讲抽象架构。
我们直接站在前端开发者的视角，完整走一遍：
拿到 LY Fullstack 之后，怎样增加自己的第一个全栈业务模块？
从数据库表、后端接口到管理页面，把一条真实业务链路接起来。等你亲手走完这一遍，再回头理解 Monorepo、模块边界和类型契约，会比先背概念清楚得多。
