甲蛙-Spring Boot + Vue3 前后端分离 实战 wiki 知识库系统

这份资料围绕一个具体的落点展开：用 Spring Boot 加 Vue3 做一套前后端分离的 wiki 知识库系统。它不是一个只讲概念的演示，而是把「知识库」这个业务场景拆成可编码的模块——电子书、分类、文档编辑、菜单联动，每一块都有对应的接口设计、数据结构与前端交互处理。对已经会写单个页面、但没完整跑通过前后端协作链路的开发者来说，参照价值比较直接。

技术栈与工程分层

后端是 Spring Boot 单体服务，承担 REST 接口、参数校验、业务分层与数据持久化；前端是 Vue3，负责路由、组件状态和界面渲染。两边通过 HTTP 接口约定数据格式，前端不依赖服务端模板，服务端也不关心视图层，这是前后端分离最基本也最关键的一条边界。

值得对照的是分层方式。Controller 只做参数接收和响应包装，Service 承载业务规则，数据访问层单独抽出。这种切法在真实项目里直接决定后期改需求的成本——当「电子书管理增加分类选择」这类改动出现时，动的是哪一层、要不要改接口契约，看一遍代码结构就清楚了。前端同理，页面组件、可复用组件、接口请求模块分开组织，避免把所有逻辑堆在单个 .vue 文件里。

围绕知识库的业务模块

• 分类管理：分类的增删改查、表格展示、编辑交互，以及分类与电子书之间的关联选择。
• 电子书管理：列表与表单，并在编辑时挂接分类，处理一对多或多对多的数据关系。
• 文档与内容编辑：知识库的核心载体，涉及内容的录入、保存与展示。
• 菜单与导航联动：点击分类菜单后的筛选、跳转与状态同步，属于典型的前端路由与状态管理问题。

这些模块不是孤立的练习，而是共享同一套数据模型。分类被电子书引用，电子书又关联文档，改一处就要考虑对其他模块的影响——这正是业务系统与「写个 demo」的区别所在。

可以拿来复用的工程细节

第一是接口约定与统一响应结构，前端请求层如何统一处理成功、失败和异常提示。第二是表格与表单的抽象，分类列表和电子书列表在分页、搜索、编辑弹窗上高度相似，能不能抽出通用组件，是判断前端组织能力的一个观察点。第三是分类选择器这类跨模块组件的复用，它同时服务于电子书管理和后续内容归类。

第四是前后端联调时的常见问题：跨域配置、请求参数与后端接收不一致、时间与枚举字段的格式转换。这些细节在视频里往往一带而过，但恰恰是本地跑不通时最耗时间的部分，建议对照源码逐项确认。

建议的对照方式

不要按顺序把视频看完再动手。更有效的做法是先用资料里的源码把项目跑起来，确认接口能通、页面能渲染，然后挑一个模块（比如分类管理）自己重写一遍，写完再和原实现对比差异：接口设计是否一致、状态放在哪一层、异常怎么处理。带着「我这样写会有什么问题」的疑问去看后续章节，吸收效率会明显不同。

如果目的是补齐前后端分离的完整经验，重点放在接口契约、数据流转和组件复用这三条线上，而不是记住某个具体 API 的写法。技术栈会变，这三条线的判断力更耐用。