我是前端，第一次用 Nuxt4 + vben5 + Go + PostgreSQL 做完博客系统

大家好，我是一个主职前端开发。
平时工作已经很满了，还会抽时间接一些朋友项目。最近终于挤出时间，做完了我人生第一个完整博客系统：前台 Nuxt4 + TypeScript，后台 vben admin 5.0，服务端 Go + PostgreSQL，并用 Docker 部署。

这篇文章不是“完美架构教程”，而是一次真实复盘：
我为什么这么选、怎么把它跑起来、踩了哪些坑，以及我这个“Go 新手”到底是怎么把项目落地的。

项目地址也放在这里，方便大家直接体验和查看代码：

• 站点体验地址：blog.copyman.top
• GitHub 仓库地址：github.com/Rupiong/blo…

---

一、为什么是这套组合？

1）Nuxt4：前端开发体验太顺手了

我本职是前端，Nuxt4 的开发体验几乎是“无痛”：

• 文件路由天然适合博客这种内容站
• SSR/SEO 友好，对文章收录更友善
• 生态成熟，Vue3 + TS 的心智成本最低
• 页面、状态、插件、中间件都有固定组织方式，长期维护舒服

2）vben 5.0：后台管理端提效很明显

这次我没有自己从零撸后台，而是用了 vben 5.0 做管理端，原因也很直接：

• 中后台能力完整，权限、路由、布局这些基础设施省了大量时间
• 组件和工程规范成熟，适合快速做内容管理后台
• 我可以把更多精力放在业务流程和接口联调上

3）Go：不是因为会，而是因为“想把服务端补齐”

我几乎没有 Go 经验，但我还是选了 Go，原因很实际：

• 编译部署简单，单二进制很省心
• 性能和并发处理能力足够做内容站 API
• 语法简洁，学习曲线比想象中平滑

4）PostgreSQL：给博客一个靠谱的数据底座

博客虽小，但数据模型并不简单（文章、分类、标签、用户、评论、权限、统计）。
PostgreSQL 在关系建模、事务和扩展性上都很稳，后续想加功能（比如全文检索）也有空间。

---

二、项目做到了什么程度？

当前版本更像“可长期迭代的 1.0”，采用的是前后端分离：

• 响应式博客前端（桌面端/移动端）
• 文章详情与内容阅读流程
• 路由中间件与插件能力（如滚动行为处理）
• Nuxt 侧 API 代理，统一前台请求入口
• vben 5.0 后台管理端（内容管理、运营维护）
• Go + PostgreSQL 服务端 API
• Docker 化部署，降低环境差异问题
• 基础工程化能力：TypeScript、状态管理、样式体系、构建优化

前端项目目录大致是这样（简化版）：

src/
├── assets/
├── middleware/
├── pages/
├── plugins/
└── app.vue

---

三、前后端分离联调时，我做对的一件事：统一 API 入口

如果你做过“前端 dev 环境 + 后端独立服务”，一定被跨域和环境配置折磨过。
我这次采用的策略是：前端永远请求同源前缀 /basic-api，再由 Nuxt/Nitro 转发到真正后端地址。

核心思路：

• 客户端只认一个地址：/basic-api
• 开发环境通过 devProxy 转发
• 生产环境通过 routeRules.proxy 转发
• 后端地址通过环境变量统一配置（GLOB_API_URL）

这件事看起来只是“配了一下代理”，但它解决了三个高频问题：

1. 前端代码不再关心不同环境的真实后端域名
2. 降低 CORS 干扰，联调路径更稳定
3. 部署切环境时，改配置而不是改业务代码

---

四、作为 Go 新手，我踩过的坑

坑 1：先写业务，再补数据库设计（顺序反了）

一开始我有点“前端思维上头”：先把接口写出来再看表结构。
结果是接口改来改去，最后回头重构数据模型。

后来我改成：

1. 先明确实体关系（文章/用户/标签等）
2. 再定 SQL 结构与索引
3. 最后写接口和 DTO

效率立刻提升。

坑 2：配置散落在多个地方，排查很痛苦

刚开始我把端口、后端地址、站点信息写在多个文件里，出问题时很难定位。
后来统一做法是：

• 环境变量负责“环境差异”
• Nuxt runtimeConfig 负责“前端可感知配置”
• 关键配置加启动时校验（例如后端 URL 不存在就直接报错）

这一步对“兼职时间碎片化开发”非常重要，不然你每次回到项目都要重新找状态。

坑 3：过早追求“高级架构”

第一次做前后端分离项目，最容易陷入“我要不要微服务、要不要事件总线、要不要先上缓存集群”。
我的结论是：先把核心链路跑通，比架构名词重要一百倍。

博客 1.0 版本真正的核心链路只有这几条：

• 文章列表能稳定返回
• 文章详情页可读、可索引、可访问
• 管理端操作能正确落库

先把这三条做实，后面的优化才有意义。

---

五、我对 Nuxt4 + vben5 + Go 这套组合的真实评价

站在“前端转全栈新手”的角度，我给这套组合一个很务实的评价：

• 学习成本：中等（Go 需要补基础，但可控）
• 开发效率：高（Nuxt 前台 + vben 后台 + Go 服务端分工清晰）
• 可维护性：高（前后端职责明确，部署方式直接）
• 适合人群：想从前端迈向全栈、又希望前台/后台/服务端职责明确的人

---

六、如果你也想做第一个全栈博客，我建议这样开始

1. 先做最小闭环：文章列表 + 详情 + 后台发布
2. 不要先卷 UI，把 API、鉴权、数据库先跑顺
3. 配置统一管理（环境变量 + 运行时配置）
4. 每周固定一个“小迭代目标”，别追求一次做完
5. 先上线一个可用版本，再根据真实反馈迭代

---

七、最后

这个项目让我最有成就感的，不是“用了 Go”，而是终于把一个完整系统从 0 到 1 做完。
对于我们这种一边上班、一边挤时间做项目的人来说，能持续推进，比完美更重要。