企业官网建设流程全解析

又到毕业设计季。每年这个时候，都会有一大批同学拿着“Spring Boot + 微信小程序”的题目来找我，“校园场景应用”是其中最典型的选题之一。说实话，这个组合在本科毕业设计里属于稳妥路线：技术栈主流、工作量可控、演示效果直观，导师也能一眼看懂你到底在解决什么问题。但我见过太多人把这类项目做成了“搬家式demo”：功能堆了一堆，答辩时连“为什么用JWT不用Session”都解释不清楚。这篇内容就围绕这类项目做一次完整拆解，从需求定位、数据库设计、接口规划，到前端联调、部署上线，把关键环节全部过一遍。

1. 先想清楚再动手：这个选题到底在做什么

1.1 校园场景的共性需求：为什么二手交易和失物招领是首选

“校园场景应用”这个题目本身比较宽泛，很多同学拿到手反而不知道怎么下手。常见的方向有课程表查询、活动报名、食堂订餐、报修服务、二手交易、失物招领等。我的建议是优先选**有明确“供需关系”**的场景，比如校园二手交易、失物招领、拼车、组队。原因很简单：这类场景天然需要“用户发布信息 + 其他用户消费信息”的流程，后端能体现CRUD、权限控制、状态流转，前端能体现列表、详情、表单、个人中心，完整度刚好卡在毕业设计需要的那个档位。

以“校园二手交易与失物招领”为例，核心角色就两类：发布者和浏览者。发布者可以发闲置物品，可以登记失物或拾物；浏览者可以查看列表、搜索、按分类筛选。叠加一个“我的”模块展示自己发布的内容，整个系统的闭环就出来了。功能不至于太复杂，但每个模块都不是“空壳子”，都能讲出业务逻辑。

这里多提一句：有些同学喜欢把系统做成“校园综合服务”，课程表、成绩查询、社团活动全塞进去。功能越多，接口越多，代码量越大，出错概率越高，答辩时被追问的可能性也越大。毕业设计不是给公司做产品，它考察的是你能不能把一个完整的小系统从头搭起来，而不是你能不能做出一个大系统。宁可把一个场景做扎实，也不要贪多求全。

1.2 技术选型的核心逻辑：Spring Boot + 小程序 + MySQL

选型这件事，很多同学是跟着教程走，但如果你不确定“为什么这么选”，答辩时就会露怯。我们先说结论：后端用Spring Boot，前端用微信小程序，数据库用MySQL，ORM用MyBatis-Plus，登录态用JWT，文件存储用服务器本地目录或云存储。这套组合是目前校园项目里最主流、也最不容易出错的方案。

为什么是Spring Boot？因为它把Spring的复杂配置大量简化，内置Tomcat，一个jar包就能跑起来，非常适合独立开发。为什么是微信小程序？因为校园场景里用户的获取成本极低，微信扫一扫就能用，不需要下载App，而且小程序本身的UI组件、API体系也足够完善，不用写原生安卓或iOS。

有同学问过“为什么不用Vue写网页，打包放进Spring Boot里”。这种方式也可以，但放在校园场景里有个天然劣势：小程序是扫码即用的，网页还要打开浏览器输入网址或者点链接，传播路径多了一步。另外小程序有平台审核流程，答辩时可以说“考虑了跨端适配和传播效率”，这是个加分点，不是减分点。从学习价值来说，小程序的前端逻辑和后端交互方式和网页前端其实高度类似，都是用request调HTTP接口，没有额外学习负担。

数据库选MySQL没什么悬念。对于这种规模的应用，MySQL的InnoDB引擎、索引机制、事务支持完全够用。MyBatis-Plus则能帮你省掉大量重复的SQL编写，内置分页插件和CRUD方法，非常适合单人快速开发。

2. 后端核心细节：Spring Boot 工程搭建与接口设计

2.1 项目结构和核心依赖

先看工程结构。我习惯用标准的Controller-Service-Mapper三层，加上config、common、entity、dto、vo这些基础包。一个参考结构如下：

src/main/java/com/example/campus/ ├── common/ // 统一返回结果、异常处理、常量 ├── config/ // CORS配置、拦截器配置、静态资源配置 ├── controller/ // 控制层 ├── service/ // 业务层（接口 + 实现） ├── mapper/ // MyBatis-Plus Mapper ├── entity/ // 数据库实体 ├── dto/ // 请求参数对象 ├── vo/ // 响应对象 └── utils/ // JWT、文件上传等工具

依赖方面，最核心的就是spring-boot-starter-web、mybatis-plus-boot-starter、mysql-connector-java、jjwt（或java-jwt）、lombok。再加一个spring-boot-starter-validation用于参数校验就够了。不需要引入太多组件，因为每多一个依赖，启动和部署就多一分不确定性。

版本这里必须提醒一下。Spring Boot 3.x 要求JDK 17，而很多学校机房或你自己电脑上装的还是JDK 8。所以个人项目建议用Spring Boot 2.7.x，对应JDK 8，兼容性最好。如果你是非要尝鲜用Spring Boot 3，那就要确认你的MyBatis-Plus和数据库驱动版本都跟得上，否则启动就报错，这个坑我后面还会提到。

2.2 数据库设计与表结构关系

数据库设计是整个项目的基石，也是答辩时老师最爱问的部分。以“校园二手交易与失物招领小程序”为例，核心表可以这样拆：

设计的时候有几个要点。第一，用户表不要存密码，因为小程序登录用的是微信openid绑定，不需要密码体系。第二，商品图片字段用JSON字符串存储，比如["url1","url2"]，不要用一张图片表去关联，不然查询复杂度会上升不少。第三，每个表都要有create_time，列表排序时按时间倒序是校园集市类应用最常见的需求。

第四点是很多人会忽略的：状态字段最好用int，不要用varchar。比如商品status=0表示在售，1表示已售，2表示下架。用数字的好处是前后端约定简单，数据库存储量小，排序和筛选也方便。答辩时如果能说清楚“状态机”的概念，老师会认为你有工程设计意识。

2.3 接口设计与统一返回格式

后端接口设计遵循RESTful风格。核心接口大概这些：

这里最重要的是统一返回格式。我建议定义一个Result类，包含code、message、data三个字段：

@Data public class Result<T> { private Integer code; private String message; private T data; public static <T> Result<T> success(T data) { // code=200, message="success" } public static <T> Result<T> error(Integer code, String message) { // 业务异常返回 } }

不要小看这个设计。如果每个接口的返回结构都不一样，小程序端处理起来会非常痛苦。统一格式之后，前端只需要判断code === 200就能确定请求是否成功，数据直接取data字段，逻辑清晰多了。

同时要配置全局异常处理器，用@RestControllerAdvice捕获业务异常和系统异常，避免异常直接抛给前端导致返回一堆Tomcat默认的错误页面。这是工程经验里的基础操作，但很多新手项目没做，答辩时被问“如果用户传了一个不存在的商品ID怎么办”就答不上来。

2.4 登录流程与JWT鉴权

小程序登录是整个系统的身份基础。流程不复杂，但有几个细节必须说清楚：

1. 小程序端调用wx.login()获取临时code。
2. 小程序把code通过请求发送给后端。
3. 后端调用微信接口code2Session，用code换取openid和session_key。
4. 后端查询user表，如果openid不存在，就自动注册一个新用户。
5. 后端生成JWT token，返回给小程序。
6. 小程序把token存起来，后续每个请求都在header里带上。

这里有几个坑。第一个坑是：code只能用一次，而且有效期很短，所以后端拿到code必须立刻调用微信接口，不能把它存起来加一会儿再用。第二个坑是：code2Session这个接口的URL在微信开放文档里是这样：https://api.weixin.qq.com/sns/jscode2session?appid=APPID&secret=SECRET&js_code=JSCODE&grant_type=authorization_code，参数一个都不能少，appid和secret必须从你的小程序后台拿，而不是从网上的demo里复制。

第三个坑是关于手机号的。有些同学想在小程序里做“一键获取手机号”，但这里有一个很容易踩的雷：获取微信手机号能力要求小程序必须完成企业主体认证，个人开发者的小程序是没有这个权限的。如果你的毕业设计没有真实上线需求，建议不要在手机号上纠缠，用户表里用openid作为唯一标识就够了，顶多再加一个“学号”字段让用户手动填写。

JWT部分，生成token只用把userId放进去，不要放敏感信息。过期时间我建议设置7天，既保证用户体验，也不会让token长期有效带来安全隐患。拦截器里校验token，对/api/下的接口做统一鉴权，例外处理登录接口和静态资源路径。

2.5 文件上传与静态资源映射

二手交易和失物招领都需要传图片，所以文件上传是必做功能。最简单的方案是：小程序端用wx.uploadFile把图片传到后端的/api/upload接口，后端保存到服务器的一个目录，比如/data/campus/images/，然后把可访问的URL返回给前端。

关键点是静态资源映射。如果你把文件存到了某个目录，默认情况下Spring Boot是访问不到的，必须在配置类里加映射：

@Configuration public class WebMvcConfig implements WebMvcConfigurer { @Override public void addResourceHandlers(ResourceHandlerRegistry registry) { // 把 /images/** 映射到本地磁盘目录 registry.addResourceHandler("/images/**") .addResourceResolver(new PathResourceResolver()) .addResourceLocations("file:/data/campus/images/"); } }

Windows环境下路径写法是file:D:/campus/images/，Linux/服务器环境下是file:/data/campus/images/。这个路径问题如果不注意，本地调试正常，放到Linux服务器上就显示不了图片，排查起来还挺费劲。

还要考虑一个问题：用户上传的文件名不能直接用原始文件名，因为可能重名或者包含特殊字符。我用的是UUID.randomUUID().toString() + 文件后缀重命名，这样基本不会冲突。文件大小限制在配置里设一下，比如spring.servlet.multipart.max-file-size=5MB，不然大图会把服务器撑爆。

3. 小程序前端：从零搭建完整页面

3.1 全局配置与导航栏设计

小程序前端虽然只用到了WXML、WXSS、JS这三个基础语言，但麻雀虽小五脏俱全。先说app.json全局配置，这是所有页面的基础：

{ "pages": [ "pages/index/index", "pages/release/release", "pages/message/message", "pages/mine/mine", "pages/detail/detail", "pages/myGoods/myGoods" ], "window": { "navigationBarBackgroundColor": "#4A6CF7", "navigationBarTitleText": "校园集市", "navigationBarTextStyle": "white", "backgroundColor": "#f5f5f5" }, "tabBar": { "list": [ { "pagePath": "pages/index/index", "text": "首页" }, { "pagePath": "pages/release/release", "text": "发布" }, { "pagePath": "pages/message/message", "text": "消息" }, { "pagePath": "pages/mine/mine", "text": "我的" } ] } }

导航栏这里有一个高频坑。微信小程序的导航栏分为两部分：顶部状态栏（显示时间、电量）和导航栏（显示标题）。如果你用默认导航栏，navigationBarTitleText直接改文字就行，省事。但如果你想做“自定义导航栏”（比如胶囊按钮穿透效果那种），就需要在页面json里配"navigationStyle": "custom"，然后自己在页面上画导航栏组件。

这时候就要处理状态栏高度和胶囊按钮位置的计算。状态栏高度用wx.getSystemInfoSync().statusBarHeight获取，胶囊按钮位置用wx.getMenuButtonBoundingClientRect()获取。很多新手图省事写死一个高度，结果在不同机型上要么标题偏上要么按钮重叠。正确的做法是把这些值动态计算出来后写入全局数据，自定义导航栏组件从全局读取。

3.2 请求封装与小程序端接口调用

小程序端用wx.request调后端接口，每个页面都写一遍request显然不可取，我把请求统一封装成一个request.js：

const BASE_URL = 'https://your-domain.com/api' function request(url, method, data, header = {}) { return new Promise((resolve, reject) => { wx.request({ url: BASE_URL + url, method: method, data: data, header: { 'Content-Type': 'application/json', 'token': wx.getStorageSync('token'), ...header }, success: (res) => { if (res.data.code === 200) { resolve(res.data.data) } else { wx.showToast({ title: res.data.message, icon: 'none' }) reject(res.data) } }, fail: (err) => { wx.showToast({ title: '网络异常', icon: 'none' }) reject(err) } }) }) }

封装的好处是后续所有页面都能直接request('/goods/list', 'GET', params)这样调用，不用关心header、状态码判断这些重复逻辑。做毕业设计时，这种“工程整洁感”在答辩时很加分。

需要提醒的是：开发环境和线上环境要用不同的BASE_URL。开发者工具里可以填http://localhost:8080/api，但手机真机调试时不能用localhost，必须填你电脑的局域网IP，比如http://192.168.1.108:8080/api。一旦到了上线阶段，就必须换成正式域名。这些切换逻辑放在同一个文件里，用注释标清楚，或者用环境变量区分。

3.3 商品列表分页与“加载更多”

列表页是二手交易系统的门面。第一次进首页加载第一页数据，拉到页面底部触发下一页请求，这种交互叫做“加载更多”。在小程序里实现起来并不复杂：用onReachBottom监听触底事件，再维护 page和hasMore两个状态。

核心逻辑大概是：

let page = 1 let hasMore = true let loading = false async function loadGoods() { if (loading || !hasMore) return loading = true const list = await request(`/goods/list`, 'GET', { page: page, size: 10 }) // 把新数据追加到 goodsList this.setData({ goodsList: this.data.goodsList.concat(list.records) }) // 根据返回记录数量判断是否还有下一页 hasMore = page < list.pages page++ loading = false }

这里有个细节：后端返回的分页结果，我习惯用MyBatis-Plus的Page对象，里面自带records、total、pages、current字段。前端如果不清楚后端返回结构，拿到数据也不知道怎么取。所以前后端接口约定要写清楚，最好在文档里注明分页参数是page和size，返回结构是{records: [], total: 10, pages: 2}。

避坑提示：onReachBottom在页面内容不满一屏时也可能触发，所以必须在onLoad时先加载第一页，确保页面有内容，然后再慢慢加载更多。否则出现“页面还在第一屏，下面已经连续请求了好几页”的bug，体验很差。另外请求期间要加锁，防止用户快速滚动导致重复请求。

3.4 发布页面与图片上传

发布页面是一个表单页，包含标题、描述、分类、价格（二手商品）或位置（失物招领）、图片选择。图片选择用wx.chooseMedia，这个API从基础库2.10.0开始支持，功能更完善，支持拍照和相册选择。

选完图片后调用上传：

wx.chooseMedia({ count: 6, mediaType: ['image'], sourceType: ['album', 'camera'], success: async (res) => { const uploadTasks = res.tempFiles.map(file => { return new Promise((resolve, reject) => { wx.uploadFile({ url: BASE_URL + '/upload', filePath: file.tempFilePath, name: 'file', success: (r) => { const result = JSON.parse(r.data) resolve(result.data.url) }, fail: reject }) }) }) // 全部上传完成后，拿到图片URL数组 const imageUrls = await Promise.all(uploadTasks) } })

注意wx.uploadFile返回的r.data是字符串，如果后端返回JSON，前台要JSON.parse一次，这个细节经常被忽略，导致前端拿不到图片URL，报undefined，排查半天。

发布完成后，通过wx.switchTab跳回首页，并提示发布成功。有一个小技巧：发布新商品后，首页列表数据是缓存的，需要重新加载。最简单的方式是在首页onShow里加一个刷新标志，或每次onShow都重新请求第一页数据。因为switchTab会触发首页的onShow，这样就能保证数据实时同步。

4. 前后端联调与部署上线

4.1 本地联调的三种方式

本地联调是整个开发过程中最容易卡壳的环节。开发者工具默认有“不校验合法域名、web-view（业务域名）、TLS版本以及HTTPS证书”的选项，开发时勾上它就能直接用http://localhost:8080调后端。但真机调试和学生自己手机上预览时，这个选项是不生效的，所以你需要知道另外两种方案。

第一种是局域网IP直连。手机和电脑连同一个WiFi，后端运行的端口是8080，那就把BASE_URL改成http://192.168.x.x:8080/api。前提是电脑防火墙允许外部访问8080端口，这一步很多同学卡住，明明后端启动了，手机却连不上。Windows上可以在防火墙设置里放行Java，或者临时添加8080端口的入站规则。

第二种是内网穿透工具，比如ngrok、natapp这类工具。它们能把你的本地服务映射成一个公网临时域名。如果做校园项目的答辩演示，这种方式最省事，不用买服务器，也能让手机在任何网络下访问到你的后端。

还有一种偏排查功能的方式叫抓包。当接口报错但开发者工具的Network面板看不太明白时，我习惯用Charles这类工具抓包，看请求头和响应体的原始数据。小程序抓包和普通HTTP抓包没有本质区别，配置代理后，你能非常清楚地看到code2Session的返回、图片上传的完整流程、token实际传过去了没有。调试登录模块时，这个能力极其有用。

4.2 上线部署：服务器、域名与HTTPS

毕业设计如果有上线演示需求，建议租一台最基础的云服务器，2核4G就够。操作系统选CentOS或Ubuntu，安装JDK8、MySQL、Nginx，然后把Spring Boot项目打成jar包。

部署的关键命令很简单：

java -jar campus-0.0.1-SNAPSHOT.jar --spring.profiles.active=prod

生产环境配置里，我会把数据库密码、JWT密钥用环境变量注入，避免明文写在配置里。这个细节虽然小，但展示的是安全意识和工程习惯。

小程序上线还有一个硬性门槛：request合法域名必须是HTTPS，且域名需要备案。所以你需要一个域名，解析到服务器IP，配置SSL证书。证书可以用云平台免费的DV证书，有效期一年，续期方便。然后在Nginx里配置反向代理，把443端口的请求转发给8080。

Nginx关键配置大概长这样：

server { listen 443 ssl; server_name your-domain.com; ssl_certificate /etc/nginx/ssl/server.crt; ssl_certificate_key /etc/nginx/ssl/server.key; location /api/ { proxy_pass http://127.0.0.1:8080; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; } }

图片上传的路径也要改成绝对路径，不然Nginx转发时会把/api前缀弄乱，接口404。我在实际部署时踩过一次这个坑，上传接口在本地好好的，上服务器就404，最后发现是Nginxlocation /api/和Spring Bootcontext-path重复导致的。

4.3 常见问题与排查思路

最后把实战中遇到的高频问题整理成一张速查表，代码里、日志里碰上这些情况，按表排查会很快。

排查问题的时候，一个很有用的技巧是先看后端日志。Spring Boot默认的日志输出比较少，可以在application.yml里配置一下MyBatis-Plus的SQL日志：

mybatis-plus: configuration: log-impl: org.apache.ibatis.logging.stdout.StdOutImpl

这样每个SQL语句都会打印出来，参数也能看到。前端传参和后端SQL对不上、中间空值导致SQL条件变化，这类问题一眼就能看出来。这个配置对学习阶段来说比加断点调试更直观。

还有一个小工具推荐：微信开发者工具自带的“Network”面板和“Storage”面板就够了，不必一上来就上Charles。先把自带的Network面板用熟，能看到每个请求的URL、参数、响应和耗时，80%的问题都能定位。

5. 答辩准备和项目扩展的个人经验

这一部分算是额外的加分建议。很多人代码没问题，但答辩时讲不清楚。我的经验是准备一张“系统架构图”和一张“核心流程图”，不需要多精美，白板手绘都行，但要把一条数据从“用户发布”到“列表展示”的完整链路讲明白：小程序表单提交 → 后端Controller接收 → Service处理 → Mapper写入数据库 → 再查询返回到前端。能把这条链路讲清楚，老师就相信这个项目是你自己做的。

扩展方向上，如果做完基础功能还有余力，比较自然的加点是搜索功能。在商品列表接口里加一个keyword参数，用MySQL的LIKE查询匹配标题和描述。这个功能量不大，但实用性很强。另外一个加点是收藏功能，加一张收藏表，在商品详情页加一个“收藏”按钮。这两个方向都不需要改变现有架构，却能体现你对业务的思考。

最后建议所有代码都放到Git仓库里管理，哪怕只有你自己一个人看。每次功能完成就提交一次，commit信息写清楚。这样做的好处是，代码出了问题可以回溯，而且答辩时导师看到你的Git记录，信任度会高很多。

我个人在实际指导这些项目的时候，最大的感受是：毕业设计翻车的原因通常不是技术上多难，而是很多同学一上来就急着写代码，需求没定清楚，表结构设计得一塌糊涂，接口写一半就开始改，最后几天熬夜补bug。如果你正在做这类项目，听我一句劝：前面多花三天时间做设计，后面能少花三周时间返工。数据库表设计好，接口约定列清楚，前后端各自开发，进度会快得超出你的预期。这篇内容把我能想到的关键环节都过了一遍，剩下的就是动手去做了。