企业官网建设流程全解析

1. 为什么做考研互助交流平台：项目背景与需求拆解

我去年帮一个培训机构做复习管理系统的时候，接触到不少考研学生。他们的需求很集中：找资料、找研友、找经验、问问题。市面上的社交平台信息太杂，论坛又太老，学习群聊两句就被刷屏。说白了，缺一个"围绕考研这件事本身"的垂直互助空间。

这个项目就是奔着这个缺口去的——基于SpringBoot+Vue搭建的考研互助交流平台，后端用MyBatis操作MySQL，前端用Vue做交互。它解决的核心问题有三个：让考研用户能发布和获取复习资料、让用户之间能发起和参与互助话题、让管理员能对内容和用户进行有效管控。

如果你正打算做类似的校园社团平台、兴趣小组社区、校友互助系统，或者纯粹想拿一个"SpringBoot+Vue全栈项目"来练手、写简历、做课程设计，那这个项目的代码结构和设计思路都值得参考。它覆盖了一个完整Web系统从数据库建模到前后端联调的所有关键环节，难度控制在"认真看能看懂、动手能改出东西"的范围，比网上那些只丢个登录注册的demo不知道强多少。

1.1 核心角色与功能全景

整个系统我拆成了三种角色：学生用户、管理员、访客。为什么这样拆，后面数据库和权限部分会说，这里先把功能盘清楚。

学生用户能做的事情包括：

• 注册登录后修改个人资料，维护自己的考研目标院校和专业方向
• 发布求助帖、经验帖，支持富文本编辑和图片上传
• 在他人帖子下回复、点赞、收藏
• 上传复习资料文件，设置下载权限（公开或登录可下载）
• 搜索帖子、按分类筛选、按热度排序
• 私信互助，也就是站内信功能

管理员的功能就是后台管理那一套：

• 用户管理：禁用、启用、重置密码
• 内容审核：帖子审核、评论删除、敏感词过滤
• 数据统计：注册趋势、帖子数量、活跃度排行
• 公告管理：发布首页公告和系统通知

访客，也就是未登录用户，只能浏览帖子列表和部分公开详情页，一旦需要点赞、评论、下载或发帖，全部拦截跳转到登录页。

1.2 从"能跑"到"好用"：这个平台的价值定位

开发这类系统最怕做成"功能堆砌"。我设计的时候始终拿三个问题来卡需求：用户为什么每天要打开它？管理员为什么愿意维护它？这套数据沉淀下来有什么用？

答案就是"信息匹配"——研友之间的匹配、资料与需求的匹配、问题与经验的匹配。所以系统里特意设计了"目标院校"和"专业方向"两个用户属性字段，帖子发布时可以关联标签。首页除了常规的最新、最热，还加了一个"同校推荐"板块，把跟你目标院校一致的用户和帖子往前排。这个细节不需要多高深的技术，但用户粘性一下子就不一样了。懂的人应该能get到，这种"运营思维反推功能设计"的思路，比单纯照着需求文档写CRUD重要得多。

2. 技术选型：SpringBoot+Vue+MyBatis+MySQL这套组合到底好在哪

技术选型这个事，很多人上来就纠结"哪个框架最牛"，但实际项目里考虑的是"哪个组合成本最低、团队最熟、生态最稳"。这个项目定下来用SpringBoot+Vue+MyBatis+MySQL，不是因为它花哨，而是因为它是目前Java全栈开发里综合性价比最高的一套，没有之一。

2.1 SpringBoot做主后端：约定大于配置带来的开发效率

SpringBoot的好处我不用多讲，内嵌Tomcat、自动配置、Starter机制，一套下来省掉了传统SSH时代大量的XML配置。做这个项目的时候，我SpringBoot用的版本是2.7.x，为什么不用3.x？因为不少老年人插件和教程还在用2.x，如果版本太高，集成遇到的坑会多一些，热搜里"springboot版本太高"就是这个意思。3.x虽然性能更好，但包名从javax改成了jakarta，很多老项目迁移会踩坑。这里给出我的建议：课程设计、毕业设计或生产环境求稳的，直接SpringBoot 2.7.18，JDK用1.8或11，依赖兼容性基本不用操心。

核心依赖大致长这样：

<parent> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-parent</artifactId> <version>2.7.18</version> </parent> <dependencies> <!-- Web层 --> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-web</artifactId> </dependency> <!-- MyBatis整合 --> <dependency> <groupId>org.mybatis.spring.boot</groupId> <artifactId>mybatis-spring-boot-starter</artifactId> <version>2.3.1</version> </dependency> <!-- MySQL驱动 --> <dependency> <groupId>mysql</groupId> <artifactId>mysql-connector-java</artifactId> <version>8.0.33</version> </dependency> <!-- 密码加密 --> <dependency> <groupId>org.springframework.security</groupId> <artifactId>spring-security-crypto</artifactId> </dependency> <!-- JWT --> <dependency> <groupId>io.jsonwebtoken</groupId> <artifactId>jjwt</artifactId> <version>0.9.1</version> </dependency> <!-- Lombok省代码 --> <dependency> <groupId>org.projectlombok</groupId> <artifactId>lombok</artifactId> <optional>true</optional> </dependency> </dependencies>

2.2 Vue做前端：组件化和工程化让你一个人顶一个小团队

Vue的核心价值在于组件化和数据驱动。这个项目里我把页面拆成了首页、帖子列表、帖子详情、个人中心、后台管理五个大模块，每个模块内部再拆组件。比如帖子卡片就是一个组件，列表页和"同校推荐"都复用它，只是传入的数据不同。

Vue 2还是Vue 3？我的建议是直接Vue 3 + Vite。Vite的开发服务器冷启动速度极快，HMR热更新也顺滑，对前端调试体验的提升是实打实的。Vue Router用的4.x，状态管理用了Pinia——说实话这个项目的状态共享没有复杂到必须上Vuex，Pinia更轻，API也更简洁。

前端工程的目录结构按下面这样组织：

frontend/ ├── public/ ├── src/ │ ├── api/ # 接口请求封装 │ │ ├── request.js # axios实例 │ │ ├── user.js │ │ ├── post.js │ │ └── admin.js │ ├── assets/ # 静态资源 │ ├── components/ # 公共组件 │ │ ├── PostCard.vue │ │ ├── Pagination.vue │ │ └── Editor.vue │ ├── router/ # 路由配置 │ │ └── index.js │ ├── stores/ # Pinia状态 │ │ └── user.js │ ├── views/ # 页面级组件 │ │ ├── home/ │ │ ├── post/ │ │ ├── user/ │ │ └── admin/ │ ├── App.vue │ └── main.js └── vite.config.js

2.3 MyBatis和MySQL：半自动ORM跟关系型数据库的经典搭配

选MyBatis而不是JPA，最重要的一点是"SQL可控"。考研社区这种系统，查询场景很杂：多表关联、动态条件、分页排序、统计报表，MyBatis能把所有SQL写在自己手里，出了性能问题直接看代码就能定位。JPA虽然开发快，但碰到复杂查询生成的SQL往往不是你想要的，调优时还得回头改JPQL或原生SQL，绕了一圈回来。

MySQL这边，项目用它来做持久化存储，配置了8.0版本，连接串需要带时区参数和SSL关闭参数，否则容易报"mysql ssl连接错误"：

spring: datasource: url: jdbc:mysql://localhost:3306/kaoyan?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai&useSSL=false&allowPublicKeyRetrieval=true username: root password: your_password driver-class-name: com.mysql.cj.jdbc.Driver

allowPublicKeyRetrieval=true这个参数8.0版本必须加，因为新版驱动默认使用RSA公钥加密密码传输，不开这个选项首次连接就会报Public Key Retrieval is not allowed。这个坑我见太多人踩了。

3. 数据库设计：考研社区的帖子、用户、互动关系怎么建模

数据库设计决定系统的上限。代码写得再花哨，表结构一塌糊涂，数据一多就现原形。这个平台我设计了八张核心表，这里把最重要的几张表结构和设计思路交代清楚。

3.1 用户表与扩展信息表：把"考研身份"单独拆出来

用户表用最简单的结构，存登录凭证和通用信息：

CREATE TABLE `t_user` ( `id` bigint(20) NOT NULL AUTO_INCREMENT, `username` varchar(50) NOT NULL COMMENT '登录名', `password` varchar(100) NOT NULL COMMENT 'BCrypt加密后的密码', `nickname` varchar(50) DEFAULT NULL COMMENT '昵称', `avatar` varchar(255) DEFAULT NULL COMMENT '头像URL', `email` varchar(100) DEFAULT NULL COMMENT '邮箱', `role` tinyint(1) NOT NULL DEFAULT '2' COMMENT '角色：1管理员 2普通用户', `status` tinyint(1) NOT NULL DEFAULT '0' COMMENT '状态：0正常 1禁用', `create_time` datetime DEFAULT NULL, `update_time` datetime DEFAULT NULL, PRIMARY KEY (`id`), UNIQUE KEY `uk_username` (`username`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

关键是配套的t_user_profile表，存考研专属信息：目标院校、目标专业、备考年份、已在职或在校、自我介绍。为什么单独拆一张表？因为用户的主查询是登录和列表页，profile信息只在个人主页和"同校推荐"时用到，拆出来避免主表行宽过大，也方便未来扩展其他身份维度——比如以后加"导师评价功能"，再建一张profile扩展表就行，不用动主表。

3.2 帖子表与回复表：一对多关系的两种处理方式

帖子表t_post：

CREATE TABLE `t_post` ( `id` bigint(20) NOT NULL AUTO_INCREMENT, `user_id` bigint(20) NOT NULL COMMENT '发布人', `category_id` bigint(20) DEFAULT NULL COMMENT '分类ID', `title` varchar(200) NOT NULL, `content` text COMMENT '富文本内容', `type` tinyint(1) NOT NULL DEFAULT '1' COMMENT '类型：1求助 2经验', `view_count` int(11) NOT NULL DEFAULT '0', `like_count` int(11) NOT NULL DEFAULT '0', `comment_count` int(11) NOT NULL DEFAULT '0', `status` tinyint(1) NOT NULL DEFAULT '1' COMMENT '状态：1待审 2上线 3下架', `is_top` tinyint(1) NOT NULL DEFAULT '0' COMMENT '是否置顶', `create_time` datetime DEFAULT NULL, `update_time` datetime DEFAULT NULL, PRIMARY KEY (`id`), KEY `idx_category_time` (`category_id`, `create_time`), KEY `idx_user_id` (`user_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

这里有个设计细节：comment_count、like_count这几个冗余字段。很多人开始会纠结"为什么不直接count查出来？"，答案是性能。帖子被评论一次就update t_post set comment_count = comment_count + 1，代价极小；但如果每次列表页都去count评论表，评论一多就是慢查询。这就是典型的"读多写少用冗余换性能"策略。

回复表t_comment是标准的一对多子表，外键post_id指向帖子，存楼层和回复内容。要注意的是我设计了一个reply_id字段，用来支持"回复某人的回复"，实现方式是存被回复评论的id，前端展示时就展示"@xxx回复了xxx"。

3.3 分类表、标签表与帖子标签关联表：垂直社区的灵活筛选机制

考研话题需要细分：数学、英语、政治、专业课、院校信息、复试调剂、二战心得……我用分类表和标签表做两级筛选。

分类表是固定的一级维度，数据量少，后台管理可以维护。标签表是灵活的词云式二级维度，比如"高数十八讲""刘晓艳""调剂经验""复试简历"这种颗粒度。标签支持用户发帖时自由输入，不做严格约束，系统自动按频率排序。

关联表设计上要避免重复干活，很多同类项目会给帖子表直接加tag_ids VARCHAR字段，用逗号分隔。这种设计短平快，但一旦做"点击标签查看所有帖子"就尴尬了。我的建议是老老实实建t_post_tag表，post_id和tag_id联合主键，建索引，5万条帖子量级的关联查询完全够用，毫秒级返回。

3.4 资料文件表：文件上传逻辑与权限控制的数据基础

这个平台的核心价值之一是资料分享，所以t_resource表单独设计：

CREATE TABLE `t_resource` ( `id` bigint(20) NOT NULL AUTO_INCREMENT, `user_id` bigint(20) NOT NULL, `post_id` bigint(20) DEFAULT NULL COMMENT '关联帖子，可为空', `file_name` varchar(255) NOT NULL COMMENT '原始文件名', `file_url` varchar(500) NOT NULL COMMENT '存储路径', `file_size` bigint(20) DEFAULT NULL COMMENT '字节数', `file_type` varchar(50) DEFAULT NULL COMMENT '扩展名', `download_count` int(11) NOT NULL DEFAULT '0', `is_public` tinyint(1) NOT NULL DEFAULT '1' COMMENT '1公开 2仅登录', `create_time` datetime DEFAULT NULL, PRIMARY KEY (`id`), KEY `idx_post_id` (`post_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

文件存哪里？开发阶段本地磁盘就好，配一个upload目录并映射成虚拟路径。生产环境再考虑OSS或者MinIO。这道题的重点是：不要把文件BASE64塞进数据库！有些新手喜欢这么干，觉得好查，但一个5MB的PDF编码后大概能膨胀到7MB，一个月下来数据库能膨胀到几十GB，备份都成灾难。数据库只存元数据，文件走磁盘或对象存储，这是开发常识，把它写进博文供大家参考。

4. 后端实现：登录鉴权、动态SQL和文件上传的完整流程

后端这套，我按"一个请求怎么从浏览器走到数据库再走回来"的逻辑来讲，比按包结构讲解更直观。你吃透这条链路，后面看源码时脑海里就会自动建立坐标。

4.1 JWT登录与拦截器：无状态鉴权怎么落地

社区类系统不需要搞Session共享，用JWT做无状态登录最合适。流程是这样的：

• 用户提交用户名密码，controller接收后通过AuthenticationManager校验
• 校验通过后JwtUtil生成token，token里放userId、username、role三个字段，设置7天有效期
• 登录接口返回token和用户基本信息，前端存到Pinia和localStorage
• 后续请求在axios拦截器里自动加Authorization: Bearer 请求头

后端配一个拦截器，注册时排除登录、注册、首页浏览接口，其余全部校验：

@Component public class JwtInterceptor implements HandlerInterceptor { @Autowired private JwtUtil jwtUtil; @Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { // 放行OPTIONS预检请求 if ("OPTIONS".equalsIgnoreCase(request.getMethod())) { return true; } String token = request.getHeader("Authorization"); if (token != null && token.startsWith("Bearer ")) { token = token.substring(7); Long userId = jwtUtil.getUserId(token); if (userId != null) { // 线程变量传递用户信息，controller里直接取 UserContext.set(userId); return true; } } response.setStatus(401); return false; } @Override public void afterCompletion(...) { UserContext.clear(); } }

拦截器最关键的是UserContext，用ThreadLocal存当前登录用户id，方便service层随时取。但切记afterCompletion里一定要remove，否则Tomcat线程池复用时上次的用户信息会被下一个请求读到——这是我早期线上项目里踩过的严重bug，用户A的评论混到用户B的接口响应里，排查时一脸懵。

4.2 MyBatis动态SQL：复杂场景的搜索和分页怎么写

考研平台最复杂的查询是帖子列表：支持按分类、按标签、按关键词标题或内容、按类型、按时间或热度排序、分页。这种条件组合查询用动态SQL再合适不过。

Mapper接口定义：

IPage<PostVO> selectPostPage(Page<?> page, @Param("query") PostQuery query);

XML里的核心片段：

<select id="selectPostPage" resultType="com.kaoyan.vo.PostVO"> SELECT p.id, p.title, p.view_count, p.like_count, p.comment_count, p.create_time, u.nickname, u.avatar, c.name AS category_name, GROUP_CONCAT(t.name SEPARATOR ',') AS tag_names FROM t_post p LEFT JOIN t_user u ON p.user_id = u.id LEFT JOIN t_category c ON p.category_id = c.id LEFT JOIN t_post_tag pt ON p.id = pt.post_id LEFT JOIN t_tag t ON pt.tag_id = t.id <where> p.status = 2 <if test="query.categoryId != null"> AND p.category_id = #{query.categoryId} </if> <if test="query.type != null"> AND p.type = #{query.type} </if> <if test="query.keyword != null and query.keyword != ''"> AND (p.title LIKE CONCAT('%', #{query.keyword}, '%') OR p.content LIKE CONCAT('%', #{query.keyword}, '%')) </if> <if test="query.tagId != null"> AND EXISTS (SELECT 1 FROM t_post_tag pt2 WHERE pt2.post_id = p.id AND pt2.tag_id = #{query.tagId}) </if> </where> <choose> <when test="query.orderBy == 'hot'"> ORDER BY p.view_count + p.like_count * 5 + p.comment_count * 10 DESC, p.id DESC </when> <otherwise> ORDER BY p.create_time DESC </otherwise> </choose> </select>

有个细节要特别提醒：LEFT JOIN了标签表，如果再 里直接写t.id = #{tagId}，会把LEFT JOIN变成INNER JOIN的效果，因为关联条件被过滤掉了，导致该帖子的其他标签记录也被筛掉后最终可能产生重复行。所以这里用EXISTS子查询来处理标签筛选，既避免重复，又避免JOIN退化。这种细节就是MyBatis面试里常考的"条件不生效"问题——很多新人碰到筛选字段失效，想半天，其实是被JOIN和WHERE的语义迷惑了。

分页我直接用的MyBatis-Plus的PaginationInnerInterceptor，物理分页不会像手写LIMIT那样要拼接字符串，而且自动统计总数。这个项目虽然是MyBatis原生XML写法，但引入MyBatis-Plus只做分页插件，也不冲突。

4.3 文件上传与控制：怎么处理大文件和下载权限

资料文件上传是前端发FormData，后端用MultipartFile接收。三个要点：

第一，大小限制。SpringBoot默认单文件最大1MB，必须改配置：

spring: servlet: multipart: max-file-size: 50MB max-request-size: 100MB

第二，存储策略。文件名用UUID重命名，保留原始扩展名作为type：

String originalFilename = file.getOriginalFilename(); String ext = originalFilename.substring(originalFilename.lastIndexOf(".")); String filename = UUID.randomUUID().toString().replace("-", "") + ext; file.transferTo(new File(uploadDir, filename));

文件名一定要重命名，否则用户上传两个同名的1.pdf，第二次会覆盖第一次的文件，而且中文名在部分Nginx和Linux配置下会有乱码问题。

第三，下载权限。下载接口在controller里先校验登录状态和is_public字段，再通过ResponseEntity返回文件流：

@GetMapping("/download/{id}") public ResponseEntity<Resource> download(@PathVariable Long id, HttpServletResponse response) { Resource resource = resourceService.getDownloadResource(id); return ResponseEntity.ok() .header(HttpHeaders.CONTENT_DISPOSITION, "attachment; filename=" + URLEncoder.encode(resource.getFileName(), "UTF-8")) .contentType(MediaType.APPLICATION_OCTET_STREAM) .body(resource); }

URLEncoder一定要加，不然下载的文件名带中文时浏览器会乱码。原来这里也是一个不起眼但坑人的点。

4.4 事务与异常：多表操作怎么保证一致性

发帖时要做两件事：插入帖子主记录、插入帖子和标签的关联关系。这两步必须在一个事务里。我在service层方法上加@Transactional注解，并且设置了rollbackFor = Exception.class，因为Spring默认只有在throw RuntimeException时才回滚，如果你自定义了一个业务异常继承Exception没设置rollbackFor，事务就不会生效，数据就脏了。

@Transactional(rollbackFor = Exception.class) public void createPost(PostCreateDTO dto) { Post post = new Post(); BeanUtils.copyProperties(dto, post); post.setUserId(UserContext.getUserId()); postMapper.insert(post); // 批量插入标签关联 if (dto.getTagIds() != null && dto.getTagIds().size() > 0) { postTagMapper.batchInsert(post.getId(), dto.getTagIds()); } }

统一异常处理用@RestControllerAdvice，捕获业务异常返回code=500，捕获参数校验异常返回code=400，捕获兜底异常记录日志。别让Spring的默认错误页直接暴露给浏览器，那既难看又泄露堆栈信息。

5. 前端实现：Vue3项目从路由到接口对接的细枝末节

前端这套，我按"路由怎么设计、请求怎么封装、页面怎么渲染"三个维度讲。前端代码不比后端少，甚至踩的坑更多，尤其版本兼容这类问题。

5.1 路由设计：动态路由与权限控制

Vue Router的路由表分两部分。基础路由包括首页、帖子详情、公告列表，这部分人人可访问。需要登录的路由包括个人中心、发帖、管理后台，通过路由元信息标记requiresAuth。

路由守卫里做两件事：判断登录态，判断角色权限。

router.beforeEach((to, from, next) => { const userStore = useUserStore() if (to.meta.requiresAuth && !userStore.token) { next({ path: '/login', query: { redirect: to.fullPath } }) return } if (to.meta.requiresAdmin && userStore.userInfo?.role !== 1) { next({ path: '/' }) return } next() })

很多同类项目做"动态路由"是先在数据库存路由表，再在登录后递归生成，但一个考研互助平台没必要搞这么复杂，静态路由+元信息拦截足够，代码还好维护。如果你因为面试想演示"动态路由"技能，那另说，生产环境我建议On Demand新增页面时再改路由表，别过度设计。

5.2 Axios封装：统一携带Token和统一处理错误码

axios封装的核心是拦截器。请求拦截器加token，响应拦截器统一解包数据并处理错误码：

const request = axios.create({ baseURL: '/api', timeout: 15000 }) request.interceptors.request.use(config => { const userStore = useUserStore() if (userStore.token) { config.headers.Authorization = `Bearer ${userStore.token}` } return config }) request.interceptors.response.use( response => { const res = response.data if (res.code !== 200) { if (res.code === 401) { // token过期跳登录 } ElMessage.error(res.msg || '请求失败') return Promise.reject(new Error(res.msg)) } return res }, error => { ElMessage.error('网络异常，请检查后端服务') return Promise.reject(error) } )

dev环境下baseURL配成/api，然后在vite.config.js里配proxy把/api转发到localhost:8080，这样开发阶段没有跨域问题。生产环境则把打包后的dist丢到Nginx，配一个location /api的代理转发，前端代码一行不用改。

5.3 页面渲染：帖子卡片组件和富文本展示的处理细节

帖子卡片PostCard是前端复用度最高的组件，包含标题、作者头像、标签、时间、浏览量、点赞数、评论数。这里有个前端渲染的性能点：如果列表返回了几百条帖子，每条都附带完整content字段的富文本，初始渲染会卡。所以列表接口特意做了字段裁剪，PostVO只查title、summary、count字段，content只有在进入详情页时才加载。summary是发布时从content里截的前100个纯文本字符保存在帖子表里，这个字段在列表页简直太重要了，能省N多时间。

富文本编辑器，我用的wangEditor 5，中文友好，API清晰，React和Vue都能接。展示时要注意XSS问题：富文本里的script和onclick事件会很危险，需要调用编辑器自带的dangerouslyInsertHtml或者自己写一个白名单过滤。这个平台因为是相对封闭的圈子，我过滤了script标签、iframe和事件属性，写了一个simpleSanitize函数，够用就行。

首页的"同校推荐"是纯前端逻辑——用户个人资料里有目标院校字段，登录后从帖子列表接口拿到当前用户的目标院校，再用一个独立的推荐接口查询同院校的帖子。接口实现不复杂，一条SQL按profile.school字段匹配，加上排序和limit 10。效果却很好，很多用户反馈说"每天打开首页先看同校动态"。

6. 部署与排查：从本地联调走到服务器上线，这几关必须过

代码写完了，不等于项目完成。我这部分专门讲部署上线过程中避不开的坑，都是实际项目中反复出现的高频问题。

6.1 跨域问题与开发代理

前后端分离，本地联调时跨域是头号问题。解决方案我推荐两个：

开发环境用vite proxy，生产环境用Nginx反向代理。这两种方式的好处是浏览器始终访问同源，Token不会因为跨域丢失，也不需要后端额外配置CORS。如果你的团队坚持后端开CORS，注意allowedHeaders不能是*，因为带Authorization请求头时浏览器会先发OPTIONS预检，后端必须处理OPTIONS请求并回带响应头。

6.2 MyBatis二级缓存：这个坑我劝你别踩

MyBatis的二级缓存用好了能提升查询性能，但这个项目里我关闭了二级缓存。原因很简单：跨Mapper的关联查询缓存同步太难保证。

举个例子：帖子详情接口查了帖子、作者、评论、标签合计四次查询，分属三个不同的Mapper namespace。如果只给PostMapper配了二级缓存，评论表更新了评论，CommentMapper里的缓存flush是清不到PostMapper缓存区里的，那个帖子的缓存还会返回旧评论数据。这种"缓存数据和数据库不一致"的问题，排查起来比性能问题痛苦多了。

我的建议是：学习阶段把二级缓存机制搞明白，项目中保持谨慎，默认关闭。那些mybatis面试题里问"一级缓存和二级缓存区别"的小伙伴，答案背熟就可以了，实战中能正确判断"什么时候不开缓存"比"什么时候开缓存"更重要。

6.3 MySQL字符集和排序规则

create table时如果没指定charset，默认继承MySQL实例配置。很多本地Windows装MySQL默认是latin1，存中文直接乱码或者"???"。我建库时统一用：

CREATE DATABASE `kaoyan` DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;

为什么用utf8mb4而不是utf8？MySQL里的utf8是utf8mb3，只能存基本多语言平面字符，遇到emoji、特殊符号就报错"Specified key was too long"或存储异常。现在考研交流群里学生动不动就发个表情包当昵称，utf8mb4必须安排。

排序规则的话我用utf8mb4_general_ci，性能略好于unicode_ci，对中文支持也够。如果你想按拼音排序或大小写不敏感更严格，可以换utf8mb4_unicode_ci，看需求。

6.4 服务器部署：Maven构建、Nginx和进程守护

部署流程整理成一套顺手的过程：

• 本地mvn clean package打出jar包，Windows环境下先装MySQL并完成初始化（如果服务器在Windows，注意防火墙放行3306端口，否则外部连接不上）
• 通过scp或宝塔面板把jar包和前端dist传到服务器
• 后端用systemd服务管理，守护进程、崩溃自动重启、开机自启都靠它，比nohup靠谱得多

systemd服务文件示意：

[Unit] Description=kaoyan-backend After=network.target mysql.service [Service] ExecStart=/usr/bin/java -jar /opt/kaoyan/app.jar --spring.profiles.active=prod Restart=always RestartSec=5 User=kaoyan Group=kaoyan Environment=SPRING_DATASOURCE_PASSWORD=某个指定密码 [Install] WantedBy=multi-user.target

这里有个小坑：数据库密码写在systemd的Environment里比写在application-prod.yml里安全一点，因为yml经常会被别人拷走，而systemd服务文件默认只有root可读。我在杀软和运维层面都做了例子，具体场景自行评估即可。

生产环境MySQL我用的是8.0，CentOS上安装的话可以采用官方仓库方式。安装完记得运行mysql_secure_installation做初始安全配置，然后单独建一个业务账号，不要把root密码直接给Java应用连，至少算一个安全底线。

前端dist打完包放到Nginx的html目录，配置：

server { listen 80; server_name your_domain; root /opt/kaoyan/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; } }

try_files那一行是SPA（Vue单页应用）部署的核心，否则刷新页面时Nginx会返回404，因为浏览器请求的是一个不存在的磁盘路径。这个配置不写，很多人刷新一个二级路由就直接白屏，非常典型。

6.5 安全加固：防外漏的基本功不丢

用户密码用BCrypt加密存储，不用MD5，因为MD5彩虹表一查就破。Spring Security Crypto库提供了BCryptPasswordEncoder，这个我记得当时直接拿来用没有任何额外成本。

SpringBoot的Actuator在生产环境要关闭或限制访问，暴露端点会让别人看到你的健康状况、配置项甚至上下线接口。防止端口信息被扫出来，生产环境建议管理员接口单独一个上下文路径，管理员登录取判断。

再一个就是别忘了给生产环境改默认的管理员账号密码，这个项目初始管理员的username和password如果被谁在源码包里看到了，上线后不马上改就会炸。

7. 源码结构阅读指南与二次开发方向

如果你拿到的源码是压缩包，或者从github上下载了demo而看不懂从哪下手，我按"先看哪、再改哪"给你一个阅读路径。

7.1 代码结构怎么读最有效率

后端包结构一般遵循controller-service-mapper-entity分层。我建议阅读顺序：

• 先看application.yml，了解端口、数据库配置、文件上传路径
• 再看entity实体类，理解每个字段的含义，对照着看数据库表结构
• 然后看mapper.xml，把"页面功能"和"SQL语句"对应起来
• 最后看controller，理解一个前端请求是怎么进入后端的

实体类用Lombok注解会大量简化代码，比如@Data注解自动生成getter/setter，@Builder支持链式调用。不要看到代码没有setter方法就觉得奇怪，这是Lombok压掉了样板代码。如果你在IDE中看到红色的编译错误，先装Lombok插件并开启annotation processing。

前端阅读顺序反过来，从router/index.js开始，先知道有哪些页面，再点进具体页面的api文件看调了哪些后端接口，最后看views目录和components目录。

7.2 可做二次开发的方向

这个平台做成后不算终点，有几个方向我实际评估过，给想继续拓展的同学参考：

• 增加积分体系：上传资料获得积分、下载消耗积分、每日签到送积分。对应改t_user加score字段，再加一张t_score_log流水表。这是社区运营的常见套路，能让资料分享的积极性明显提升
• 接入WebSocket实现在线聊天，考研互助群从"刷帖子"升级成"即时沟通"。SpringBoot集成WebSocket不难，Vue端用原生WebSocket对象就行，就是心跳检测和断线重连要写稳
• 考研资料在线预览，比如PDF转图片或者用前端组件直接渲染。热点里"vue image能显示pdf吗"说的就是这类需求，实际做法是引入vue-pdf-embed做PDF预览，但要注意浏览器兼容和分页加载性能
• 管理员加数据统计图表，SpringBoot后台定时汇总数据，前端用ECharts画折线图和饼图。考研报名人数趋势、热门院校排行这种东西展示出来会很有说服力

7.3 学习型项目的复盘建议

不管你是为了课程作业还是面试项目，做完之后一定要能回答这几个问题：登录token过期怎么处理？分页查询的性能瓶颈在哪？缓存和数据库一致性怎么做？富文本XSS怎么防？文件上传为什么不建议存库？这些如果张口就来，面试官对你的项目评价会直接上一个台阶。

我自己带过好几个实习生和徒弟，发现一个共性：角色权限、帖子发布这些核心功能大家都能写，但问到底层"为什么"就含糊。比如动态SQL的where条件为什么用 不直接用字符串拼接？因为 会根据参数动态包含SQL片段，字符串拼接会导致SQL注入和语法错误。再比如JWT为什么适合微服务但小程序里要注意token长度？因为header携带大token可能超限。这些问题不是刁难，是区分"会写代码"和"理解系统"的分水岭。

8. 实际操作中的体会和最后几条建议

整个考研互助交流平台从设计到跑通，我前后大概花了一个月左右，每天抽几个钟头写。说实话，平台本身的CRUD并不复杂，真正花时间的地方都在细节：事务要不要回滚、缓存要不要开、跨域怎么配、上传目录权限能不能写、Nginx配置刷新页面会不会404，这些零散的坑单拎出来每一个都小，叠在一起就是小白劝退路。

我个人在实际操作中的体会是，做全栈项目最困难的不是某一门技术，而是"上下文切换"——早上还在JVM里调接口排错，下午就跑到Vue组件里调样式，晚上又在bash里debug systemd。所以强烈建议用笔记工具把每种环境的坑记录下来，尤其那些报错关键词，比如mysql ssl连接错误、springboot版本太高这种，下次直接搜自己的笔记就知道怎么处理，不用重新踩一遍。

最后再分享一个小技巧：把前后端项目都放到一个Git仓库里，用backend和frontend两个目录区分。这样改后端时提交一次、改前端时提交一次，历史记录里能清晰看出每个功能的演变过程。如果项目要写进简历，把README写得多一点，把架构图、功能清单、启动步骤都写清楚，面试官看到的第一印象会好很多。

技术栈本身只是工具，真正有含金量的是你在这个项目里解决问题过程中形成的判断力。把这个平台做完、吃透每个报错背后的原因，你再去写任何类似的SpringBoot+Vue社区类项目，都会轻松很多。