企业官网建设流程全解析

做毕设这些年，最怕的就是要么纯网页太老气，要么纯理论没落地。今天要拆的这套“梅州红色文化传承小程序”，是一个典型的Java + SpringBoot + 微信小程序三段式项目，没有什么花哨的算法，但胜在技术栈规整、开发周期可控、演示效果好，尤其适合计算机专业本科毕设，也适合想系统练一遍全栈开发的朋友。

这个项目要解决什么？梅州的红色文化资源丰富，但因为分布散、宣传方式传统，年轻人触达效率低。小程序作为轻量入口，能把场馆介绍、红色故事、文化路线、学习打卡这些东西装进用户手机里，同时对运营方来说，后台可以管理内容、统计访问。所以它本质上是一个“内容展示 + 轻互动 + 后台管理”的信息平台，不是高并发的电商系统，也不是复杂推荐算法项目，它的核心竞争力在于功能完整度、工程规范程度和文档配合度。

无论你是想直接复刻做毕设，还是想借鉴其中的模块设计思路，这篇文章都会把项目从设计、建表、编码到部署的完整链路讲清楚，尤其会重点说那些课程设计和网上烂大街教程里不会写清楚的细节，比如Spring Boot版本坑、微信登录session处理、小程序真机联调等。

1. 项目定位与整体设计：梅州红色文化传承小程序到底在做什么

1.1 需求背景与用户场景

先说需求背景。梅州作为客家人文底蕴深厚的城市，本地有一定数量的红色文化旧址、纪念场馆和教育基地，这些资源天然有教育属性，也有旅游属性。但存在几个现实问题：一是信息碎片化，用户想找一个场馆，可能要翻公众号历史消息、地图App、旅游网站，效率很低；二是内容展示形式单一，多数停留在图文层面，缺乏互动性；三是运营侧没有统一的内容管理入口，更新信息要依赖技术人员或者第三方平台。

小程序端存在的意义就是把这些内容做结构化整合。用户打开小程序，看到的不再是一堆链接，而是分类清晰的红色场馆列表、文化故事列表、纪念活动信息，还可以做收藏、搜索、浏览记录、学习答题。站在毕设角度，这些功能全部是常规CRUD的变体，但组合起来就是一个完整产品，能体现出需求分析能力、数据库设计能力和工程落地能力。

1.2 技术选型：为什么偏偏是Java + SpringBoot + 微信小程序

选型逻辑要讲清楚，不然答辩被问一句“为什么不用PHP”就容易卡壳。

后端选Java + SpringBoot，核心原因是生态稳定、岗位需求大、学习资料多。对毕设来说，SpringBoot解决了传统SSM项目里大量XML配置的痛点，起步快，内嵌Tomcat，打jar包就能跑，不需要单独装容器。MyBatis-Plus再做一层增强，单表CRUD基本不用手写SQL，这在开发效率和答辩讲解上都是实打实的优势。

小程序端选微信小程序而不是H5，一是微信生态天然适合本地文旅类应用传播，扫码即用，不需要下载App；二是小程序原生组件和API能覆盖页面展示、定位、地图、授权登录这些需求；三是对毕设而言，小程序是一个独立的交付物，演示时能直接扫真机，比浏览器里开网页更有“成品感”。

另外要讲清楚的是，这类项目不是分布式微服务架构，不需要Redis集群，不需要MQ，更不需要Spring Cloud那一套。老老实实用单体应用 + 关系型数据库，性能完全够用，架构也更容易被答辩老师理解。过度设计反而是扣分点。

1.3 功能模块规划与页面流转

功能模块按照用户端、管理端来拆。用户端包括：

• 首页：轮播图、热门场馆、推荐故事，本质是几张表的聚合查询。
• 文化地图：场馆地理位置列表，配合地图组件展示。
• 文化内容：红色故事、场馆详情、人物事迹，支持图文混排。
• 学习中心：红色知识答题、学习打卡记录。
• 个人中心：登录状态、收藏列表、浏览记录、意见反馈。

管理端是一个Web后台，包含内容管理、分类管理、用户管理、数据统计。毕设如果只做小程序不做管理后台，数据库里的内容就只能手动插SQL，演示的时候换一条数据都要重启，非常狼狈，所以强烈建议把管理后台加上。

页面流转上，最核心的链路是：用户扫码进入小程序 -> 微信授权登录 -> 浏览首页内容 -> 进入详情页 -> 收藏/分享 -> 个人中心查看记录。这个链路贯穿了登录态管理、数据查询、缓存处理等所有关键技术点。

2. 技术架构与核心细节：SpringBoot后端和小程序端怎么接上

2.1 后端工程结构与统一返回格式

工程结构不要乱，按功能分包比按技术分包更适合毕设展示。我建议这样分：

com.meizhou.culture ├── controller // 接口层 ├── service // 业务层 ├── mapper // 数据访问层 ├── entity // 数据库实体 ├── dto // 前端交互对象 ├── config // 配置类 ├── utils // 工具类 └── common // 统一返回结果、异常处理

用entity还是domain命名不重要，重要的是层次清晰。Controller只做参数接收和结果封装，不写SQL；Service处理业务逻辑；Mapper只做数据库交互。答辩时被问到分层思想，能说出“每一层各司其职、层间通过接口通信”就可以了。

统一返回结果类是所有接口的基础，强烈建议自己写一个，别用Map代替。基础结构就是三个字段：

{ "code": 200, "message": "操作成功", "data": {} }

code用200表示成功，400表示参数错误，401表示未登录，500表示服务器异常。前端拿到code先判断，再决定是渲染data还是弹错误提示。这里有个实操经验：不要在返回对象里把data设计成Object然后强行塞各种类型，建议用泛型Result<T>，调用时指定类型，前端联调时Swagger文档也好看得多。

2.2 微信登录与JWT会话管理

小程序登录和后端会话管理是这类项目最容易写崩的地方。先说登录流程，微信官方要求的是code换openid，不是在小程序端直接拿着用户名密码登录。

具体流程是：小程序端调用wx.login()拿到临时code，把code发送到后端接口；后端拿着code调用微信接口jscode2session，换取openid和session_key；然后后端拿openid去用户表查，查不到就自动注册一个用户；最后后端生成一个token返回给小程序，小程序后续所有请求都带着这个token，后端通过token识别用户身份。

token我推荐用JWT，原因很简单：无状态、自带过期时间、好调试。生成JWT时，把userId和openid作为payload放进去，设置过期时间为7天。后续接口通过拦截器解析token，把userId放到ThreadLocal里供业务层使用。

这里有个容易踩的坑：JWT的密钥不要硬编码在代码里，放到application.yml配置文件中，答辩时还能顺便讲一下敏感信息配置管理。还有一个细节，前端传token时放在请求头里，命名建议走常规的Authorization: Bearer xxx，别自己发明头名称。

2.3 数据库设计：六张核心表怎么建

数据库设计是整个项目的骨架，表结构设计得好，后续开发就是顺水推舟。这套项目我建议建六张表：

第一张user用户表，字段包括id、openid、nickname、avatar、phone、create_time。openid唯一索引，注意不要存session_key，那个是微信侧的秘密，只在登录时使用。

第二张category分类表，字段包括id、name、sort、status。用来区分红色场馆、人物故事、学习资料等大类型。

第三张article内容表，这是核心表，字段包括id、category_id、title、cover_image、content、author、view_count、create_time、status。content字段用text类型存富文本，cover_image存图片URL。这里要注意关联关系：文章和分类是多对一，所以只存category_id即可，不需要中间表。

第四张building（红色场馆）表，如果文章表可以覆盖场馆内容，可以不单独建表，但如果要做地图标记，建议单独建，字段包括id、name、cover、description、address、longitude、latitude、open_time、tel。经纬度字段用decimal存储，后续地图组件直接调用。

第五张favorite收藏表，字段包括id、user_id、article_id、create_time，联合唯一索引uk_user_article防止重复收藏。

第六张answer_record答题记录表，字段包括id、user_id、question_id、user_answer、is_correct、create_time。

这些表全部是标准第三范式设计，没有冗余字段。答辩时如果老师问怎么优化，可以说当数据量增长后，给article表的view_count加缓存，用Redis做热点数据，但毕设阶段直接查库完全没问题。

2.4 小程序端开发和原生API的取舍

小程序端我推荐用原生开发，不推荐为毕设强行上uni-app。原因很直接：原生框架语法简单，WXML + WXSS + JS三件套，资料多，遇到问题好查；uni-app虽然能一套代码多端运行，但调试链路长，编译报错排查起来对新手不友好。

页面结构上，底部tabBar四个页面：首页、地图、学习、我的。tabBar不能超过五个，图标尺寸要求81px * 81px，iconfont不能用，必须用png或jpg，这些是微信官方的硬限制，提前准备好免得后面返工。

有个高频问题：微信小程序顶部导航栏高度怎么适配。不同的手机型号，状态栏高度不一样，如果页面用了自定义导航栏，直接写死高度就会在不同机型上错位。解决方案是获取系统信息里的statusBarHeight和menuButton信息，动态计算。核心代码如下：

const systemInfo = wx.getSystemInfoSync(); const menuButton = wx.getMenuButtonBoundingClientRect(); const navBarHeight = (menuButton.top - systemInfo.statusBarHeight) * 2 + menuButton.height;

这段代码的含义是：胶囊按钮到状态栏底部的距离乘以2，加上胶囊自身高度，就是自定义导航栏的总高度。这个方案能兼容绝大多数机型，不要再在样式表里写死高度了。

3. 实操过程记录：从前端到后端完整落地

3.1 后端项目初始化与Spring Boot版本选择

先说明一个版本上的关键问题：Spring Boot 2.x和3.x有根本性区别，3.x要求Java 17+，javax包全部换成jakarta。如果你本机装的是JDK 8，就不要硬选Spring Boot 3.x，否则一启动就会报ClassNotFoundException: javax.servlet这种错误。稳妥的组合是JDK 8 + Spring Boot 2.7.x + MyBatis-Plus 3.5.x，或者JDK 17 + Spring Boot 3.x + MyBatis-Plus 3.5.3以上版本。

创建项目我推荐用IDEA自带Spring Initializr，选择Java版本、打包方式为jar，依赖先加Web、MySQL Driver、Lombok。注意不要勾选太多依赖，后续手写或者修改pom都来得及，项目结构越简单越不容易出问题。

pom.xml核心依赖就五个左右：spring-boot-starter-web、mybatis-plus-boot-starter、mysql-connector-j、lombok、jjwt（或java-jwt）。额外加一个knife4j或springfox做接口文档，方便调试。MyBatis-Plus版本这里特别提一下：如果你是Spring Boot 2.x，用3.5.3没问题；如果用了Spring Boot 3.x，要选带-jakarta后缀的版本，或者直接用3.5.5及以上，不然启动会报分页插件不兼容。

3.2 配置文件与数据源设置

application.yml配置是项目启动的门面，我一般这样组织：

server: port: 8080 spring: datasource: url: jdbc:mysql://localhost:3306/meizhou_culture?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai username: root password: 123456 driver-class-name: com.mysql.cj.jdbc.Driver mybatis-plus: configuration: log-impl: org.apache.ibatis.logging.stdout.StdOutImpl map-underscore-to-camel-case: true global-config: db-config: logic-delete-field: deleted logic-delete-value: 1 logic-not-delete-value: 0

数据库地址里serverTimezone=Asia/Shanghai一定要写，不然MySQL 8.x连本地库经常报时区错误。map-underscore-to-camel-case开启后，user_id自动映射到userId，少写一堆@TableField注解。逻辑删除配置加上之后，删除操作自动变成update，这对内容管理类项目很实用，误删了还能恢复。

3.3 实体类与Mapper层快速开发

实体类直接和表对应，用Lombok简化getter/setter。以article表为例：

@Data @TableName("article") public class Article { @TableId(type = IdType.AUTO) private Long id; private Long categoryId; private String title; private String coverImage; private String content; private String author; private Integer viewCount; private Integer status; private LocalDateTime createTime; }

@TableName指定表名，@TableId指定主键策略，其他的什么都不用写，MyBatis-Plus就能根据实体类自动生成CRUD。注意实体类字段不要出现Java关键字，比如status没问题，但如果有describe这种字段，在MySQL里就要用反引号。

Mapper层更简单，继承BaseMapper就有单表CURD：

@Mapper public interface ArticleMapper extends BaseMapper<Article> { }

如果你想自定义复杂查询，比如文章列表要连分类名称，就直接在Mapper里写@Select注解SQL，或者写XML。毕设阶段不要搞复杂分页插件以外的花活，保持简单可解释。

3.4 Service和Controller的实现套路

Service层我习惯先写接口，再写实现类。这点很多同学忽略，觉得“就一个类何必写接口”，但答辩时老师很可能问“你理解面向接口编程吗”，到时候有接口就有话讲，没有就容易卡壳。

以ArticleService为例，接口定义三个方法：

public interface ArticleService { PageResult<ArticleVO> pageArticles(int page, int size, Long categoryId); ArticleVO getArticleDetail(Long id); void increaseViewCount(Long id); }

实现类负责拼装逻辑，比如getArticleDetail要先查文章详情，再查相关推荐，还要自增浏览量。这里有个小技巧：自增浏览量不要用“先查出来再加一写回去”，直接执行一条UPDATE语句UPDATE article SET view_count = view_count + 1 WHERE id = ?，避免并发下数据不准。

Controller层只做参数接收和调用：

@RestController @RequestMapping("/api/article") public class ArticleController { @GetMapping("/page") public Result<PageResult<ArticleVO>> page(@RequestParam(defaultValue = "1") int page, @RequestParam(defaultValue = "10") int size, @RequestParam(required = false) Long categoryId) { return Result.ok(articleService.pageArticles(page, size, categoryId)); } @GetMapping("/{id}") public Result<ArticleVO> detail(@PathVariable Long id) { return Result.ok(articleService.getArticleDetail(id)); } }

参数校验用@Validated比手写if判断更规范，比如分页参数范围、ID不能为负数。统一异常处理类用@RestControllerAdvice捕获异常，把兜底错误信息返回给前端，避免一报错就弹出500裸错误码。

3.5 小程序端请求封装与页面渲染

小程序端最重要的封装是request方法。我见过太多同学在每个页面里直接写wx.request，改个baseURL要满项目替换，这是很不好的习惯。建议在utils目录下建一个request.js：

const BASE_URL = 'https://your-domain.com/api'; function request(path, method = 'GET', data = {}) { return new Promise((resolve, reject) => { wx.request({ url: BASE_URL + path, method, data, header: { 'Content-Type': 'application/json', 'Authorization': wx.getStorageSync('token') || '' }, success(res) { if (res.statusCode === 200 && res.data.code === 200) { resolve(res.data.data); } else if (res.data.code === 401) { wx.navigateTo({ url: '/pages/login/login' }); reject(res.data); } else { wx.showToast({ title: res.data.message, icon: 'none' }); reject(res.data); } }, fail(err) { wx.showToast({ title: '网络异常', icon: 'none' }); reject(err); } }); }); } module.exports = { request, get: (p) => request(p, 'GET'), post: (p, d) => request(p, 'POST', d) };

这段代码有三个关键设计：一是Promise化，后续页面里可以用async/await，写起来像同步代码；二是统一处理业务码，不用每个页面重复写判断；三是token从storage里取，登录后写入，退出时删除，全局只在这里维护。

页面渲染时注意一个问题：微信小程序里setData是高频性能瓶颈，不要在循环里频繁修改data。像首页轮播图、列表这种数据，一次setData传整个数组就行，不要在onShow里反复刷新，真有下拉刷新需求再用enablePullDownRefresh。

3.6 答题与学习模块的实现思路

学习答题模块是给整个平台加教育属性的关键功能。实现方式是：题库表存放题目，答案表记录用户作答情况。每次用户从题库里随机取十道题，前端展示题干和四个选项，提交后后端逐个比对答案，返回得分和错题详情。

这里一个设计上的坑是：选择题答案不要在数据库里存“A、B、C、D”，而是直接存正确选项的text内容。不然以后题干或者选项顺序调整，历史答题记录就全对不上了。对毕设来说，答案字段直接存“正确选项内容”反而是更简单可靠的设计。

4. 部署联调与常见问题排查：从本地到线上

4.1 本地开发调试：小程序开发者工具的联调配置

本地开发阶段，小程序不能直接请求localhost:8080，因为微信开发者工具模拟器里的网络环境和电脑本地有隔离，我们要开启“不校验合法域名”选项。位置在开发者工具的详情-本地设置里，勾选“不校验合法域名、web-view（业务域名）、TLS版本以及HTTPS证书”。

但有个问题，真机预览时这个选项是不生效的，手机上的小程序必须走HTTPS协议。所以建议本地调试用开发者工具的模拟器，提交体验版之后再用真机。如果你有云服务器，直接绑域名配SSL证书最省事；如果没有，也可以先用内网穿透工具做临时调试，但只建议开发时用，演示时稳定性不如部署到服务器。

4.2 后端打包与服务器部署

后端部署这块是很多毕设翻车的地方。在IDEA里执行mvn clean package后，target目录下会生成一个xxx.jar文件。上传到服务器后，启动命令很简单：

java -jar meizhou-culture-0.0.1.jar --spring.profiles.active=prod

生产环境的数据库地址、账号密码放到application-prod.yml里，不要在默认配置里写死。服务器内存小的，可以在启动命令上加JVM参数限制堆内存：

java -Xms256m -Xmx512m -jar meizhou-culture-0.0.1.jar

用nohup放在后台运行：

nohup java -jar meizhou-culture-0.0.1.jar > app.log 2>&1 &

因为小程序要求HTTPS，域名要配置SSL证书，Nginx做反向代理，把https://your-domain.com/api代理到http://127.0.0.1:8080/api。Nginx配置里要注意proxy_set_header X-Real-IP $remote_addr;，不然后端拿不到真实用户IP，访问日志统计不准确。

4.3 常见问题速查表

把我在实际开发和帮助学生调试过程中遇到的高频问题整理成一张表，方便对照排查：

4.4 答辩前最容易忽略的三件事

答辩时技术演示不是最难的，难的是细节。第一个容易被忽略的是接口文档，用knife4j生成的Swagger页面提前打开，现场演示接口调用，比在IDEA里debug有说服力。第二个是准备好演示数据，不要在答辩现场才往数据库里插内容，至少准备十条新闻类数据、五条场馆数据、一套完整答题题目。第三个是设计好演示脚本，从首页开始，到详情页，再到收藏和答题，按真实用户路径走一遍，不要想起来点什么点什么。

5. 提升点与后续扩展方向

5.1 给项目加分的“性价比”功能

如果时间有富余，按投入产出比排序，这几个功能最容易加分。

第一，地图导航。微信小程序原生支持map组件，把场馆表的经纬度传给markers，点标记弹出场馆简介，点击“去这里”唤起wx.openLocation调起地图导航。这个功能代码量不大，但演示效果非常直观，把红色文化场馆分布在哪个位置一目了然。

第二，内容搜索。搜索功能在小程序端就是一个搜索框加列表页，后端用LambdaQueryWrapper加一个like条件，重点是要处理关键词为空时返回空列表而不是全部数据。这个可以提前做，也很实用。

第三，分享裂变。在小程序的onShareAppMessage里配置分享标题和图片，用户分享给好友后，好友打开小程序可以填写“通过谁分享”的关系字段。这个功能在毕设里代表了对微信开放能力的了解，也是答辩时的一个亮点。

5.2 如果真的想上难度：Redis缓存与数据统计

如果你的水平已经超过了基本CRUD，可以把Redis引进来。比如首页轮播图和热门内容，用Redis缓存一个小时，缓存失效后再回源查数据库。这个改动只需要引入spring-boot-starter-data-redis，在Service层加一个逻辑判断即可。

另一个有深度的问题是数据统计看板：管理后台统计用户活跃量、每日浏览数、收藏量Top10、场馆热度排行。这些数据可以从favorite表、article表里聚合查询出来，用ECharts画折线图和柱状图。这个功能做出来后，整个项目的“数据运营”属性就出来了，评委和老师会明显感觉到你的项目不是玩具，而是有真实使用场景的。

6. 项目总结与个人实操体会

做这个梅州红色文化传承小程序的完整流程走下来，我最大的体会是：毕设项目不是越难越好，而是越完整越好。

什么叫完整？需求分析里能说清楚目标和用户，数据库设计里有主外键和索引组建，后端工程里有统一异常和日志处理，小程序端不是简单页面拼凑，而是有登录态和请求封装，部署环节能跑通HTTPS真机访问。这些点每一个单独的难度都不高，但能把它们整合到一起，就需要对整个web开发链路有比较全面的理解。

给我印象最深的一个细节是微信登录流程。很多教程直接给代码，但没讲清楚为什么code要用一次就失效，为什么后端要用openid而不是session_key做身份标识。当我把wx.login到code2Session到JWT签发的完整链路在一个白板上画出来，并且用postman一步步验证的时候，才真正有“这个项目是我自己做的”的感觉。

如果你正在做类似的毕设，我的建议是：不要急着写代码，先花几天时间把表结构设计好，把接口清单列出来，然后一个模块一个模块推。碰到问题不要怕，微信的报错提示虽然有点绕，但互联网上资料非常多。最重要的是，每个功能做完以后，要跑一遍测试用例，不要等到答辩前一天才发现页面白屏。项目代码是一方面，但你在调试过程中积累的排错思路，才是答辩时真正能发挥的东西。