简介一份基于 SpringBoot 与 Uniapp 前后端分离的校园社区项目源码包涵盖校园集市、表白墙、论坛、失物招领、校园墙及跳蚤市场等板块能满足校园内信息发布、二手交易与互助交流等需求适合作为高校校园信息化建设、Java 全栈课程设计或毕业设计的参考原型。后端整合 MyBatisPlus、SpringSecurity、Quartz、MinIO、Redis 与 MongoDBMyBatisPlus 简化数据持久层SpringSecurity 提供接口鉴权Quartz 负责定时任务MinIO 承载对象存储Redis 承担缓存MongoDB 存放非关系数据前端采用 Uniapp uView 构建跨平台界面。压缩包共 564 个文件、约 1.85MB以 113 个 Java 后端类、127 个 Vue 页面、253 个 JS 脚本、15 个 SCSS 样式及 1 个 SQL 数据库脚本为主另含 yml/properties 配置、邮件模板、工具类与前端静态资源数据库脚本可直接初始化数据表目录结构清晰便于按模块查阅。内容覆盖用户认证、帖子发布、信息管理等核心逻辑可直接导入开发工具并结合数据库脚本运行调试目前已有 75 人学习查看适合需要快速上手前后端分离项目整合流程、理解常见中间件协同工作的开发者研读。1. 校园论坛与表白墙一起做SpringBoot Uniapp 校园圈源码能省掉哪些事如果你接过校园类项目就会知道校园论坛和表白墙从来不是单点功能而是「帖子 评论 二手交易 失物招领」揉在一起的一套体系。这份基于 SpringBoot Uniapp 的前后端分离校园圈项目源代码把校园集市、表白墙、论坛、失物招领、跳蚤市场全部打通后端是一个 SpringBoot 工程提供 REST 接口前端是一套 Uniapp 代码改改配置就能跑 H5、微信小程序和 App。我拆完这套源码后最直接的感受是它把「一个校园社区最常用的七个模块」做成了标准答案适合做毕设、课程设计也适合想快速上线校园墙类产品的开发者拿去做二次开发。2. 项目结构与数据库设计先看懂模块拆分和核心表再动手拿到任何前后端分离项目我习惯先看目录结构和数据库脚本而不是先跑起来。这一步能让你在 20 分钟内判断这套代码值不值得继续看、改起来要动哪里。2.1 前后端分离的工程骨架SpringBoot 管接口Uniapp 管多端后端是典型的 SpringBoot 分层结构controller 层只做参数接收和结果返回service 层写业务mapper 层用 MyBatis-Plus 操作数据库。前端 Uniapp 按页面分包组织底部 tabBar 挂五个主导航发布和消息类页面走二级路由。项目整体结构如下campus-circle-server/ ├── src/main/java/com/campus/ │ ├── config/ # 跨域配置、拦截器注册、静态资源映射 │ ├── controller/ # 用户、帖子、商品、失物招领等 REST 接口 │ ├── service/ # 业务逻辑层事务注解主要写在这里 │ ├── mapper/ # MyBatis-Plus 的 Mapper 接口 │ ├── entity/ # 数据库表映射实体 │ ├── common/ # Result 统一返回、全局异常处理 │ └── utils/ # JWT 工具、密码加密工具 ├── src/main/resources/ │ ├── mapper/ # 复杂 SQL 的 XML 文件 │ └── application.yml └── sql/ # 建库脚本和初始化数据这套结构没什么花哨但胜在规整。选 MyBatis-Plus 而不是 JPA我个人的偏好是校园社区这类业务有很多多表关联查询和动态条件筛选MyBatis-Plus 的 LambdaQueryWrapper 写起来直观复杂 SQL 又能回退到 XML 里手写不会像 JPA 那样在复杂查询时陷入黑匣子。前端选 Uniapp 的理由更直接——一套代码覆盖微信小程序、H5 和 Android/iOS App对于校园场景来说用户在小程序里扫码使用管理方在 H5 后台看数据同一份前端代码都能兼顾。2.2 核心表设计用户、帖子、商品、表白墙与失物招领数据库脚本是整个项目的根基这套源码把七个模块的业务浓缩成了十来张核心表。我按模块梳理了一遍最主要的关系如下表名所属模块关键字段说明user用户中心username, password, nickname, avatar, role, statusrole 区分普通用户和管理员posts论坛/校园墙user_id, title, content, category, view_countcategory 区分帖子归属板块comments评论post_id, user_id, content, parent_idparent_id 支持楼中楼likes点赞user_id, target_type, target_id多态点赞帖子/评论/表白通用confessions表白墙user_id, content, is_anonymous, status匿名发布时返回虚拟昵称goods跳蚤市场/校园集市user_id, title, price, images, statusstatus 控制在售/已售/下架lost_items失物招领user_id, type, title, location, statustype 区分丢失还是捡到我挑两张最核心的表展开看。用户表是全部模块的外键依赖密码字段长度留够避免 BCrypt 加密串被截断CREATE TABLE user ( id INT UNSIGNED NOT NULL AUTO_INCREMENT COMMENT 主键, username VARCHAR(32) NOT NULL COMMENT 用户名/学号, password VARCHAR(100) NOT NULL COMMENT BCrypt 加密后的密码, nickname VARCHAR(32) DEFAULT COMMENT 昵称, avatar VARCHAR(255) DEFAULT COMMENT 头像地址, role TINYINT NOT NULL DEFAULT 0 COMMENT 0普通 1管理员, status TINYINT NOT NULL DEFAULT 1 COMMENT 0禁用 1正常, create_time DATETIME DEFAULT CURRENT_TIMESTAMP COMMENT 注册时间, PRIMARY KEY (id), UNIQUE KEY uk_username (username) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT用户表;注意两点。一是建表必须用 utf8mb4 而不是 utf8否则用户昵称里带个 emoji 字符入库时报错或者静默丢字这种问题排查起来极其费劲。二是 role 和 status 这类状态字段用 TINYINT 加注释不要用 VARCHAR 存字符串虽然代码里看着直观但索引和存储效率都吃亏。集市商品表是跳蚤市场的核心价格字段的选型很多人会踩坑CREATE TABLE goods ( id INT UNSIGNED NOT NULL AUTO_INCREMENT COMMENT 主键, user_id INT UNSIGNED NOT NULL COMMENT 发布者ID, title VARCHAR(100) NOT NULL COMMENT 商品标题, description TEXT COMMENT 商品描述, price DECIMAL(10,2) NOT NULL DEFAULT 0.00 COMMENT 价格(元), images JSON COMMENT 图片URL列表, status TINYINT NOT NULL DEFAULT 0 COMMENT 0在售 1已售 2下架, create_time DATETIME DEFAULT CURRENT_TIMESTAMP COMMENT 发布时间, PRIMARY KEY (id), KEY idx_user_id (user_id), KEY idx_status (status) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT集市商品表;价格一定要用 DECIMAL(10,2)不要图省事用 FLOAT。FLOAT 是近似存储一件商品标价 9.99查出来可能是 9.9900000001展示层再一格式化容易出幺蛾子。images 用 JSON 类型存储多图列表前端拿到直接遍历渲染少一次字符串拆分。这个设计取舍在评论区和帖子表同理——列表页只查主表详情页再取 JSON 字段避免大字段拖慢列表查询。2.3 统一返回格式与分页约定前端依赖的三条铁律前后端分离项目最常见的翻车点就是接口返回格式不统一——有的接口返回{code:200, data:...}有的直接返回裸数据前端封装层得写一堆兼容代码。这套源码里所有接口走同一个 Result 包装类public class ResultT { private Integer code; // 200 成功400 参数错误401 未登录500 服务异常 private String message; // 错误描述或提示信息 private T data; // 业务数据 public static T ResultT ok(T data) { ResultT r new Result(); r.code 200; r.message success; r.data data; return r; } public static T ResultT error(Integer code, String message) { ResultT r new Result(); r.code code; r.message message; return r; } }前端 request.js 里只需要判断res.data.code一个字段就能处理所有业务分流401 统一跳登录其他非 200 码统一弹 toast。分页约定也是固定的两个参数page从 1 开始pageSize默认 10返回体统一是{records: [], total: 0, pages: 0}。这样写的好处是后续加新模块时前端列表页组件可以直接复用不用为每个页面重写一套分页逻辑。3. SpringBoot 后端实现JWT 鉴权、帖子发布与商品状态流转后端这部分决定这套源码能撑起多大的用户量。校园场景的特点是多读少写、并发不高但业务杂所以实现上不需要微服务那套东西一个单体应用把事务管好、把权限校验做对就够了。3.1 JWT 登录鉴权拦截器、Token 生成与过期时间登录接口走的是标准 JWT 流程前端提交用户名密码后端用 BCrypt 校验密码通过后签发 token 返回。密码加密这里强烈建议用 BCrypt 而不是 MD5因为 MD5 加盐还要自己维护盐值逻辑BCrypt 把盐值内嵌在密文里天然抗彩虹表攻击。生成 token 的代码如下public String createToken(User user) { long now System.currentTimeMillis(); return Jwts.builder() .setSubject(user.getId().toString()) .claim(username, user.getUsername()) .claim(role, user.getRole()) .setIssuedAt(new Date(now)) .setExpiration(new Date(now 7L * 24 * 3600 * 1000)) // 7 天过期 .signWith(SignatureAlgorithm.HS256, SECRET_KEY) .compact(); }参数说明SECRET_KEY 是写在 application.yml 里的签名密钥生产环境要改成 32 位以上随机字符串不要用仓库里默认的值过期时间设定为 7 天校园用户不是每天都登录太短了体验差太长了对敏感操作不友好。如果你要改这个逻辑记住 token 一旦签发在过期前是无法作废的所以被踢下线的用户只能等 token 自然过期。拦截器负责校验每个受保护接口的 tokenpublic 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.trim().isEmpty()) { response.setStatus(401); return false; } try { Claims claims Jwts.parser() .setSigningKey(SECRET_KEY) .parseClaimsJws(token.replace(Bearer , )) .getBody(); request.setAttribute(userId, Long.valueOf(claims.getSubject())); return true; } catch (Exception e) { response.setStatus(401); return false; } }这里有两个容易被忽略的细节。第一前端传的 Authorization 头是Bearer xxxxxxparse 之前必须把Bearer前缀去掉否则解析必失败。第二拦截器解析成功后把 userId 塞进 request attributecontroller 里用RequestAttribute(userId) Long userId直接取这样每个接口都不用再手动解析 token代码会干净很多。3.2 帖子与表白墙接口匿名逻辑和分页查询校园论坛和表白墙在数据模型上是同一张帖子表靠 category 区分板块。发布接口的核心逻辑是从拦截器注入的 userId 拿到发布者校验标题和内容非空然后落库。表白墙的匿名逻辑在查询层处理——如果帖子是匿名发布就把昵称替换成「匿名同学」PostMapping(/post) public ResultLong publish(RequestBody PostDTO dto, RequestAttribute(userId) Long userId) { if (dto.getTitle() null || dto.getTitle().trim().isEmpty()) { return Result.error(400, 标题不能为空); } if (dto.getContent() null || dto.getContent().trim().isEmpty()) { return Result.error(400, 内容不能为空); } Post post new Post(); post.setUserId(userId); post.setTitle(dto.getTitle()); post.setContent(dto.getContent()); post.setCategory(dto.getCategory()); // 0论坛 1表白墙 2校园墙 post.setViewCount(0); post.setStatus(1); // 1正常 0已删除 postService.save(post); return Result.ok(post.getId()); }列表接口走分页查询同时关联用户表查出昵称和头像避免前端拿到 userId 后再逐个请求用户信息。这种 N1 问题在帖子列表这种场景特别明显——一页 10 条帖子如果不做关联查询前端要额外发 10 个请求补用户信息。MyBatis-Plus 里直接用 Page 对象加 LambdaQueryWrapper 就能搞定public PageResultPostVO pagePosts(int page, int pageSize, Integer category) { PagePost pg new Page(page, pageSize); LambdaQueryWrapperPost qw new LambdaQueryWrapper(); if (category ! null) { qw.eq(Post::getCategory, category); } qw.eq(Post::getStatus, 1); qw.orderByDesc(Post::getCreateTime); return postMapper.selectPostPage(pg, qw); }selectPostPage 是写在 XML 里的一条联表 SQLleft join user 表取 nickname 和 avatar。分页插件用 MyBatis-Plus 自带的 PaginationInterceptor配置一次全局生效。这里提醒一句分页插件必须配置数据库类型不然生成的 limit 方言可能不对。3.3 集市商品接口发布、上下架与权限校验跳蚤市场这块业务的核心在商品状态流转。发布时默认 status0在售买家拍下后变 1已售卖家手动操作变 2下架。这里最难的不是 CRUD而是只能让商品主人操作自己的商品否则会出现 A 用户把 B 用户的商品下架了这种严重事故。实现上上下架接口先查商品归属再执行更新PostMapping(/goods/{id}/status) public ResultBoolean changeStatus(PathVariable Long id, RequestParam Integer status, RequestAttribute(userId) Long userId) { Goods goods goodsService.getById(id); if (goods null) { return Result.error(404, 商品不存在); } if (!goods.getUserId().equals(userId)) { return Result.error(403, 无权操作该商品); } // 校验状态流转合法性在售-已售/下架下架-在售 Goods update new Goods(); update.setId(id); update.setStatus(status); goodsService.updateById(update); return Result.ok(true); }状态流转合法性校验值得多说一句。商品不能从「已售」直接变回「在售」因为订单流程上已售意味着交易完成允许回滚会造成数据不一致。严格做法是定义状态机枚举类每个状态只允许跳转到特定目标状态。这套源码里在 service 层做了判断如果前端绕过接口直接改库那属于另一个层面的问题了。3.4 失物招领状态机与消息通知时机失物招领模块相比集市多了一层「认领」动作。表里 type 字段区分失物lost和拾物found状态只有三个0 待认领、1 已找到、2 已撤销。关键动作在「认领」——拾物发布者看到有人想认领需要线下核对信息后再把状态改为已找到而不是由认领人自己改。这个逻辑放在接口层面就是只有发布者或管理员能调用状态变更接口普通用户只能提交认领申请申请落到一张认领记录表里。这种设计符合真实校园场景也避免了误操作带来的纠纷。4. Uniapp 前端页面结构、请求封装与微信小程序打包Uniapp 这层直接决定项目能不能在不同端跑起来。很多前后端分离项目的源码后端写得再规范前端一跑就报错多半是请求封装和打包配置没处理好。这套源码的前端部分有几个值得抄作业的设计。4.1 页面划分与 tabBar 配置前端页面按五个 tab 组织首页帖子流、集市跳蚤市场、发布多功能发布中心、消息、我的。表白墙和失物招领放在首页顶部分类切换里没有作为独立 tab这样底部导航不会超过五个。pages.json 里 tabBar 有个细节——中间那个发布 tab 通常不用原生 tabBar而是用自定义按钮覆盖因为发布页需要选择类型发帖、发表白、发商品、发失物弹层选择组件比直接跳转页面更自然。4.2 request.js 封装Token 注入与 401 兜底前端所有请求走同一个封装baseURL 单独抽到一个配置文件里。用 Promise 包装 uni.request好处是所有页面可以用 async/await 写业务代码不用嵌套回调const BASE_URL http://192.168.1.100:8080/api export function request(options) { return new Promise((resolve, reject) { uni.request({ url: BASE_URL options.url, method: options.method || GET, data: options.data || {}, header: { Content-Type: application/json, Authorization: uni.getStorageSync(token) ? Bearer uni.getStorageSync(token) : }, success: (res) { if (res.statusCode 401) { uni.removeStorageSync(token) uni.navigateTo({ url: /pages/login/login }) return } if (res.data.code 200) { resolve(res.data.data) } else { uni.showToast({ title: res.data.message, icon: none }) reject(res.data) } }, fail: (err) reject(err) }) }) }这段封装的聪明之处是把「鉴权」「错误提示」「数据解包」三个横切关注点收敛在一处。页面里写请求只需要关心业务数据const list await request({ url: /post/list, data: { page } })。注意 BASE_URL 本地调试时不要写 localhost真机调试时手机的 localhost 指向手机自己必须改成电脑的局域网 IP。这个坑我见过太多人踩了改配置改到怀疑人生其实是网络指向问题。4.3 微信登录与匿名发帖的前端实现微信小程序登录比账号密码登录多一步先调 uni.login 拿临时 code再把这个 code 发给后端换取 openid。后端拿 openid 去 user 表匹配用户匹配不到就自动注册一个影子账号。前端只需要处理 token 回写uni.login({ provider: weixin, success: (res) { const code res.code request({ url: /auth/wx-login, method: POST, data: { code } }) .then(data { uni.setStorageSync(token, data.token) uni.setStorageSync(userInfo, data.userInfo) uni.switchTab({ url: /pages/index/index }) }) } })匿名发帖的逻辑在前端只有一个开关发布页有个「匿名发布」的 switch打开时提交的表单数据里带isAnonymous: true后端存库后列表查询时就把昵称替换掉。这里有个安全细节要说清楚匿名只是对普通用户匿名管理员在后端的用户详情里还是能看到真实发布者 ID。如果你的项目承诺「绝对匿名」那属于产品定位问题不是技术能兜底的。4.4 触底加载与下拉刷新列表页统一用 onReachBottom 做触底加载配合分页参数防止重复请求。关键点在「最后一页不再发请求」onReachBottom() { if (this.loading || this.page this.totalPage) return this.loading true this.page this.loadPosts().finally(() { this.loading false }) }loading 标志位必须有否则用户快速滚动时同一页会发出多份重复请求后端虽然扛得住但列表会出现重复数据。下拉刷新则调uni.startPullDownRefresh清空列表并重置 page 为 1再拉一次第一页数据最后uni.stopPullDownRefresh收尾。5. 避坑手册跨域、图片、时区、版本虚高和打包的五个现场翻车记录这部分是我拆这套源码时实际撞过的坑每一条都能对上一条排查经验。记下来你跑的时候至少能少花半天时间。5.1 跨域H5 联调接口能通但浏览器拦截报 CORS现象后端接口用 Postman 调一切正常前端 H5 页面发请求也能看到网络请求发出去了但浏览器 console 报CORS policy错误前端拿不到响应数据。原因浏览器同源策略在拦截Uniapp 跑在http://localhost:8080后端接口在http://192.168.x.x:8080跨域了。Postman 没有同源策略限制所以正常。解决后端写一个 CORS 配置类覆盖所有接口Configuration public class CorsConfig implements WebMvcConfigurer { Override public void addCorsMappings(CorsRegistry registry) { registry.addMapping(/**) .allowedOriginPatterns(*) .allowedMethods(GET, POST, PUT, DELETE, OPTIONS) .allowedHeaders(*) .maxAge(3600); } }注意allowedOriginPatterns不要写成allowedOrigins(*)后者在带 cookie 证书的请求里会被浏览器拒绝。另外拦截器里必须放行 OPTIONS 请求因为浏览器跨域预检发的是 OPTIONS你不放行预检就直接 401 了。5.2 图片上传小程序选完图存的是临时路径刷新就挂现象用uni.chooseImage选完图片前端拿到一个wxfile://tmp_xxx路径直接存进数据库页面一刷新所有商品图全裂。原因微信小程序返回的是临时文件路径只对当次会话有效App 退出或缓存清理后就访问不了。解决选完图立刻调uni.uploadFile传到后端后端把图片存到磁盘并返回可访问的 URL前端存这个 URLuni.chooseImage({ count: 6, success: (res) { const tasks res.tempFilePaths.map((path) { return new Promise((resolve, reject) { uni.uploadFile({ url: BASE_URL /file/upload, filePath: path, name: file, success: (up) { const data JSON.parse(up.data) resolve(data.data.url) }, fail: reject }) }) }) Promise.all(tasks).then((urls) { this.form.images urls }) } })后端这边还要加一个静态资源映射把磁盘上保存图片的目录映射成/upload/**的 URL 访问路径否则库里存了路径浏览器也访问不到文件那图片一样是裂的。5.3 数据库时报错提示字符集和时区不对现象本地 Windows 跑没问题部署到 Linux 服务器后登录接口和发帖接口随机报SQLException: Incorrect string value或者The server time zone value XXX is unrecognized。原因MySQL 8.0 默认时区不是 UTC 时区就可能在连接层报错表里存了表情符号但连接串字符集没指定 utf8mb4就会报 Incorrect string value。解决数据库连接串一次配到位jdbc:mysql://localhost:3306/campus?useUnicodetruecharacterEncodingutf8mb4serverTimezoneAsia/ShanghaiuseSSLfalseallowPublicKeyRetrievaltrue这里特别注意characterEncodingutf8mb4——连接层字符集不指对建表字符集再对也没用。serverTimezoneAsia/Shanghai和useSSLfalse是 MySQL 8.0 连接的两个常见坑少了其中一个大概率会收到驱动层的异常。5.4 SpringBoot 版本虚高3.x 工程引用 2.x 教程代码直接包不存在现象下载源码后升级到 SpringBoot 3.x导包时发现javax.servlet.*全部标红编译不过。原因SpringBoot 3.0 全面迁移到 Jakarta EE 9所有javax.servlet相关的包名改成jakarta.servlet同时很多老版本第三方库不再兼容。解决如果是跑这份校园圈源码建议回退到 SpringBoot 2.7.x它是 2.x 系列最后一个稳定版本老教程代码几乎零改动就能跑。如果你确实要用 3.x把代码里所有javax.servlet批量替换成jakarta.servlet同时把 JWT 库换成支持 Jakarta 的版本。这个坑对新手不友好因为报错信息里并不直接告诉你「版本不兼容」只会说包不存在。5.5 微信小程序正式包请求全部失败或白屏现象HBuilderX 内置模拟器一切正常预览到手机真机上页面能打开但接口全部请求失败或直接白屏。原因微信小程序真机环境比模拟器严格得多——开发阶段勾选了「不校验合法域名」所以能请求 http 明文接口但真机调试或正式包必须用 https 且域名要在微信公众平台配置白名单。白屏也可能是 JS 报错被静默吞掉。解决开发阶段在微信开发者工具里勾选「不校验合法域名」真机和模拟器就能通。要发正式版后端接口必须走 https域名备案后在 mp 后台「开发设置-服务器域名」里把 request 合法域名加上。这套源码的 manifest.json 里要填真实的小程序 appid不能拿测试号去发正式包。如果你只是本地学习走到「不校验合法域名」这一步就够了要上架这条避坑记录能帮你省一次审核驳回。6. 跑起来与验证从本地启动到用 nginx 反代接口最后这一步实操价值最高。整套源码的启动顺序有讲究按我的习惯一定是「先数据库再后端最后前端」——数据库脚本没跑成功就启动后端会抛一堆连接异常干扰你判断。第一步用 MySQL 客户端执行 sql 目录下的建库脚本确认 12 张表全部建好。第二步改 application.yml 里的数据库账号密码其他配置保持默认。第三步启动 SpringBoot 工程看到控制台打印端口 8080 启动成功。第四步HBuilderX 导入前端工程改掉 request.js 里的 BASE_URL在浏览器里跑 H5 端验证登录、发帖、发商品全流程。这个顺序能保证任何一步出问题排查范围缩到最小。验证清单我整理成一条固定动作注册账号 → 发布一个论坛帖 → 发一条匿名表白 → 上架一件二手商品 → 发一条失物招领 → 在首页看到刚才发布的内容。这套流程走通七个模块的核心链路就全通了。如果某一步走不通先看浏览器 Network 面板里的请求状态码——401 是 token 问题404 是接口路径问题500 是后端逻辑问题定位效率最高。部署到服务器时我习惯用 nginx 做反向代理把/api开头的请求转发到 SpringBoot 的 8080 端口。这样一个 server 块同时托管前端静态文件和后端接口前端 BASE_URL 直接配成/api不用区分开发和生产两套地址server { listen 80; server_name your-domain.com; # 前端静态资源 root /usr/share/nginx/html; index index.html; # 后端接口反向代理 location /api/ { proxy_pass http://127.0.0.1:8080/api/; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; } # 上传的图片文件 location /upload/ { alias /data/upload/; } }这个配置有个隐藏好处浏览器始终只跟你的域名通信不存在跨域问题前端代码里的 BASE_URL 用相对路径/api后端 CORS 配置对同源请求也不会有任何干扰。图片目录单独映射不用打进 jar 包后面换服务器只需要把整个 /data/upload 目录拷走。把这套流程跑通之后我对校园圈这类前后端分离项目形成了一套固定套路先跑数据库脚本确认表结构再改连接串启动后端用 Postman 打两个核心接口验证鉴权最后才轮到前端页面联调。从那以后我每次接手新的同类源码都强制走这一遍流程没有一次因为启动顺序问题卡壳。希望这份拆解能帮你在自己的项目上少走几步冤枉路如果后续跑通后有更好的优化思路也欢迎按自己的场景去改。本文还有配套的精品资源点击获取 SpringBoot+Uniapp校园圈源码拆解：数据库设计到部署避坑指南
简介一份基于 SpringBoot 与 Uniapp 前后端分离的校园社区项目源码包涵盖校园集市、表白墙、论坛、失物招领、校园墙及跳蚤市场等板块能满足校园内信息发布、二手交易与互助交流等需求适合作为高校校园信息化建设、Java 全栈课程设计或毕业设计的参考原型。后端整合 MyBatisPlus、SpringSecurity、Quartz、MinIO、Redis 与 MongoDBMyBatisPlus 简化数据持久层SpringSecurity 提供接口鉴权Quartz 负责定时任务MinIO 承载对象存储Redis 承担缓存MongoDB 存放非关系数据前端采用 Uniapp uView 构建跨平台界面。压缩包共 564 个文件、约 1.85MB以 113 个 Java 后端类、127 个 Vue 页面、253 个 JS 脚本、15 个 SCSS 样式及 1 个 SQL 数据库脚本为主另含 yml/properties 配置、邮件模板、工具类与前端静态资源数据库脚本可直接初始化数据表目录结构清晰便于按模块查阅。内容覆盖用户认证、帖子发布、信息管理等核心逻辑可直接导入开发工具并结合数据库脚本运行调试目前已有 75 人学习查看适合需要快速上手前后端分离项目整合流程、理解常见中间件协同工作的开发者研读。1. 校园论坛与表白墙一起做SpringBoot Uniapp 校园圈源码能省掉哪些事如果你接过校园类项目就会知道校园论坛和表白墙从来不是单点功能而是「帖子 评论 二手交易 失物招领」揉在一起的一套体系。这份基于 SpringBoot Uniapp 的前后端分离校园圈项目源代码把校园集市、表白墙、论坛、失物招领、跳蚤市场全部打通后端是一个 SpringBoot 工程提供 REST 接口前端是一套 Uniapp 代码改改配置就能跑 H5、微信小程序和 App。我拆完这套源码后最直接的感受是它把「一个校园社区最常用的七个模块」做成了标准答案适合做毕设、课程设计也适合想快速上线校园墙类产品的开发者拿去做二次开发。2. 项目结构与数据库设计先看懂模块拆分和核心表再动手拿到任何前后端分离项目我习惯先看目录结构和数据库脚本而不是先跑起来。这一步能让你在 20 分钟内判断这套代码值不值得继续看、改起来要动哪里。2.1 前后端分离的工程骨架SpringBoot 管接口Uniapp 管多端后端是典型的 SpringBoot 分层结构controller 层只做参数接收和结果返回service 层写业务mapper 层用 MyBatis-Plus 操作数据库。前端 Uniapp 按页面分包组织底部 tabBar 挂五个主导航发布和消息类页面走二级路由。项目整体结构如下campus-circle-server/ ├── src/main/java/com/campus/ │ ├── config/ # 跨域配置、拦截器注册、静态资源映射 │ ├── controller/ # 用户、帖子、商品、失物招领等 REST 接口 │ ├── service/ # 业务逻辑层事务注解主要写在这里 │ ├── mapper/ # MyBatis-Plus 的 Mapper 接口 │ ├── entity/ # 数据库表映射实体 │ ├── common/ # Result 统一返回、全局异常处理 │ └── utils/ # JWT 工具、密码加密工具 ├── src/main/resources/ │ ├── mapper/ # 复杂 SQL 的 XML 文件 │ └── application.yml └── sql/ # 建库脚本和初始化数据这套结构没什么花哨但胜在规整。选 MyBatis-Plus 而不是 JPA我个人的偏好是校园社区这类业务有很多多表关联查询和动态条件筛选MyBatis-Plus 的 LambdaQueryWrapper 写起来直观复杂 SQL 又能回退到 XML 里手写不会像 JPA 那样在复杂查询时陷入黑匣子。前端选 Uniapp 的理由更直接——一套代码覆盖微信小程序、H5 和 Android/iOS App对于校园场景来说用户在小程序里扫码使用管理方在 H5 后台看数据同一份前端代码都能兼顾。2.2 核心表设计用户、帖子、商品、表白墙与失物招领数据库脚本是整个项目的根基这套源码把七个模块的业务浓缩成了十来张核心表。我按模块梳理了一遍最主要的关系如下表名所属模块关键字段说明user用户中心username, password, nickname, avatar, role, statusrole 区分普通用户和管理员posts论坛/校园墙user_id, title, content, category, view_countcategory 区分帖子归属板块comments评论post_id, user_id, content, parent_idparent_id 支持楼中楼likes点赞user_id, target_type, target_id多态点赞帖子/评论/表白通用confessions表白墙user_id, content, is_anonymous, status匿名发布时返回虚拟昵称goods跳蚤市场/校园集市user_id, title, price, images, statusstatus 控制在售/已售/下架lost_items失物招领user_id, type, title, location, statustype 区分丢失还是捡到我挑两张最核心的表展开看。用户表是全部模块的外键依赖密码字段长度留够避免 BCrypt 加密串被截断CREATE TABLE user ( id INT UNSIGNED NOT NULL AUTO_INCREMENT COMMENT 主键, username VARCHAR(32) NOT NULL COMMENT 用户名/学号, password VARCHAR(100) NOT NULL COMMENT BCrypt 加密后的密码, nickname VARCHAR(32) DEFAULT COMMENT 昵称, avatar VARCHAR(255) DEFAULT COMMENT 头像地址, role TINYINT NOT NULL DEFAULT 0 COMMENT 0普通 1管理员, status TINYINT NOT NULL DEFAULT 1 COMMENT 0禁用 1正常, create_time DATETIME DEFAULT CURRENT_TIMESTAMP COMMENT 注册时间, PRIMARY KEY (id), UNIQUE KEY uk_username (username) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT用户表;注意两点。一是建表必须用 utf8mb4 而不是 utf8否则用户昵称里带个 emoji 字符入库时报错或者静默丢字这种问题排查起来极其费劲。二是 role 和 status 这类状态字段用 TINYINT 加注释不要用 VARCHAR 存字符串虽然代码里看着直观但索引和存储效率都吃亏。集市商品表是跳蚤市场的核心价格字段的选型很多人会踩坑CREATE TABLE goods ( id INT UNSIGNED NOT NULL AUTO_INCREMENT COMMENT 主键, user_id INT UNSIGNED NOT NULL COMMENT 发布者ID, title VARCHAR(100) NOT NULL COMMENT 商品标题, description TEXT COMMENT 商品描述, price DECIMAL(10,2) NOT NULL DEFAULT 0.00 COMMENT 价格(元), images JSON COMMENT 图片URL列表, status TINYINT NOT NULL DEFAULT 0 COMMENT 0在售 1已售 2下架, create_time DATETIME DEFAULT CURRENT_TIMESTAMP COMMENT 发布时间, PRIMARY KEY (id), KEY idx_user_id (user_id), KEY idx_status (status) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT集市商品表;价格一定要用 DECIMAL(10,2)不要图省事用 FLOAT。FLOAT 是近似存储一件商品标价 9.99查出来可能是 9.9900000001展示层再一格式化容易出幺蛾子。images 用 JSON 类型存储多图列表前端拿到直接遍历渲染少一次字符串拆分。这个设计取舍在评论区和帖子表同理——列表页只查主表详情页再取 JSON 字段避免大字段拖慢列表查询。2.3 统一返回格式与分页约定前端依赖的三条铁律前后端分离项目最常见的翻车点就是接口返回格式不统一——有的接口返回{code:200, data:...}有的直接返回裸数据前端封装层得写一堆兼容代码。这套源码里所有接口走同一个 Result 包装类public class ResultT { private Integer code; // 200 成功400 参数错误401 未登录500 服务异常 private String message; // 错误描述或提示信息 private T data; // 业务数据 public static T ResultT ok(T data) { ResultT r new Result(); r.code 200; r.message success; r.data data; return r; } public static T ResultT error(Integer code, String message) { ResultT r new Result(); r.code code; r.message message; return r; } }前端 request.js 里只需要判断res.data.code一个字段就能处理所有业务分流401 统一跳登录其他非 200 码统一弹 toast。分页约定也是固定的两个参数page从 1 开始pageSize默认 10返回体统一是{records: [], total: 0, pages: 0}。这样写的好处是后续加新模块时前端列表页组件可以直接复用不用为每个页面重写一套分页逻辑。3. SpringBoot 后端实现JWT 鉴权、帖子发布与商品状态流转后端这部分决定这套源码能撑起多大的用户量。校园场景的特点是多读少写、并发不高但业务杂所以实现上不需要微服务那套东西一个单体应用把事务管好、把权限校验做对就够了。3.1 JWT 登录鉴权拦截器、Token 生成与过期时间登录接口走的是标准 JWT 流程前端提交用户名密码后端用 BCrypt 校验密码通过后签发 token 返回。密码加密这里强烈建议用 BCrypt 而不是 MD5因为 MD5 加盐还要自己维护盐值逻辑BCrypt 把盐值内嵌在密文里天然抗彩虹表攻击。生成 token 的代码如下public String createToken(User user) { long now System.currentTimeMillis(); return Jwts.builder() .setSubject(user.getId().toString()) .claim(username, user.getUsername()) .claim(role, user.getRole()) .setIssuedAt(new Date(now)) .setExpiration(new Date(now 7L * 24 * 3600 * 1000)) // 7 天过期 .signWith(SignatureAlgorithm.HS256, SECRET_KEY) .compact(); }参数说明SECRET_KEY 是写在 application.yml 里的签名密钥生产环境要改成 32 位以上随机字符串不要用仓库里默认的值过期时间设定为 7 天校园用户不是每天都登录太短了体验差太长了对敏感操作不友好。如果你要改这个逻辑记住 token 一旦签发在过期前是无法作废的所以被踢下线的用户只能等 token 自然过期。拦截器负责校验每个受保护接口的 tokenpublic 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.trim().isEmpty()) { response.setStatus(401); return false; } try { Claims claims Jwts.parser() .setSigningKey(SECRET_KEY) .parseClaimsJws(token.replace(Bearer , )) .getBody(); request.setAttribute(userId, Long.valueOf(claims.getSubject())); return true; } catch (Exception e) { response.setStatus(401); return false; } }这里有两个容易被忽略的细节。第一前端传的 Authorization 头是Bearer xxxxxxparse 之前必须把Bearer前缀去掉否则解析必失败。第二拦截器解析成功后把 userId 塞进 request attributecontroller 里用RequestAttribute(userId) Long userId直接取这样每个接口都不用再手动解析 token代码会干净很多。3.2 帖子与表白墙接口匿名逻辑和分页查询校园论坛和表白墙在数据模型上是同一张帖子表靠 category 区分板块。发布接口的核心逻辑是从拦截器注入的 userId 拿到发布者校验标题和内容非空然后落库。表白墙的匿名逻辑在查询层处理——如果帖子是匿名发布就把昵称替换成「匿名同学」PostMapping(/post) public ResultLong publish(RequestBody PostDTO dto, RequestAttribute(userId) Long userId) { if (dto.getTitle() null || dto.getTitle().trim().isEmpty()) { return Result.error(400, 标题不能为空); } if (dto.getContent() null || dto.getContent().trim().isEmpty()) { return Result.error(400, 内容不能为空); } Post post new Post(); post.setUserId(userId); post.setTitle(dto.getTitle()); post.setContent(dto.getContent()); post.setCategory(dto.getCategory()); // 0论坛 1表白墙 2校园墙 post.setViewCount(0); post.setStatus(1); // 1正常 0已删除 postService.save(post); return Result.ok(post.getId()); }列表接口走分页查询同时关联用户表查出昵称和头像避免前端拿到 userId 后再逐个请求用户信息。这种 N1 问题在帖子列表这种场景特别明显——一页 10 条帖子如果不做关联查询前端要额外发 10 个请求补用户信息。MyBatis-Plus 里直接用 Page 对象加 LambdaQueryWrapper 就能搞定public PageResultPostVO pagePosts(int page, int pageSize, Integer category) { PagePost pg new Page(page, pageSize); LambdaQueryWrapperPost qw new LambdaQueryWrapper(); if (category ! null) { qw.eq(Post::getCategory, category); } qw.eq(Post::getStatus, 1); qw.orderByDesc(Post::getCreateTime); return postMapper.selectPostPage(pg, qw); }selectPostPage 是写在 XML 里的一条联表 SQLleft join user 表取 nickname 和 avatar。分页插件用 MyBatis-Plus 自带的 PaginationInterceptor配置一次全局生效。这里提醒一句分页插件必须配置数据库类型不然生成的 limit 方言可能不对。3.3 集市商品接口发布、上下架与权限校验跳蚤市场这块业务的核心在商品状态流转。发布时默认 status0在售买家拍下后变 1已售卖家手动操作变 2下架。这里最难的不是 CRUD而是只能让商品主人操作自己的商品否则会出现 A 用户把 B 用户的商品下架了这种严重事故。实现上上下架接口先查商品归属再执行更新PostMapping(/goods/{id}/status) public ResultBoolean changeStatus(PathVariable Long id, RequestParam Integer status, RequestAttribute(userId) Long userId) { Goods goods goodsService.getById(id); if (goods null) { return Result.error(404, 商品不存在); } if (!goods.getUserId().equals(userId)) { return Result.error(403, 无权操作该商品); } // 校验状态流转合法性在售-已售/下架下架-在售 Goods update new Goods(); update.setId(id); update.setStatus(status); goodsService.updateById(update); return Result.ok(true); }状态流转合法性校验值得多说一句。商品不能从「已售」直接变回「在售」因为订单流程上已售意味着交易完成允许回滚会造成数据不一致。严格做法是定义状态机枚举类每个状态只允许跳转到特定目标状态。这套源码里在 service 层做了判断如果前端绕过接口直接改库那属于另一个层面的问题了。3.4 失物招领状态机与消息通知时机失物招领模块相比集市多了一层「认领」动作。表里 type 字段区分失物lost和拾物found状态只有三个0 待认领、1 已找到、2 已撤销。关键动作在「认领」——拾物发布者看到有人想认领需要线下核对信息后再把状态改为已找到而不是由认领人自己改。这个逻辑放在接口层面就是只有发布者或管理员能调用状态变更接口普通用户只能提交认领申请申请落到一张认领记录表里。这种设计符合真实校园场景也避免了误操作带来的纠纷。4. Uniapp 前端页面结构、请求封装与微信小程序打包Uniapp 这层直接决定项目能不能在不同端跑起来。很多前后端分离项目的源码后端写得再规范前端一跑就报错多半是请求封装和打包配置没处理好。这套源码的前端部分有几个值得抄作业的设计。4.1 页面划分与 tabBar 配置前端页面按五个 tab 组织首页帖子流、集市跳蚤市场、发布多功能发布中心、消息、我的。表白墙和失物招领放在首页顶部分类切换里没有作为独立 tab这样底部导航不会超过五个。pages.json 里 tabBar 有个细节——中间那个发布 tab 通常不用原生 tabBar而是用自定义按钮覆盖因为发布页需要选择类型发帖、发表白、发商品、发失物弹层选择组件比直接跳转页面更自然。4.2 request.js 封装Token 注入与 401 兜底前端所有请求走同一个封装baseURL 单独抽到一个配置文件里。用 Promise 包装 uni.request好处是所有页面可以用 async/await 写业务代码不用嵌套回调const BASE_URL http://192.168.1.100:8080/api export function request(options) { return new Promise((resolve, reject) { uni.request({ url: BASE_URL options.url, method: options.method || GET, data: options.data || {}, header: { Content-Type: application/json, Authorization: uni.getStorageSync(token) ? Bearer uni.getStorageSync(token) : }, success: (res) { if (res.statusCode 401) { uni.removeStorageSync(token) uni.navigateTo({ url: /pages/login/login }) return } if (res.data.code 200) { resolve(res.data.data) } else { uni.showToast({ title: res.data.message, icon: none }) reject(res.data) } }, fail: (err) reject(err) }) }) }这段封装的聪明之处是把「鉴权」「错误提示」「数据解包」三个横切关注点收敛在一处。页面里写请求只需要关心业务数据const list await request({ url: /post/list, data: { page } })。注意 BASE_URL 本地调试时不要写 localhost真机调试时手机的 localhost 指向手机自己必须改成电脑的局域网 IP。这个坑我见过太多人踩了改配置改到怀疑人生其实是网络指向问题。4.3 微信登录与匿名发帖的前端实现微信小程序登录比账号密码登录多一步先调 uni.login 拿临时 code再把这个 code 发给后端换取 openid。后端拿 openid 去 user 表匹配用户匹配不到就自动注册一个影子账号。前端只需要处理 token 回写uni.login({ provider: weixin, success: (res) { const code res.code request({ url: /auth/wx-login, method: POST, data: { code } }) .then(data { uni.setStorageSync(token, data.token) uni.setStorageSync(userInfo, data.userInfo) uni.switchTab({ url: /pages/index/index }) }) } })匿名发帖的逻辑在前端只有一个开关发布页有个「匿名发布」的 switch打开时提交的表单数据里带isAnonymous: true后端存库后列表查询时就把昵称替换掉。这里有个安全细节要说清楚匿名只是对普通用户匿名管理员在后端的用户详情里还是能看到真实发布者 ID。如果你的项目承诺「绝对匿名」那属于产品定位问题不是技术能兜底的。4.4 触底加载与下拉刷新列表页统一用 onReachBottom 做触底加载配合分页参数防止重复请求。关键点在「最后一页不再发请求」onReachBottom() { if (this.loading || this.page this.totalPage) return this.loading true this.page this.loadPosts().finally(() { this.loading false }) }loading 标志位必须有否则用户快速滚动时同一页会发出多份重复请求后端虽然扛得住但列表会出现重复数据。下拉刷新则调uni.startPullDownRefresh清空列表并重置 page 为 1再拉一次第一页数据最后uni.stopPullDownRefresh收尾。5. 避坑手册跨域、图片、时区、版本虚高和打包的五个现场翻车记录这部分是我拆这套源码时实际撞过的坑每一条都能对上一条排查经验。记下来你跑的时候至少能少花半天时间。5.1 跨域H5 联调接口能通但浏览器拦截报 CORS现象后端接口用 Postman 调一切正常前端 H5 页面发请求也能看到网络请求发出去了但浏览器 console 报CORS policy错误前端拿不到响应数据。原因浏览器同源策略在拦截Uniapp 跑在http://localhost:8080后端接口在http://192.168.x.x:8080跨域了。Postman 没有同源策略限制所以正常。解决后端写一个 CORS 配置类覆盖所有接口Configuration public class CorsConfig implements WebMvcConfigurer { Override public void addCorsMappings(CorsRegistry registry) { registry.addMapping(/**) .allowedOriginPatterns(*) .allowedMethods(GET, POST, PUT, DELETE, OPTIONS) .allowedHeaders(*) .maxAge(3600); } }注意allowedOriginPatterns不要写成allowedOrigins(*)后者在带 cookie 证书的请求里会被浏览器拒绝。另外拦截器里必须放行 OPTIONS 请求因为浏览器跨域预检发的是 OPTIONS你不放行预检就直接 401 了。5.2 图片上传小程序选完图存的是临时路径刷新就挂现象用uni.chooseImage选完图片前端拿到一个wxfile://tmp_xxx路径直接存进数据库页面一刷新所有商品图全裂。原因微信小程序返回的是临时文件路径只对当次会话有效App 退出或缓存清理后就访问不了。解决选完图立刻调uni.uploadFile传到后端后端把图片存到磁盘并返回可访问的 URL前端存这个 URLuni.chooseImage({ count: 6, success: (res) { const tasks res.tempFilePaths.map((path) { return new Promise((resolve, reject) { uni.uploadFile({ url: BASE_URL /file/upload, filePath: path, name: file, success: (up) { const data JSON.parse(up.data) resolve(data.data.url) }, fail: reject }) }) }) Promise.all(tasks).then((urls) { this.form.images urls }) } })后端这边还要加一个静态资源映射把磁盘上保存图片的目录映射成/upload/**的 URL 访问路径否则库里存了路径浏览器也访问不到文件那图片一样是裂的。5.3 数据库时报错提示字符集和时区不对现象本地 Windows 跑没问题部署到 Linux 服务器后登录接口和发帖接口随机报SQLException: Incorrect string value或者The server time zone value XXX is unrecognized。原因MySQL 8.0 默认时区不是 UTC 时区就可能在连接层报错表里存了表情符号但连接串字符集没指定 utf8mb4就会报 Incorrect string value。解决数据库连接串一次配到位jdbc:mysql://localhost:3306/campus?useUnicodetruecharacterEncodingutf8mb4serverTimezoneAsia/ShanghaiuseSSLfalseallowPublicKeyRetrievaltrue这里特别注意characterEncodingutf8mb4——连接层字符集不指对建表字符集再对也没用。serverTimezoneAsia/Shanghai和useSSLfalse是 MySQL 8.0 连接的两个常见坑少了其中一个大概率会收到驱动层的异常。5.4 SpringBoot 版本虚高3.x 工程引用 2.x 教程代码直接包不存在现象下载源码后升级到 SpringBoot 3.x导包时发现javax.servlet.*全部标红编译不过。原因SpringBoot 3.0 全面迁移到 Jakarta EE 9所有javax.servlet相关的包名改成jakarta.servlet同时很多老版本第三方库不再兼容。解决如果是跑这份校园圈源码建议回退到 SpringBoot 2.7.x它是 2.x 系列最后一个稳定版本老教程代码几乎零改动就能跑。如果你确实要用 3.x把代码里所有javax.servlet批量替换成jakarta.servlet同时把 JWT 库换成支持 Jakarta 的版本。这个坑对新手不友好因为报错信息里并不直接告诉你「版本不兼容」只会说包不存在。5.5 微信小程序正式包请求全部失败或白屏现象HBuilderX 内置模拟器一切正常预览到手机真机上页面能打开但接口全部请求失败或直接白屏。原因微信小程序真机环境比模拟器严格得多——开发阶段勾选了「不校验合法域名」所以能请求 http 明文接口但真机调试或正式包必须用 https 且域名要在微信公众平台配置白名单。白屏也可能是 JS 报错被静默吞掉。解决开发阶段在微信开发者工具里勾选「不校验合法域名」真机和模拟器就能通。要发正式版后端接口必须走 https域名备案后在 mp 后台「开发设置-服务器域名」里把 request 合法域名加上。这套源码的 manifest.json 里要填真实的小程序 appid不能拿测试号去发正式包。如果你只是本地学习走到「不校验合法域名」这一步就够了要上架这条避坑记录能帮你省一次审核驳回。6. 跑起来与验证从本地启动到用 nginx 反代接口最后这一步实操价值最高。整套源码的启动顺序有讲究按我的习惯一定是「先数据库再后端最后前端」——数据库脚本没跑成功就启动后端会抛一堆连接异常干扰你判断。第一步用 MySQL 客户端执行 sql 目录下的建库脚本确认 12 张表全部建好。第二步改 application.yml 里的数据库账号密码其他配置保持默认。第三步启动 SpringBoot 工程看到控制台打印端口 8080 启动成功。第四步HBuilderX 导入前端工程改掉 request.js 里的 BASE_URL在浏览器里跑 H5 端验证登录、发帖、发商品全流程。这个顺序能保证任何一步出问题排查范围缩到最小。验证清单我整理成一条固定动作注册账号 → 发布一个论坛帖 → 发一条匿名表白 → 上架一件二手商品 → 发一条失物招领 → 在首页看到刚才发布的内容。这套流程走通七个模块的核心链路就全通了。如果某一步走不通先看浏览器 Network 面板里的请求状态码——401 是 token 问题404 是接口路径问题500 是后端逻辑问题定位效率最高。部署到服务器时我习惯用 nginx 做反向代理把/api开头的请求转发到 SpringBoot 的 8080 端口。这样一个 server 块同时托管前端静态文件和后端接口前端 BASE_URL 直接配成/api不用区分开发和生产两套地址server { listen 80; server_name your-domain.com; # 前端静态资源 root /usr/share/nginx/html; index index.html; # 后端接口反向代理 location /api/ { proxy_pass http://127.0.0.1:8080/api/; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; } # 上传的图片文件 location /upload/ { alias /data/upload/; } }这个配置有个隐藏好处浏览器始终只跟你的域名通信不存在跨域问题前端代码里的 BASE_URL 用相对路径/api后端 CORS 配置对同源请求也不会有任何干扰。图片目录单独映射不用打进 jar 包后面换服务器只需要把整个 /data/upload 目录拷走。把这套流程跑通之后我对校园圈这类前后端分离项目形成了一套固定套路先跑数据库脚本确认表结构再改连接串启动后端用 Postman 打两个核心接口验证鉴权最后才轮到前端页面联调。从那以后我每次接手新的同类源码都强制走这一遍流程没有一次因为启动顺序问题卡壳。希望这份拆解能帮你在自己的项目上少走几步冤枉路如果后续跑通后有更好的优化思路也欢迎按自己的场景去改。本文还有配套的精品资源点击获取