第三世界的妖孽记得去年开学前，学科部的老师说想换个网站——旧的还是十年前的风格，信息更新要靠学生会手工挂到论坛里。我当时接需求的时候，脑子里第一个方案就是“springboot信息学科部校园网站”这么个东西：SpringBoot管后端数据和权限，Vue做前端页面，一套标准的前后端分离结构。做完之后发现，这类校园网站看着不起眼，但真正上手时会遇到跨域、文件上传、权限控制、部署打包一整套问题，踩一遍坑下来比看十遍教程都有用。
这篇文章我就把整个项目的搭建过程完整复盘一遍，从需求拆解、表结构设计、后端接口、前端Vue实现到最后的部署上线，尽量把我当时卡住的地方和取舍逻辑都写出来。你如果正在做毕设，或者要给学院、社团、部门搭一个类似的展示型网站，这篇可以直接当参考。文中涉及的代码都是实际跑过的版本，SpringBoot用的2.7系，Vue用的2.6加Element UI，这是目前校园项目里最稳妥的组合。
1. 为什么我用SpringBoot加Vue来搭学科部网站，而不是直接套模板
1.1 校园网站的真实需求：信息展示为主，管理后台为辅
很多同学一听到“校园网站”就觉得要做得像门户一样复杂，实际上学科部网站的核心需求就三块：
第一块是对外展示：学科部的最新动态、通知公告、学科竞赛信息、教师团队介绍、课程资料下载。这部分是访客（学生和老师）看得见的内容，占了90%的访问量。
第二块是后台管理：部里的老师或学生干部需要一个管理界面，能发布文章、更新公告、上传文件，不需要懂代码，打开浏览器就能操作。
第三块是用户系统：不一定需要复杂注册，但至少要支持管理员登录，区分普通学生和管理员身份，有些内容比如课程作业、内部资料要登录后才能看。
想清楚这三点之后，你再去选技术方案就很简单了。纯静态HTML做不了后台管理，用现成CMS（比如WordPress）需要部署PHP环境而且定制麻烦，最后确定用SpringBoot负责接口和数据，Vue负责页面渲染和交互，前后端各管各的，分工明确。
1.2 技术栈选择不是跟风，是算清楚这笔账
项目标题里带了SpringBoot和Vue，但我选这两个不是因为网上教程多，而是它们恰好满足这个项目的三个硬性要求。
后端用SpringBoot，理由是：
- 开发效率高。一个学科部网站的接口无非就是用户登录、文章增删改查、文件上传，这些在SpringBoot里都有现成的起步依赖（Starter），拿来即用。
- 生态成熟。JWT认证、MyBatis-Plus操作数据库、文件上传配置，每一块都有稳定方案，不会卡在底层细节上。
- 部署方便。最终打包成一个可执行的JAR文件，丢到服务器上就能跑，对没有专业运维老师的学科部来说，维护成本最低。你要是用SSM那套老框架，光xml配置就能劝退一半人。
前端选Vue，理由是：
- 学习曲线平缓。Vue的模板语法接近HTML，一个没系统性学过前端的学生也能在几天内上手写页面。
- 组件化适合后台管理。后台很多页面长得很像：一个表格、一个表单、一个搜索框，用Vue组件封装以后，新增一个管理页面只需要少量代码。
- Element UI铺路。Vue配合Element UI组件库，后台管理界面几乎是“拼积木”，不需要自己写CSS样式。
你可以把这两个技术理解成：SpringBoot是后厨，负责切菜炒菜；Vue是餐厅前场，负责摆盘上菜。前场换装修不影响后厨做菜，后厨换菜单也不影响前场端盘子，这就是前后端分离最大的价值。对于学科部网站这种需求会不断微调（比如今天加个“竞赛获奖”栏目，明天加个“下载专区”）的项目来说，这种松耦合的关系非常重要。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 先把地基打牢：项目结构、数据库表与接口约定
2.1 前后端项目目录怎么摆才不乱
项目一开始如果目录乱，后面哪怕加了再多的功能也会很难维护。我当时直接建了两个根目录：server放SpringBoot后端，client放Vue前端。两个项目独立运行、独立开发。
后端的包结构是按功能模块分，而不是按技术层分。这个原则很关键，尤其对后面要加功能的情况来说。
code复制com.campus.info
├── controller // 放接口，只做参数接收和结果返回
├── service // 业务逻辑层
├── mapper // MyBatis-Plus的数据访问接口
├── entity // 数据库对应的实体类
├── dto // 接口接收参数的对象
├── vo // 接口返回给前端的对象
├── config // 配置类（拦截器、跨域放行、静态资源映射）
├── utils // 工具类（JWT生成与解析、结果包装）
└── exception // 全局异常处理
前端目录按页面和组件拆分：
code复制client/src
├── api // 所有接口请求封装，按模块分成user.js、article.js等
├── router // 路由配置文件
├── store // Vuex状态管理
├── views // 页面级组件，比如Home.vue、ArticleList.vue、AdminLogin.vue
├── components // 通用的小组件，比如ArticleCard.vue、Pagination.vue
├── utils // request.js（Axios封装）、auth.js（token存取）
└── styles // 全局样式
这个结构的好处是：后端的controller层只写接口，不要在里面写业务代码；前端的api目录只放请求定义，页面组件里不要直接写axios.get。这样后续排查问题时，你能很快定位到出问题的地方——接口报错就查controller和service，页面显示不对就查views和api，分工清楚，不会两个地方互相猜。
2.2 核心表设计：用最少的表覆盖最常见的需求
校园网站的数据量不大，完全没必要设计一张庞大的数据库表。我当时就设计了四张核心表，差不多覆盖了全部业务需求。
第一张是用户表。字段包括id、username、password、real_name、role（管理员或普通用户）、avatar、create_time。密码存的是BCrypt加密后的散列值，注意一定不能存明文，这个是底线。role字段用字符串就行，比如ADMIN和USER，简单直接，不需要额外建角色表。
第二张是栏目表。学科部网站的新闻是分类别的，比如“学部动态”、“通知公告”、“竞赛信息”、“学术讲座”。栏目表就建两个关键字段：name（栏目名称）和sort（排序值），再加一个id就够了。为什么单独立一张表而不是在文章表里硬写一个枚举？因为栏目是会变的，今天有“竞赛信息”，明天可能就要加“考研经验”，放在数据库里老师自己就能改，不用改代码。
第三张是文章表，这是整个项目最核心的表。字段包括：id、title、content（正文，用TEXT类型存富文本）、cover（封面图路径）、category_id（关联栏目表的id）、author_id（发布者的用户id）、view_count（浏览次数）、publish_time（发布时间）。设计文章表时尤其要注意两个点：一是content用TEXT而不是VARCHAR(255)，因为新闻内容肯定超过255个字符；二是要加category_id的索引，后面列表查询会频繁按栏目过滤。
第四张是教师信息表。学科部网站通常要展示教师团队，字段有name、title（职称）、photo（照片路径）、research_direction（研究方向）、intro（个人简介）。这块相对简单，就是一个纯展示的数据维护。
建表SQL我用MyBatis-Plus的代码生成器跑出来的，没有手写太多。有一点提醒一下：所有表都加上create_time和update_time两个字段，虽然有的场景用不上，但一旦要排查数据问题或者后续做数据统计，这两个字段能救命。
2.3 接口返回格式统一：避免前后端联调时各自猜测
前后端刚联调时，最烦的就是接口返回格式不统一：这个接口返回数组，那个接口返回对象，前端取数据的时候总是要各种判断。所以项目一开始就要定一个统一的返回格式。
我当时的统一结构是：
json复制{
"code": 200,
"message": "success",
"data": {}
}
后端用一个通用Result类包装所有接口的返回值，前端Axios拦截器里统一判断code。所有查询接口的data要么是对象，要么是数组，要么是分页结构（包含records和total），不会出现第三种情况。这一点先约定清楚，前后端联调能省一半时间。
3. 后端主战场：认证、内容管理、文件上传一个不少
3.1 基于JWT的登录认证：用拦截器而不是Spring Security
学科部网站的用户量小，权限控制很简单，我用的是JWT加HandlerInterceptor的组合，没有引入Spring Security。为什么不用Spring Security？因为它学习成本高，配置复杂，对这个项目来说属于杀鸡用牛刀。拦截器加JWT是校园项目里最轻量又能满足需求的组合。
JWT登录的完整流程是这样的：
- 用户提交用户名和密码。
- 后端用BCrypt算法校验密码是否正确。
- 校验通过后，生成一个JWT字符串，把用户的
id和role放在token里，设置24小时过期时间。 - 前端拿到token存到
localStorage，以后每个请求都在请求头里带上Authorization: Bearer <token>。 - 后端写一个拦截器，拦截
/api/**下的所有请求，校验token是否有效，并把token里解析出的用户信息放到request对象里，方便后续接口直接取当前用户。
核心实现大致是这样：
java复制@Component
public class JwtInterceptor implements HandlerInterceptor {
@Override
public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception {
// 如果是预检请求，直接放行
if (HttpMethod.OPTIONS.equals(request.getMethod())) {
return true;
}
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"));
request.setAttribute("role", claims.get("role"));
return true;
} catch (Exception e) {
// token无效，返回401
response.setStatus(401);
response.setContentType("application/json;charset=UTF-8");
response.getWriter().write(JSON.toJSONString(Result.error(401, "登录状态已失效")));
return false;
}
}
response.setStatus(401);
response.getWriter().write(JSON.toJSONString(Result.error(401, "未登录")));
return false;
}
}
写登录认证时有一个很容易忽略的点：拦截器里要放行登录接口本身、静态资源和前端页面。我当时第一次配拦截器，把/api/auth/login也拦截了，结果前端一直报401，排查半天才反应过来是拦截规则写成了拦截所有请求。
配置拦截规则时我是这样写的：
java复制registry.addInterceptor(jwtInterceptor)
.addPathPatterns("/api/**")
.excludePathPatterns("/api/auth/login", "/api/auth/register")
.excludePathPatterns("/api/article/list", "/api/article/detail/**", "/api/category/list");
公开展示的接口放在排除列表里，需要登录才能操作的接口（发布文章、修改公告、上传文件）默认被拦截，这样一套规则下来权限控制就很清楚。
3.2 新闻公告模块：CRUD之外要注意的两个细节
新闻公告是整个网站数据量最大的模块，本质上就是增删改查，但有两个细节值得单独说。
第一个细节是分页查询的设计。学科部的文章数量可能一年也就两三百篇，但前端页面仍然需要分页，因为用户浏览习惯是“每页10条，翻页看”。分页参数我用的是currentPage和pageSize，MyBatis-Plus的Page对象直接接收，然后按publish_time倒序排序。同时要支持按栏目筛选，所以查询条件里要有categoryId，这些都写在一个ArticleQuery对象里，接口统一接收。
第二个细节是浏览量的更新。浏览量不是每次请求详情页就简单view_count + 1，因为刷新页面也会加一，数据就不准了。我当时的简单做法是：同一个用户5分钟内浏览同一篇文章只加一次。实现方案是记录用户id和文章id到一个Set里，5分钟后清空。不做持久化，就是内存中的简单去重。这个逻辑虽然不完美，但应对校园网站的规模完全够用。
发布文章的接口有个技术点要提一下：前端传过来的文章内容是一个富文本HTML字符串，直接用@RequestBody接收就行。但是展示详情页时要小心XSS问题。我自己的实践是：后台只有可信的管理员能发布文章，普通用户没有发布权限，所以没有做特别严格的XSS过滤。如果开放评论功能，就一定要引入过滤框架，否则很容易被人塞进恶意脚本。
3.3 文件上传：本地存储加静态资源映射
学科部网站的上传需求主要是两块：发布文章时上传封面图，更新教师信息时上传照片。我没有接阿里云OSS或腾讯云COS，原因很简单——校园项目的访问量小，而且没有运维人员管理云资源，本地存储加备份就能满足需求，还不用花钱。
SpringBoot里配置本地文件上传要做三件事：
第一，配置上传路径。我是在application.yml里加了一个自定义配置：
yaml复制file:
upload-dir: /home/campus/upload/
access-path: /files/**
第二，注册静态资源映射，让前端能通过URL访问上传的图片：
java复制@Configuration
public class WebConfig implements WebMvcConfigurer {
@Value("${file.upload-dir}")
private String uploadDir;
@Override
public void addResourceHandlers(ResourceHandlerRegistry registry) {
registry.addResourceHandler("/files/**")
.addResourceMapping("/files/**")
.addResourceLocations("file:" + uploadDir);
}
}
第三，写上传接口。接受MultipartFile，用UUID生成文件名避免重名，保存到指定目录后返回文件的访问路径。
这段配置里最容易出错的地方是路径最后忘了加斜杠。我之前就因为没有在upload-dir末尾加/，导致保存文件时报路径不存在。Windows和Linux的路径分隔符也不一样，上传目录这种配置一定要用统一的写法，推荐用Paths.get()来拼接而不是手动写死斜杠。
4. 前端Vue实战：路由、请求封装和页面组件
4.1 路由设计：用静态路由加导航守卫
Vue Router是前端项目的地基。我一开始考虑过动态路由（根据后端返回的菜单动态生成），后来评估了一下，学科部网站的菜单很固定——首页、学部动态、通知公告、竞赛信息、教师团队，后端返回菜单意义不大，所以最终用静态路由配合导航守卫的方案。
前端有几种页面要区分清楚：
- 公开页面：首页、文章列表、文章详情、教师列表，游客可以看。
- 需要登录的页面：后台管理首页、文章管理、栏目管理、用户信息。
- 仅管理员页面：用户管理、系统设置。
导航守卫就是根据当前用户登录状态和role字段判断能不能进入某个路由。我写了一个beforeEach钩子：
javascript复制router.beforeEach((to, from, next) => {
const token = getToken();
if (to.meta.requiresAuth && !token) {
next('/login');
return;
}
if (to.meta.requiresAdmin && getRole() !== 'ADMIN') {
next('/403');
return;
}
next();
});
路由配置里给每个页面标注好meta信息：
javascript复制{
path: '/admin',
component: Layout,
meta: { requiresAuth: true },
children: [
{ path: 'articles', component: ArticleManage, meta: { requiresAdmin: true } }
]
}
这个方案的好处是直观、好维护。菜单调整只改前端路由表就行，不需要后端配合。
4.2 Axios封装：统一处理token、错误提示和加载状态
前端和后端打交道全靠Axios，但实际开发中千万不要在每个页面里直接写axios.get(url)，那样会让错误处理、token携带、加载状态变得非常混乱。我用一个request.js文件把Axios实例统一封装。
核心是三个拦截器功能：
第一个是请求拦截器，每次请求前把token加到请求头里：
javascript复制service.interceptors.request.use(config => {
const token = getToken();
if (token) {
config.headers['Authorization'] = 'Bearer ' + token;
}
return config;
});
第二个是响应拦截器，统一处理后端返回的数据：
javascript复制service.interceptors.response.use(
response => {
const res = response.data;
if (res.code !== 200) {
Message.error(res.message);
return Promise.reject(new Error(res.message));
}
return res.data;
},
error => {
if (error.response && error.response.status === 401) {
// token过期，清除本地存储并跳转登录页
removeToken();
router.push('/login');
}
Message.error(error.message || '网络异常');
return Promise.reject(error);
}
);
第三个功能是全局加载状态。我在拦截器里维护一个计数器，请求开始加一，请求结束减一，大于0时显示一个全局的loading动画。这样页面里大量并发请求的时候，loading状态不会闪来闪去。
封装完成后，页面里调用接口的代码会变得非常简洁：
javascript复制import { getArticleList } from '@/api/article';
const data = await getArticleList({ categoryId: 1, page: 1 });
this.articles = data.records;
4.3 页面组件设计：首页、列表页、详情页和后台管理
前端的页面展示部分，我用几个典型页面来说说实现思路。
首页是最能体现一个网站质感的页面。我把它分成三个区域：顶部Banner轮播放学科部的重大新闻或活动海报，中间是“最新动态”和“通知公告”两个榜单栏目，底部是学科部的简介和联系方式。首页通过调用接口获取每个栏目的最新5篇文章，数据量小，所以不涉及分页。
文章列表页处理逻辑比较统一：接收一个categoryId参数显示对应栏目的文章，按发布时间倒序展示，底部是一个分页组件。做列表页时要注意空数据状态，我曾经拿一个空栏目测试，结果页面白屏，报错原因是数组长度为0时模板还在访问第一条记录的字段。后来统一加了v-if="list.length > 0"的判断，这个坑才算彻底解决。
文章详情页相对简单，但有一个体验上的小细节：正文显示的富文本内容是带HTML标签的，Vue里要用v-html渲染。用v-html必须注意XSS风险，我的处理是后端接口对文章内容做了简单的标签白名单过滤，后端管理端本身是可信人员操作的，所以基本没有风险。为了防止样式污染，我在详情页加了scoped样式，避免了正文样式影响全局。
后台管理页面是整个前端代码量最大的部分。文章管理页面用Element UI的el-table展示文章列表，el-dialog嵌套表单实现新增和编辑。编辑文章用的富文本编辑器，我选的是vue-quill-editor，支持图片上传到后端，整体效果比较轻量，适合校园项目的需求。
后台管理的表格分页我踩过一个坑：搜索条件变化后要重置页码。刚开始点击第二页搜索，搜索结果仍然停留第二页，如果第二页没有数据就会显示空。后来在搜索按钮的点击事件里强制把currentPage重置为1，这个问题就解决了。这种逻辑属于前端业务细节，但实战中几乎一定会遇到。
5. 联调、部署以及我在这个项目里踩过的坑
5.1 跨域问题：前后端联调的第一道坎
前后端分离项目开发阶段几乎都会遇到跨域问题。前端跑在本地8080端口，后端跑在8080端口，端口不同就是跨域。解决办法有两个：
第一种是后端SpringBoot配置跨域放行。用CorsFilter是通用做法：
java复制@Configuration
public class CorsConfig {
@Bean
public CorsFilter corsFilter() {
CorsConfiguration config = new CorsConfiguration();
config.addAllowedOriginPattern("*");
config.addAllowedMethod("*");
config.addAllowedHeader("*");
config.setAllowCredentials(true);
UrlBasedCorsConfigurationSource source = new UrlBasedCorsConfigurationSource();
source.registerCorsConfiguration("/**", config);
return new CorsFilter(source);
}
}
第二种是前端开发环境配置Proxy代理。在vue.config.js里：
javascript复制module.exports = {
devServer: {
proxy: {
'/api': {
target: 'http://localhost:8080',
changeOrigin: true
}
}
}
};
我建议开发阶段用前端的Proxy方案，因为生产部署时（后端和前端最终在同一域名下）不需要跨域配置，而开发阶段用Proxy代理还能顺带模拟生产环境的同源请求，更贴近真实场景。如果开发时就让后端开跨域，等部署时反而要记得关掉，容易漏。
5.2 打包部署：Vue构建产物和SpringBoot JAR的搭配方式
部署这一步，我有两种推荐方式，根据你有没有独立的服务器来选。
方式一是前后端分离部署。Vue项目执行npm run build生成dist目录，用Nginx托管静态文件，接口请求通过Nginx反代到SpringBoot的8080端口。这样前端的静态资源和后端的JAR互不干扰，上线以后前端可以不重启，后端更新时也不会影响静态资源，是目前最规范的做法。
方式二是合并部署。把Vue的dist目录里的文件复制到SpringBoot的src/main/resources/static目录下，打包成一个JAR文件。这样只要服务器上跑一个JAR就能访问整个网站，对校园项目这种小规模场景来说管理成本最低。如果你做毕设答辩，现场演示时用一个JAR启动整个项目，也会让老师觉得结构清晰。
我当时用的就是方式二。需要注意一个问题：Vue打包后资源路径默认是根路径/，如果SpringBoot里项目没有配置server.servlet.context-path，那就没什么事。如果项目配置了context-path比如/campus，那Vue里所有静态资源的路径都会404。处理办法是在vue.config.js里配置publicPath: process.env.BASE_URL，并且在生产环境设置publicPath: '/campus/'。
部署过程中还有一个容易漏的配置：生产环境JAR包里的静态资源管理。SpringBoot默认把static目录下的文件当静态资源处理，你不用做额外配置。但如果前端用了路由的history模式（路由地址不带#），刷新页面时会404，因为SpringBoot找不到对应的后端路由。解决方法是写一个Controller做页面转发：
java复制@Controller
public class PageForwardController {
@RequestMapping(value = {"/", "/index", "/home", "/article/**", "/teacher/**"})
public String forward() {
return "forward:/index.html";
}
}
这个坑很多第一次做前后端分离项目的人都会踩：部署后点页面一切正常，一按F5刷新就白屏。如果你决定只用hash模式（路由地址带#），就不会有这个问题，但体验上略差，我建议还是配置好history模式。
5.3 几个值得认真记下来的坑
项目做完后，我整理了几个当初卡得比较久的问题，这里都写出来供你参考。
第一个坑是数据库方言问题。MyBatis-Plus在查询时如果实体字段是驼峰命名，默认会自动转换为下划线命名，比如realName会被转成real_name。如果你的表字段本来就叫realName（没有下划线），查询结果就会是null。我当时有一张旧表字段全是驼峰命名，排查了很久才发现是这个映射问题，解决办法是配置map-underscore-to-camel-case: false，或者统一建表时都按下划线命名。总之，表字段风格要统一，要么全驼峰，要么全下划线，不要混。
第二个坑是日期格式问题。后端返回的LocalDateTime默认序列化成类似2025-05-01T10:30:00的格式，这跟前端想显示的“2025年05月01日”差距很大。我当时后端统一配置了Jackson的日期格式化：
java复制@Bean
public Jackson2ObjectMapperBuilderCustomizer customizer() {
return builder -> {
builder.serializers(new LocalDateTimeSerializer(DateTimeFormatter.ofPattern("yyyy-MM-dd HH:mm:ss")));
builder.deserializers(new LocalDateTimeDeserializer(DateTimeFormatter.ofPattern("yyyy-MM-dd HH:mm:ss")));
};
}
这个配置不会写的话，前端每个地方都要写格式化函数，非常麻烦。
第三个坑是文件上传大小限制。SpringBoot默认的单文件大小上限是1MB，发布文章时上传一张手机拍的封面图很容易超限，直接报错。如果你不做自定义异常处理，前端会收到一个很难看的错误页。解决办法是在配置文件里调大限制，并加上全局异常处理：
yaml复制spring:
servlet:
multipart:
max-file-size: 20MB
max-request-size: 50MB
同时写一个全局异常类捕获MaxUploadSizeExceededException，向前端返回一个友好的提示消息，说清“文件太大，请上传小于20MB的图片”，而不是返回一大堆堆栈信息。
写在最后：如果让我重做一次，我会在这些地方优化
项目上线后跑了接近一个学期，整体功能都稳定，但复盘时我也发现了几个可以优化的点，留给准备做类似项目的你参考。
权限控制如果后续要加“老师录入成绩”、“学生提交作业”之类的功能，简单的拦截器加角色判断就不够用了，建议升级成基于注解的权限校验，比如自定义一个@RequireRole("ADMIN")注解，用AOP实现校验，代码会更优雅。目前这个规模用拦截器完全合适，不用提前过度设计。
数据统计方面，学科部网站上线后最常被问的问题是“哪个栏目访问最多”“哪篇新闻最受欢迎”。我当初只存了view_count字段，没有做按时间维度的统计，导致期末做汇报时还得从数据库临时拉数据。如果你希望网站数据能生成简单报表，建议加一张访问日志表，记录每天各个栏目的浏览量，一个月之后你就能看到哪类内容最受学生关注，这个数据对学科部来说其实很有价值。
缓存方面，文章首页和热门文章列表不用每次请求都查数据库，目前数据量小看不出来什么问题，但如果微课视频、教学资源这类内容放上来之后，热数据会明显增加。建议对首页数据和栏目列表加@Cacheable缓存，用Redis或者简单的本地缓存都行，能够让接口响应急速下降。学科部网站虽然不大，但加了缓存后在大活动期间顶住集中访问的压力会轻松不少。
最后一点是代码里的日志规范。开发阶段我用System.out.println调试，上线前才发现操作日志完全没有记录，老师删了一篇文章出了问题都不知道是谁删的。后来补了字段级的操作日志记录，但那时候补就是额外的返工了。建议从一开始就在关键操作（发布、编辑、删除、登录）上加上日志输出，用@Slf4j注解加log.info()，至少记录操作人、操作时间、操作内容。等你真正去排查线上问题的时候，就会感谢自己当初加的那几行log日志。
学科部校园网站这个项目，技术难度不算高，但它把主流Java后端开发里最常遇到的那些问题都覆盖了一遍：前后端分离、认证鉴权、文件处理、跨域、打包部署、缓存和日志。做完这个项目，再去接触微服务、消息队列那些大型体系，你会发现自己比完全没做过项目的人更容易理解框架的设计意图——因为你已经知道那些框架到底在解决什么问题了。