最近帮朋友梳理一个开源的 IT 交流与分享平台项目，标题写得直白：Java SpringBoot + Vue3 + MyBatis，前后端分离，数据落在 MySQL。乍一听有点像常见的“课程设计代码”，但真把它从零跑起来，再翻一遍模块设计，会发现里面藏了不少可以拿到生产环境里用的东西。这篇文章我就以这套系统为例，把整体设计、核心实现、前后端联调、部署启动和踩坑经验完整讲一遍，适合正准备做全栈项目的同学，也适合想拿现成源码做二次开发的从业者。1. 整体架构与核心设计思路1.1 前后端分离到底在“分”什么很多人把前后端分离理解成“前端一个文件夹，后端一个文件夹”，其实这还停留在表面。真正的分离要拆开三层来看：职责分离、开发分离、部署分离。在这套系统里，后端只负责暴露 JSON 接口，处理业务逻辑，访问 MySQL 数据库；前端只用 Vue3 负责页面渲染、路由跳转、状态管理。后端不返回任何 HTML 片段，所有交互都靠 HTTP 请求完成。这样做最直接的好处是，前端不再被后端模板牵着走，两个方向可以并行开发。我见过不少项目改成前后端分离后又改回模板渲染，原因多半是接口设计太随意，后端改一个字段，前端就要跟着改一遍，最后干脆把页面塞回后端。所以前后端分离的第一步不是选框架，而是定好接口契约。这套系统的接口约定很统一：所有响应都包在 Result 对象里，结构是 code、message、data。前端只看 code 是否为 200 来判断成功，不需要每个接口单独处理异常。这样无论列表页、详情页还是登录页，错误处理逻辑都一致，代码里不会到处散落着奇怪的返回判断。部署层面的分离也很有代表性。前端构建出来的 dist 目录可以直接交给 Nginx 托管，后端打成 jar 包单独跑在 Tomcat 或者自己的内嵌容器里，MySQL 独立负责持久化。实际发布时只需要把前端静态文件放到服务器，再把/api/开头的请求反向代理到后端，就能完成整个上线的闭环。这套部署模型在中小团队里非常常见，也是标题里“前后端分离”这四个字真正值钱的地方。1.2 技术选型背后的取舍：为什么是这四个组件先说说 SpringBoot。这个框架最大的价值不是“新”，而是省事。SpringMVC 时代写一个接口要配置一堆 XML，还要处理容器部署的问题。SpringBoot 把自动配置和内嵌 Tomcat 做到一起，启动一个mvn spring-boot:run就能跑起来，这对于独立开发一个社区类系统来说非常合适。虽然现在已经有很多人转向 Spring Cloud，但那通常是在多微服务场景下的事，单人或者小团队开发单体应用，SpringBoot 依然是性价比最高的选择。Vue3 选得也没毛病。Vue2 虽然成熟，但 Composition API 和更细粒度的响应式系统只在 Vue3 里能用。尤其是当你需要在文章详情页同时处理评论列表、点赞状态、用户登录引导这些逻辑时，ref、reactive、computed组合起来的代码，比 Vue2 的 Options API 清晰得多。再加上 Vite 的启动速度，前端开发体验确实提升了一个档次。MyBatis 和 JPA 是很多人纠结的点。我这次选择 MyBatis，核心原因是这个项目里有大量列表查询、统计查询和动态 SQL 场景。比如首页文章列表要按 status 过滤，后台要按标题模糊搜索，还要拼时间范围条件，这些用 MyBatis 的 XML 写起来非常直接，每一条 SQL 都明明白白，性能问题也好定位。对比项MyBatisJPA/HibernateSQL 控制力手写 SQL，完全可控自动生成为主，复杂查询难优学习曲线会 SQL 基本就能用要理解映射关系、缓存机制动态 SQL通过<if>、<where>实现方便需要 Specification 或 QueryDSL性能调优可以精确控制查询语句容易出现 N+1，需要额外处理国内生态资料、面试题、开源项目非常多国外企业应用更多，国内覆盖略弱最后一环是 MySQL，不用多解释。免费、稳定、资料多，单机部署的社区类平台用它完全够了。这套组合不是“最新最强”，而是一套很成熟的“低门槛高复用”方案。真正生产环境如果后续并发上来，可以再补 Redis 缓存和分库分表，但那是另一个阶段的问题了。2. 后端核心功能从表结构到业务接口2.1 数据库模型：核心表与关系设计拿到源码第一步，先看 SQL，因为表结构往往决定了业务边界。这个平台核心表不算多，但每张表都有讲究。user 表存用户信息，除了常规的 username、password、nickname、avatar 之外，还用一个 role 字段区分管理员和普通用户。article 表是文章主表，字段里我比较关注的是status，它不是一个简单的删除标记，而是表示草稿、已发布、审核失败三种状态。这样做的好处是，用户可以在发布前存草稿，管理员也能对内容做审核，同时不太需要用物理删除去处理问题内容，保留历史记录对技术社区的运营很重要。comment 表用parent_id支持楼中楼回复。如果parent_id为空，就是顶级评论；如果指向另外一条评论，就表示是回复。为了不让查询复杂度爆掉，这个项目只做了两层结构，避免用递归去拼无限嵌套的评论树。article_like 表是典型的关联表，存文章 ID 和用户 ID，联合唯一索引保证同一个用户对同一篇文章只能点赞一次。favorite 表负责收藏，结构和点赞表类似。标签表的设计也不复杂：tag 表存标签名，article_tag 表做多对多关联。新建文章时前端提交一串标签字符串，后端拆分后先查标签是否存在，不存在就插入，再批量写关联记录。整个过程放在一个事务里，只要一步失败就回滚，不会出现文章有了但标签关联没写进去的情况。建表的时候有两个容易忽略的细节。一是字符集一定要用utf8mb4，否则文章内容里出现表情符号会直接报错。二是时间字段建议用DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP，配合ON UPDATE CURRENT_TIMESTAMP，这样插入和更新都不用手动维护update_time。用现在网上到处都能搜到的经典建表写法，列一个核心表示意：CREATE TABLE article ( id BIGINT AUTO_INCREMENT PRIMARY KEY, user_id BIGINT NOT NULL COMMENT '作者ID', title VARCHAR(200) NOT NULL, content LONGTEXT NOT NULL, summary VARCHAR(500) DEFAULT '', cover_url VARCHAR(500) DEFAULT '', status TINYINT NOT NULL DEFAULT 0 COMMENT '0草稿,1已发布,2审核失败', view_count INT NOT NULL DEFAULT 0, like_count INT NOT NULL DEFAULT 0, comment_count INT NOT NULL DEFAULT 0, create_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, update_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, KEY idx_user_id(user_id), KEY idx_status_create(status, create_time) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;这个idx_status_create(status, create_time)联合索引，是为了首页列表能快速按“已发布”状态和创建时间倒序分页。没有这个索引，数据量上来之后首页会越来越慢。2.2 JWT 认证与权限控制前后端分离项目里，Session 处理起来很别扭，跨域、移动端接入、多实例部署都会遇到麻烦。所以这套源码用了 JWT，登录成功后后端签发一个 token，前端保存起来，每次请求放到 Authorization 请求头里。登录接口做的事情很简单：接收用户名和密码，用 BCrypt 比对数据库里的密码哈希，比对通过后生成 JWT，payload 里放 userId 和 role。注意密码绝对不能明文存，源码里用了 BCryptPasswordEncoder，这是 Spring Security 里自带的标准工具，安全性相对可靠。权限控制这块没有引入整套 Spring Security，而是用拦截器加自定义注解的方式。原因很简单：平台只有普通用户和管理员两类角色，不需要太过复杂的权限体系，拦截器实现起来更轻量，代码也更直观。核心逻辑是在preHandle里取 Token，解析成功后把 userId 放到 request attribute 里，后面 Controller 直接用@RequestAttribute拿到当前登录用户。@Component public class AuthInterceptor implements HandlerInterceptor { @Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { String token = request.getHeader("Authorization"); if (StringUtils.hasText(token) && token.startsWith("Bearer ")) { token = token.substring(7); } try { Claims claims = JwtUtil.parseToken(token); request.setAttribute("userId", claims.get("userId", Integer.class)); request.setAttribute("role", claims.get("role", String.class)); return true; } catch (Exception e) { response.setStatus(HttpStatus.UNAUTHORIZED.value()); response.getWriter().write("{\"code\":401,\"message\":\"登录已过期\"}"); return false; } } }把这个拦截器注册进 WebMvcConfigurer，同时排除/api/auth/login、/api/article/list这些公开接口。这样整个应用的权限边界非常清楚，新增加一个接口时，只要默认走拦截器就行，需要公开的再单独放行。2.3 文章发布、评论与分享的关键实现文章发布是一个高频且容易出错的接口。前端提交 title、content、summary 和 tags，后端 Service 里要先校验标题和内容不能为空，然后开启事务。为什么用事务？因为一次发布要写 article、tag、article_tag 三张表，任何一个写失败都会导致数据不一致。事务让这三个操作要么全部成功，要么全部回滚，在线社区的数据不能出现“文章正文在但标签没了”这种情况。评论列表的查询也有个小技巧。先查顶级评论，查出来之后收集所有顶级评论 ID，再用一次 IN 查询把子评论批量查出来，在后端组装成树形结构。这样做比逐条子评论循环查询少了很多次数据库往返。你如果看到有人写出“循环里查数据库”的评论接口，数据量小的时候没问题，但只要一个热帖有几百条评论，接口延迟就会非常明显。分享功能的实现也值得说一下。这里的分享不是简单复制网页链接，而是有一套独立的记录表。用户点击“分享”后，后端生成一个短码，保存来源文章 ID 和分享渠道，然后返回一个/s/{shortCode}链接。别人打开这个链接时，后端做一次 302 跳转，把访问者导到文章详情页，同时给分享记录加一个点击次数。这样运营就能知道哪些渠道的分享效果更好。还有一个很容易踩坑的点是浏览量统计。最简单的写法是select view_count from article where id = xxx，然后在服务端加一，再update回去。并发情况下这个数字会丢失更新。正确做法是单条 SQL 原子更新：UPDATE article SET view_count = view_count + 1 WHERE id = #{articleId}这样哪怕同时有十个请求进来，数据库自身也能保证累加正确，不需要加锁。3. 前端 Vue3 工程化落地实践3.1 用 Vite 快速初始化前端项目前端部分我最开始拿到的时候还是一个手写配置的 Webpack 项目，后来我直接用 Vite 重新初始化了一遍，迁移非常顺畅。Vite 是基于 ES Module 开发的，冷启动速度快，热更新也流畅，和 Vue3 搭配几乎是当前默认选择。初始化命令很简单：npm create vite@latest frontend -- --template vue然后进入目录安装需要的依赖：npm install vue-router@4 pinia axios element-plus @element-plus/icons-vuevue-router 负责路由，pinia 做状态管理，axios 发请求，element-plus 提供现成组件。这些几乎是 Vue3 全家桶的基础配备。目录结构我习惯按模块切分，而不是按文件类型堆在一起：src/ ├── api/ # 按功能拆分接口请求 ├── assets/ # 静态资源 ├── components/ # ArticleCard、CommentList 等公用组件 ├── router/ # 路由配置 ├── stores/ # Pinia 状态 ├── views/ # 页面级组件 ├── utils/ # 工具函数 ├── App.vue └── main.js为什么一定要把 API 单独放到src/api目录？因为后端接口路径经常变，比如/api/article/page可能改成/api/article/list，如果所有请求都散落在页面组件里，你必须一个个去找。统一放到 api 目录后，只改一个文件里的函数就行。这个习惯在项目变大以后会节省非常多时间。3.2 页面拆分与核心组件设计页面层主要分为首页文章列表、文章详情、个人中心和管理后台。这些页面里的逻辑不难，真正麻烦的是拆分组件。首页拆出一个 ArticleCard 组件，负责展示封面、标题、摘要、作者头像、浏览数、点赞数和评论数。详情页拆出 CommentList 和 ArticleContent，评论列表会递归调用自己来渲染回复，ArticleContent 负责解析 Markdown 内容。这种拆分方式让每个组件职责单一，调试的时候不用在一个大文件里上下翻几百行。Vue3 里写业务逻辑，我比较推荐用<script setup>。以首页加载文章列表为例：<script setup> import { ref, onMounted } from 'vue' import { getArticleList } from '@/api/article' const list = ref([]) const loading = ref(false) const page = ref(1) async function load() { loading.value = true const res = await getArticleList({ page: page.value, size: 10 }) list.value = res.data.records loading.value = false } onMounted(load) </script>这里用ref包住 list，是因为 Vue3 的响应式系统需要被包裹的变量才能触发视图更新。直接写let list = []然后list = res.data.records，页面是不会有任何变化的。对刚入门的同学来说，理解“响应式数据”这一步比理解路由配置更关键。页面之间跳转时，可以用 pinia 保存用户信息。登录成功后把 user 对象和 token 存进 store，同时写入 localStorage。刷新页面时再从 localStorage 恢复，保证用户不会因为按了一下 F5 就丢失登录状态。清除登录状态时，要同时清空 store 和 localStorage，经常有人只清了 localStorage 忘记 store，结果页面还显示旧用户信息，这个坑我踩过好几回。3.3 Axios 封装和跨域联调配置前端所有请求都会经过一个 axios 实例，这个实例负责两件大事：加 token、统一处理错误。项目里的请求封装可以简化成下面这样：import axios from 'axios' import { ElMessage } from 'element-plus' import { useUserStore } from '@/stores/user' import router from '@/router' const request = axios.create({ baseURL: '/api', timeout: 10000 }) request.interceptors.request.use(config => { const userStore = useUserStore() if (userStore.token) { config.headers.Authorization = `Bearer ${userStore.token}` } return config }) request.interceptors.response.use( response => { if (response.data.code !== 200) { ElMessage.error(response.data.message) return Promise.reject(new Error(response.data.message)) } return response.data }, error => { if (error.response?.status === 401) { useUserStore().clearUser() router.push('/login') } ElMessage.error(error.response?.data?.message || '请求失败') return Promise.reject(error) } ) export default request注意这里baseURL写的不是http://localhost:8080，而是简单地写了/api。为什么？因为开发环境下有 Vite proxy 兜底，生产环境有 Nginx 反代，这样代码里就不用按环境切换地址了。Vite 的 proxy 配置在vite.config.ts里：export default defineConfig({ server: { proxy: { '/api': { target: 'http://localhost:8080', changeOrigin: true } } } })这样前端发出/api/user/info请求时，Vite 会自动转发到http://localhost:8080/api/user/info，跨域问题在开发阶段就被解决了。生产环境 Nginx 配置如下：server { listen 80; server_name _; root /path/to/dist; index index.html; location / { try_files $uri $uri/ /index.html; } location /api/ { proxy_pass http://127.0.0.1:8080; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } }location /里回退到/index.html是 Vue Router history 模式的必备姿势，没有这行配置，你在文章详情页按 F5 会直接 404。4. 部署启动与问题排查经验4.1 从零跑通项目的完整步骤很多人拿到源码后第一反应是直接启动后端，结果报一连串错误。正确顺序应该是：先建数据库，再改配置，最后分别启动前后端。第一步，创建数据库并导入初始化 SQL。在 MySQL 里执行：CREATE DATABASE itshare DEFAULT CHARACTER SET utf8mb4;然后导入项目中的init.sql，它会把所有表结构和默认管理员账号都建好。第二步，修改后端配置。重点看application.yml里的数据源信息：spring: datasource: url: jdbc:mysql://localhost:3306/itshare?useUnicode=true&characterEncoding=utf8mb4&serverTimezone=Asia/Shanghai username: root password: your_password jackson: date-format: yyyy-MM-dd HH:mm:ss time-zone: GMT+8这里有两个细节。一是连接串里要带上serverTimezone，否则高版本 MySQL 驱动会报时区错误。二是 Jackson 的时区要设置成 GMT+8，否则前端拿到的时间会比本地时间少八个小时。这两个问题几乎每次新环境部署都会遇到。第三步，启动后端。用 IDEA 直接运行主类，或者命令行执行：mvn spring-boot:run后端启动成功后，先不要急着打开前端，直接在浏览器访问http://localhost:8080/api/article/list，如果能看到 JSON 数据，说明后端已经通了。第四步，启动前端。进入 frontend 目录执行：npm install npm run dev然后访问http://localhost:5173，注册一个账号或者用初始化管理员账号登录，整个项目就完整跑起来了。4.2 常见报错速查表跑项目和联调时，有一些报错反复出现。我整理成了一张表，遇到问题直接照着检查就行。报错/现象原因解决方案连接数据库超时数据库没启动，或账号密码错误检查 MySQL 进程，核对 application.yml 配置中文乱码连接串没指定 utf8mb4在 jdbc url 加characterEncoding=utf8mb4Article list 字段为 nullMyBatis 下划线映射没打开配置map-underscore-to-camel-case: trueInvalid bound statementMapper 接口没被扫描启动类加@MapperScan或接口加@Mapper前端请求 404Vite proxy 没生效或路径不统一确认请求以/api开头，检查 target 地址登录成功但请求 401Token 过期或请求头没带上检查 axios 请求拦截器是否加了 Authorization前端点击跳转刷新后 404Vue Router history 模式缺少后端回退Nginxtry_files $uri $uri/ /index.html;另外还有个很隐蔽的问题：不同电脑上 MyBatis XML 文件的 mapper 路径写死，导致本地找不到对应 namespace。规范的做法是在application.yml里配置mybatis.mapper-locations: classpath:/mapper/*.xml，并且把 XML 文件放在src/main/resources/mapper目录下，不要放在奇怪的包路径里。4.3 二次开发与扩展方向这套源码跑通之后，想把它改造成自己项目，有几个方向值得尝试。第一个方向是做内容推荐。现在的列表只是按时间排序，如果给 article 表加一个热度字段，再写一个定时任务，按浏览量、点赞数、评论数综合计算热度值，就能实现一个“最热榜”。计算逻辑可以用 Spring 的@Scheduled注解，十分钟执行一次，更新热度值。这个功能不复杂，但会让平台看起来更有“社区感”。第二个方向是加 Redis 缓存热门文章列表。首页列表的查询压力最大，把第一页和热门标签对应的文章 ID 列表缓存到 Redis，设置五分钟过期，能显著降低数据库压力。写缓存时注意不要缓存完整对象，可以先缓存 ID，再查数据库补全内容，避免缓存和数据库数据不一致。第三个方向是引入 WebSocket 做在线提醒和私信。评论被回复、文章被点赞时，前端不轮询，而是通过 WebSocket 实时收到通知。实现起来可以先用 Spring 的 WebSocket 模块做一个最简单的握手，前端用new WebSocket()连接，服务端在表扬、评论事件发生时推送一条 JSON。这个扩展会明显提升用户实时交互的体验，也符合“交流和分享平台”本身的产品定位。不管往哪个方向扩展，都要注意基础安全。JWT 密钥不要写在代码里，放到环境变量配置；上线前要修改默认管理员密码；用户提交的富文本内容要做 XSS 过滤。二次开发最容易犯的错就是只关注新功能，忽略了这些底层约束。最后分享一点个人体会。这套系统刚拿到手时，我也习惯性当成“普通毕设”来看，但后来为了改造，把整个数据流追了一遍，才发现真正值钱的东西不在某个酷炫功能，而在每一层之间约定得是否干净。接口统一返回格式、前端统一封装请求、表结构预留 status 状态字段，这些“不起眼”的习惯，才是它能拿来直接二次开发的原因。如果你也想彻底吃透这套源码，我的建议是先不要急着跑，先看 SQL，再跟着一个请求从 Vue 组件一路走到 Mapper 接口，这个过程比看十篇架构文章都管用。
最近帮朋友梳理一个开源的 IT 交流与分享平台项目，标题写得直白：Java SpringBoot + Vue3 + MyBatis，前后端分离，数据落在 MySQL。乍一听有点像常见的“课程设计代码”，但真把它从零跑起来，再翻一遍模块设计，会发现里面藏了不少可以拿到生产环境里用的东西。这篇文章我就以这套系统为例，把整体设计、核心实现、前后端联调、部署启动和踩坑经验完整讲一遍，适合正准备做全栈项目的同学，也适合想拿现成源码做二次开发的从业者。1. 整体架构与核心设计思路1.1 前后端分离到底在“分”什么很多人把前后端分离理解成“前端一个文件夹，后端一个文件夹”，其实这还停留在表面。真正的分离要拆开三层来看：职责分离、开发分离、部署分离。在这套系统里，后端只负责暴露 JSON 接口，处理业务逻辑，访问 MySQL 数据库；前端只用 Vue3 负责页面渲染、路由跳转、状态管理。后端不返回任何 HTML 片段，所有交互都靠 HTTP 请求完成。这样做最直接的好处是，前端不再被后端模板牵着走，两个方向可以并行开发。我见过不少项目改成前后端分离后又改回模板渲染，原因多半是接口设计太随意，后端改一个字段，前端就要跟着改一遍，最后干脆把页面塞回后端。所以前后端分离的第一步不是选框架，而是定好接口契约。这套系统的接口约定很统一：所有响应都包在 Result 对象里，结构是 code、message、data。前端只看 code 是否为 200 来判断成功，不需要每个接口单独处理异常。这样无论列表页、详情页还是登录页，错误处理逻辑都一致，代码里不会到处散落着奇怪的返回判断。部署层面的分离也很有代表性。前端构建出来的 dist 目录可以直接交给 Nginx 托管，后端打成 jar 包单独跑在 Tomcat 或者自己的内嵌容器里，MySQL 独立负责持久化。实际发布时只需要把前端静态文件放到服务器，再把/api/开头的请求反向代理到后端，就能完成整个上线的闭环。这套部署模型在中小团队里非常常见，也是标题里“前后端分离”这四个字真正值钱的地方。1.2 技术选型背后的取舍：为什么是这四个组件先说说 SpringBoot。这个框架最大的价值不是“新”，而是省事。SpringMVC 时代写一个接口要配置一堆 XML，还要处理容器部署的问题。SpringBoot 把自动配置和内嵌 Tomcat 做到一起，启动一个mvn spring-boot:run就能跑起来，这对于独立开发一个社区类系统来说非常合适。虽然现在已经有很多人转向 Spring Cloud，但那通常是在多微服务场景下的事，单人或者小团队开发单体应用，SpringBoot 依然是性价比最高的选择。Vue3 选得也没毛病。Vue2 虽然成熟，但 Composition API 和更细粒度的响应式系统只在 Vue3 里能用。尤其是当你需要在文章详情页同时处理评论列表、点赞状态、用户登录引导这些逻辑时，ref、reactive、computed组合起来的代码，比 Vue2 的 Options API 清晰得多。再加上 Vite 的启动速度，前端开发体验确实提升了一个档次。MyBatis 和 JPA 是很多人纠结的点。我这次选择 MyBatis，核心原因是这个项目里有大量列表查询、统计查询和动态 SQL 场景。比如首页文章列表要按 status 过滤，后台要按标题模糊搜索，还要拼时间范围条件，这些用 MyBatis 的 XML 写起来非常直接，每一条 SQL 都明明白白，性能问题也好定位。对比项MyBatisJPA/HibernateSQL 控制力手写 SQL，完全可控自动生成为主，复杂查询难优学习曲线会 SQL 基本就能用要理解映射关系、缓存机制动态 SQL通过<if>、<where>实现方便需要 Specification 或 QueryDSL性能调优可以精确控制查询语句容易出现 N+1，需要额外处理国内生态资料、面试题、开源项目非常多国外企业应用更多，国内覆盖略弱最后一环是 MySQL，不用多解释。免费、稳定、资料多，单机部署的社区类平台用它完全够了。这套组合不是“最新最强”，而是一套很成熟的“低门槛高复用”方案。真正生产环境如果后续并发上来，可以再补 Redis 缓存和分库分表，但那是另一个阶段的问题了。2. 后端核心功能从表结构到业务接口2.1 数据库模型：核心表与关系设计拿到源码第一步，先看 SQL，因为表结构往往决定了业务边界。这个平台核心表不算多，但每张表都有讲究。user 表存用户信息，除了常规的 username、password、nickname、avatar 之外，还用一个 role 字段区分管理员和普通用户。article 表是文章主表，字段里我比较关注的是status，它不是一个简单的删除标记，而是表示草稿、已发布、审核失败三种状态。这样做的好处是，用户可以在发布前存草稿，管理员也能对内容做审核，同时不太需要用物理删除去处理问题内容，保留历史记录对技术社区的运营很重要。comment 表用parent_id支持楼中楼回复。如果parent_id为空，就是顶级评论；如果指向另外一条评论，就表示是回复。为了不让查询复杂度爆掉，这个项目只做了两层结构，避免用递归去拼无限嵌套的评论树。article_like 表是典型的关联表，存文章 ID 和用户 ID，联合唯一索引保证同一个用户对同一篇文章只能点赞一次。favorite 表负责收藏，结构和点赞表类似。标签表的设计也不复杂：tag 表存标签名，article_tag 表做多对多关联。新建文章时前端提交一串标签字符串，后端拆分后先查标签是否存在，不存在就插入，再批量写关联记录。整个过程放在一个事务里，只要一步失败就回滚，不会出现文章有了但标签关联没写进去的情况。建表的时候有两个容易忽略的细节。一是字符集一定要用utf8mb4，否则文章内容里出现表情符号会直接报错。二是时间字段建议用DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP，配合ON UPDATE CURRENT_TIMESTAMP，这样插入和更新都不用手动维护update_time。用现在网上到处都能搜到的经典建表写法，列一个核心表示意：CREATE TABLE article ( id BIGINT AUTO_INCREMENT PRIMARY KEY, user_id BIGINT NOT NULL COMMENT '作者ID', title VARCHAR(200) NOT NULL, content LONGTEXT NOT NULL, summary VARCHAR(500) DEFAULT '', cover_url VARCHAR(500) DEFAULT '', status TINYINT NOT NULL DEFAULT 0 COMMENT '0草稿,1已发布,2审核失败', view_count INT NOT NULL DEFAULT 0, like_count INT NOT NULL DEFAULT 0, comment_count INT NOT NULL DEFAULT 0, create_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, update_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, KEY idx_user_id(user_id), KEY idx_status_create(status, create_time) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;这个idx_status_create(status, create_time)联合索引，是为了首页列表能快速按“已发布”状态和创建时间倒序分页。没有这个索引，数据量上来之后首页会越来越慢。2.2 JWT 认证与权限控制前后端分离项目里，Session 处理起来很别扭，跨域、移动端接入、多实例部署都会遇到麻烦。所以这套源码用了 JWT，登录成功后后端签发一个 token，前端保存起来，每次请求放到 Authorization 请求头里。登录接口做的事情很简单：接收用户名和密码，用 BCrypt 比对数据库里的密码哈希，比对通过后生成 JWT，payload 里放 userId 和 role。注意密码绝对不能明文存，源码里用了 BCryptPasswordEncoder，这是 Spring Security 里自带的标准工具，安全性相对可靠。权限控制这块没有引入整套 Spring Security，而是用拦截器加自定义注解的方式。原因很简单：平台只有普通用户和管理员两类角色，不需要太过复杂的权限体系，拦截器实现起来更轻量，代码也更直观。核心逻辑是在preHandle里取 Token，解析成功后把 userId 放到 request attribute 里，后面 Controller 直接用@RequestAttribute拿到当前登录用户。@Component public class AuthInterceptor implements HandlerInterceptor { @Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { String token = request.getHeader("Authorization"); if (StringUtils.hasText(token) && token.startsWith("Bearer ")) { token = token.substring(7); } try { Claims claims = JwtUtil.parseToken(token); request.setAttribute("userId", claims.get("userId", Integer.class)); request.setAttribute("role", claims.get("role", String.class)); return true; } catch (Exception e) { response.setStatus(HttpStatus.UNAUTHORIZED.value()); response.getWriter().write("{\"code\":401,\"message\":\"登录已过期\"}"); return false; } } }把这个拦截器注册进 WebMvcConfigurer，同时排除/api/auth/login、/api/article/list这些公开接口。这样整个应用的权限边界非常清楚，新增加一个接口时，只要默认走拦截器就行，需要公开的再单独放行。2.3 文章发布、评论与分享的关键实现文章发布是一个高频且容易出错的接口。前端提交 title、content、summary 和 tags，后端 Service 里要先校验标题和内容不能为空，然后开启事务。为什么用事务？因为一次发布要写 article、tag、article_tag 三张表，任何一个写失败都会导致数据不一致。事务让这三个操作要么全部成功，要么全部回滚，在线社区的数据不能出现“文章正文在但标签没了”这种情况。评论列表的查询也有个小技巧。先查顶级评论，查出来之后收集所有顶级评论 ID，再用一次 IN 查询把子评论批量查出来，在后端组装成树形结构。这样做比逐条子评论循环查询少了很多次数据库往返。你如果看到有人写出“循环里查数据库”的评论接口，数据量小的时候没问题，但只要一个热帖有几百条评论，接口延迟就会非常明显。分享功能的实现也值得说一下。这里的分享不是简单复制网页链接，而是有一套独立的记录表。用户点击“分享”后，后端生成一个短码，保存来源文章 ID 和分享渠道，然后返回一个/s/{shortCode}链接。别人打开这个链接时，后端做一次 302 跳转，把访问者导到文章详情页，同时给分享记录加一个点击次数。这样运营就能知道哪些渠道的分享效果更好。还有一个很容易踩坑的点是浏览量统计。最简单的写法是select view_count from article where id = xxx，然后在服务端加一，再update回去。并发情况下这个数字会丢失更新。正确做法是单条 SQL 原子更新：UPDATE article SET view_count = view_count + 1 WHERE id = #{articleId}这样哪怕同时有十个请求进来，数据库自身也能保证累加正确，不需要加锁。3. 前端 Vue3 工程化落地实践3.1 用 Vite 快速初始化前端项目前端部分我最开始拿到的时候还是一个手写配置的 Webpack 项目，后来我直接用 Vite 重新初始化了一遍，迁移非常顺畅。Vite 是基于 ES Module 开发的，冷启动速度快，热更新也流畅，和 Vue3 搭配几乎是当前默认选择。初始化命令很简单：npm create vite@latest frontend -- --template vue然后进入目录安装需要的依赖：npm install vue-router@4 pinia axios element-plus @element-plus/icons-vuevue-router 负责路由，pinia 做状态管理，axios 发请求，element-plus 提供现成组件。这些几乎是 Vue3 全家桶的基础配备。目录结构我习惯按模块切分，而不是按文件类型堆在一起：src/ ├── api/ # 按功能拆分接口请求 ├── assets/ # 静态资源 ├── components/ # ArticleCard、CommentList 等公用组件 ├── router/ # 路由配置 ├── stores/ # Pinia 状态 ├── views/ # 页面级组件 ├── utils/ # 工具函数 ├── App.vue └── main.js为什么一定要把 API 单独放到src/api目录？因为后端接口路径经常变，比如/api/article/page可能改成/api/article/list，如果所有请求都散落在页面组件里，你必须一个个去找。统一放到 api 目录后，只改一个文件里的函数就行。这个习惯在项目变大以后会节省非常多时间。3.2 页面拆分与核心组件设计页面层主要分为首页文章列表、文章详情、个人中心和管理后台。这些页面里的逻辑不难，真正麻烦的是拆分组件。首页拆出一个 ArticleCard 组件，负责展示封面、标题、摘要、作者头像、浏览数、点赞数和评论数。详情页拆出 CommentList 和 ArticleContent，评论列表会递归调用自己来渲染回复，ArticleContent 负责解析 Markdown 内容。这种拆分方式让每个组件职责单一，调试的时候不用在一个大文件里上下翻几百行。Vue3 里写业务逻辑，我比较推荐用<script setup>。以首页加载文章列表为例：<script setup> import { ref, onMounted } from 'vue' import { getArticleList } from '@/api/article' const list = ref([]) const loading = ref(false) const page = ref(1) async function load() { loading.value = true const res = await getArticleList({ page: page.value, size: 10 }) list.value = res.data.records loading.value = false } onMounted(load) </script>这里用ref包住 list，是因为 Vue3 的响应式系统需要被包裹的变量才能触发视图更新。直接写let list = []然后list = res.data.records，页面是不会有任何变化的。对刚入门的同学来说，理解“响应式数据”这一步比理解路由配置更关键。页面之间跳转时，可以用 pinia 保存用户信息。登录成功后把 user 对象和 token 存进 store，同时写入 localStorage。刷新页面时再从 localStorage 恢复，保证用户不会因为按了一下 F5 就丢失登录状态。清除登录状态时，要同时清空 store 和 localStorage，经常有人只清了 localStorage 忘记 store，结果页面还显示旧用户信息，这个坑我踩过好几回。3.3 Axios 封装和跨域联调配置前端所有请求都会经过一个 axios 实例，这个实例负责两件大事：加 token、统一处理错误。项目里的请求封装可以简化成下面这样：import axios from 'axios' import { ElMessage } from 'element-plus' import { useUserStore } from '@/stores/user' import router from '@/router' const request = axios.create({ baseURL: '/api', timeout: 10000 }) request.interceptors.request.use(config => { const userStore = useUserStore() if (userStore.token) { config.headers.Authorization = `Bearer ${userStore.token}` } return config }) request.interceptors.response.use( response => { if (response.data.code !== 200) { ElMessage.error(response.data.message) return Promise.reject(new Error(response.data.message)) } return response.data }, error => { if (error.response?.status === 401) { useUserStore().clearUser() router.push('/login') } ElMessage.error(error.response?.data?.message || '请求失败') return Promise.reject(error) } ) export default request注意这里baseURL写的不是http://localhost:8080，而是简单地写了/api。为什么？因为开发环境下有 Vite proxy 兜底，生产环境有 Nginx 反代，这样代码里就不用按环境切换地址了。Vite 的 proxy 配置在vite.config.ts里：export default defineConfig({ server: { proxy: { '/api': { target: 'http://localhost:8080', changeOrigin: true } } } })这样前端发出/api/user/info请求时，Vite 会自动转发到http://localhost:8080/api/user/info，跨域问题在开发阶段就被解决了。生产环境 Nginx 配置如下：server { listen 80; server_name _; root /path/to/dist; index index.html; location / { try_files $uri $uri/ /index.html; } location /api/ { proxy_pass http://127.0.0.1:8080; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } }location /里回退到/index.html是 Vue Router history 模式的必备姿势，没有这行配置，你在文章详情页按 F5 会直接 404。4. 部署启动与问题排查经验4.1 从零跑通项目的完整步骤很多人拿到源码后第一反应是直接启动后端，结果报一连串错误。正确顺序应该是：先建数据库，再改配置，最后分别启动前后端。第一步，创建数据库并导入初始化 SQL。在 MySQL 里执行：CREATE DATABASE itshare DEFAULT CHARACTER SET utf8mb4;然后导入项目中的init.sql，它会把所有表结构和默认管理员账号都建好。第二步，修改后端配置。重点看application.yml里的数据源信息：spring: datasource: url: jdbc:mysql://localhost:3306/itshare?useUnicode=true&characterEncoding=utf8mb4&serverTimezone=Asia/Shanghai username: root password: your_password jackson: date-format: yyyy-MM-dd HH:mm:ss time-zone: GMT+8这里有两个细节。一是连接串里要带上serverTimezone，否则高版本 MySQL 驱动会报时区错误。二是 Jackson 的时区要设置成 GMT+8，否则前端拿到的时间会比本地时间少八个小时。这两个问题几乎每次新环境部署都会遇到。第三步，启动后端。用 IDEA 直接运行主类，或者命令行执行：mvn spring-boot:run后端启动成功后，先不要急着打开前端，直接在浏览器访问http://localhost:8080/api/article/list，如果能看到 JSON 数据，说明后端已经通了。第四步，启动前端。进入 frontend 目录执行：npm install npm run dev然后访问http://localhost:5173，注册一个账号或者用初始化管理员账号登录，整个项目就完整跑起来了。4.2 常见报错速查表跑项目和联调时，有一些报错反复出现。我整理成了一张表，遇到问题直接照着检查就行。报错/现象原因解决方案连接数据库超时数据库没启动，或账号密码错误检查 MySQL 进程，核对 application.yml 配置中文乱码连接串没指定 utf8mb4在 jdbc url 加characterEncoding=utf8mb4Article list 字段为 nullMyBatis 下划线映射没打开配置map-underscore-to-camel-case: trueInvalid bound statementMapper 接口没被扫描启动类加@MapperScan或接口加@Mapper前端请求 404Vite proxy 没生效或路径不统一确认请求以/api开头，检查 target 地址登录成功但请求 401Token 过期或请求头没带上检查 axios 请求拦截器是否加了 Authorization前端点击跳转刷新后 404Vue Router history 模式缺少后端回退Nginxtry_files $uri $uri/ /index.html;另外还有个很隐蔽的问题：不同电脑上 MyBatis XML 文件的 mapper 路径写死，导致本地找不到对应 namespace。规范的做法是在application.yml里配置mybatis.mapper-locations: classpath:/mapper/*.xml，并且把 XML 文件放在src/main/resources/mapper目录下，不要放在奇怪的包路径里。4.3 二次开发与扩展方向这套源码跑通之后，想把它改造成自己项目，有几个方向值得尝试。第一个方向是做内容推荐。现在的列表只是按时间排序，如果给 article 表加一个热度字段，再写一个定时任务，按浏览量、点赞数、评论数综合计算热度值，就能实现一个“最热榜”。计算逻辑可以用 Spring 的@Scheduled注解，十分钟执行一次，更新热度值。这个功能不复杂，但会让平台看起来更有“社区感”。第二个方向是加 Redis 缓存热门文章列表。首页列表的查询压力最大，把第一页和热门标签对应的文章 ID 列表缓存到 Redis，设置五分钟过期，能显著降低数据库压力。写缓存时注意不要缓存完整对象，可以先缓存 ID，再查数据库补全内容，避免缓存和数据库数据不一致。第三个方向是引入 WebSocket 做在线提醒和私信。评论被回复、文章被点赞时，前端不轮询，而是通过 WebSocket 实时收到通知。实现起来可以先用 Spring 的 WebSocket 模块做一个最简单的握手，前端用new WebSocket()连接，服务端在表扬、评论事件发生时推送一条 JSON。这个扩展会明显提升用户实时交互的体验，也符合“交流和分享平台”本身的产品定位。不管往哪个方向扩展，都要注意基础安全。JWT 密钥不要写在代码里，放到环境变量配置；上线前要修改默认管理员密码；用户提交的富文本内容要做 XSS 过滤。二次开发最容易犯的错就是只关注新功能，忽略了这些底层约束。最后分享一点个人体会。这套系统刚拿到手时，我也习惯性当成“普通毕设”来看，但后来为了改造，把整个数据流追了一遍，才发现真正值钱的东西不在某个酷炫功能，而在每一层之间约定得是否干净。接口统一返回格式、前端统一封装请求、表结构预留 status 状态字段，这些“不起眼”的习惯，才是它能拿来直接二次开发的原因。如果你也想彻底吃透这套源码，我的建议是先不要急着跑，先看 SQL，再跟着一个请求从 Vue 组件一路走到 Mapper 接口，这个过程比看十篇架构文章都管用。