企业官网建设流程全解析

每年到毕业季，总有一大批人被毕设题目卡住。选题库里那些"XX管理系统""XX平台设计与实现"看着都差不多，真要动手才发现：要么技术栈太老，论文写出去毫无亮点；要么工作量太大，三个月搭不完一个能跑的系统。今天我拿一个具体的题——Spring Boot钓鱼爱好者交流平台APP设计与实现，把整套从选题、架构、编码到论文答辩的完整链路拆开讲。这个题目属于典型的"前后端分离 + 移动端 + 业务社交"型毕设，Spring Boot负责后端接口，APP端承载用户交互，核心价值在于麻雀虽小五脏俱全：登录鉴权、内容发布、社交互动、地图打卡、消息推送全都能覆盖。你只要把这条线走通，论文有得写、答辩有得讲、代码拿得出手，无论你是准备自己动手做，还是想判断手里买的源码到底行不行，这篇都能给你一条清晰的判断标准。

1. 为什么我推荐你选这个题目：一个看似普通的毕设背后的完整生态

很多同学一听到"钓鱼"就觉得这题目小众，担心导师不认可、评审觉得low。实际上恰恰相反，我在帮人评估毕设题目的时候，最看重的不是题目听起来多高大上，而是这题目能不能覆盖足够多的技术点、能不能写出有逻辑的论文、做完之后能不能讲清楚。钓鱼爱好者交流平台这三个关键词——爱好者(用户体系)、交流(社区互动)、平台(系统架构)——每一层都有文章可做。

从用户侧看，游客、注册用户、管理员是三种基础角色；从业务侧看，发帖、回帖、点赞、收藏、关注、约钓组队是典型社交动作；从场景侧看，钓点分享需要地理位置、天气信息，约钓需要时效性。你把这些拆开看，每个模块单独拎出来都是Spring Boot开发里的常见考点，合在一起又是一个完整的闭环。导师看到的是"这学生能独立设计一个多角色、多模块的系统"，而实际上你只是把几个成熟套路组合了一次。

再说技术选型的稳妥性。Spring Boot是当前企业级Java开发的事实标准，光这一个框架就串起了Spring IOC、Spring MVC、MyBatis、Maven、RESTful API一堆知识点。APP端无论你用uni-app、Flutter还是Android原生，都能跟后端通过JSON做数据交换。这套组合意味着你在简历上写"熟悉Spring Boot开发、理解前后端分离架构"是完全站得住脚的，不像纯JSP+Servlet那种老古董，做完即失业。

我还要提醒一点：钓鱼这个垂直领域有个天然优势，就是数据模型贴近真实生活，容易做功能延展。你觉得"钓点打卡"不就是发个定位吗？但往深处走，它可以关联经纬度、天气、鱼种、水深、潮汐，甚至可以做一个基于地理位置的附近钓点推荐。这种延展空间在你论文"系统展望"章节里特别加分，答辩时老师问"你这个系统还能怎么优化"，你张口就能说出三四个方向。

2. 技术架构怎么搭：先用一张图想清楚再动手指

很多人做毕设的习惯是启动IDE就开写，写到数据库那张表了才开始想字段。这是个节奏陷阱。我建议你拿到题目后，第一件事不是敲代码，而是花一个晚上把下面三件事定下来：技术栈、包结构、接口风格。这三件事定了，后面所有代码都是在填空。

2.1 技术栈选型：不用追新，但要够主流

我推荐的组合是这套，这也是市面上绝大多数同类源码采用的方案：

这里特别说下为什么Spring Boot选2.7.x而不是最新的3.x。毕设的核心目标是稳，你答辩的时候演示到一半报个依赖冲突的错，整个心态就崩了。2.7.x这个版本线的第三方资料、踩坑贴、搜索引擎结果都是最丰富的，你遇到任何诡异问题都能找到答案。3.x的jakarta命名空间迁移、Spring Security配置变化对新手来说都是不必要的风险。

2.2 后端包结构：这不是形式主义，是你论文里的体系图

一个规范的分层包结构长这样：

com.fishing.app ├── controller // 接口层：接收请求、返回结果 ├── service // 业务层：处理核心逻辑 │ └── impl ├── mapper // 数据访问层：MyBatis-Plus的Mapper接口 ├── entity // 实体类：对应数据库表 ├── dto // 数据传输对象：接收前端参数 ├── vo // 视图对象：返回给前端的数据结构 ├── config // 配置类：WebMvc、拦截器、跨域等 ├── common // 公共类：统一返回结果、异常处理、常量 ├── utils // 工具类：JWT工具、日期工具等 └── interceptor // 拦截器：登录校验、权限控制

别小看这个结构，它就是你论文第三章"系统设计"里架构图的代码映射。很多同学论文里画得漂漂亮亮，代码却全写在一个Controller里，答辩时一翻代码就露馅。分层清晰还有一个实际好处：你调bug的时候能快速定位是参数问题、逻辑问题还是SQL问题。接口层报错先查参数，业务层报错打断点查逻辑，数据层报错看SQL——排查链路极其高效。

2.3 统一返回体：一个类减少80%的接口沟通成本

前后端分离开发最容易翻车的点就是接口返回值约定不统一。今天这个接口返回{code:0, data:{}}，明天那个接口返回{success:true, result:{}}，APP端解析的时候写一堆if else，迟早要疯。我的做法是从第一个接口开始就用统一的R对象：

@Data public class R<T> { private Integer code; // 200成功，500失败，401未登录 private String message; // 提示信息 private T data; // 业务数据 public static <T> R<T> ok(T data) { R<T> r = new R<>(); r.setCode(200); r.setMessage("success"); r.setData(data); return r; } public static <T> R<T> fail(String message) { R<T> r = new R<>(); r.setCode(500); r.setMessage(message); return r; } public static <T> R<T> unauthorized(String message) { R<T> r = new R<>(); r.setCode(401); r.setMessage(message); return r; } }

这个类一写，前后端联调的效率直接翻倍。APP端只需要封装一个网络请求工具，判断code等于200就走成功逻辑，否则弹message提示，不用每个接口单独写解析。而且你这个类放在common包里，论文里写"设计了统一的接口返回结构，规范了前后端数据交互格式"——一句话就是一个得分点。

3. 数据库设计：钓鱼平台的表结构背后藏着哪些业务思考

数据库是毕设的基础设施，也是论文评审老师最爱翻的地方。很多人的表设计错误在于一上来就堆字段，缺乏关联设计。钓鱼交流平台的核心表不用多，七八张足够，但每一张都要有存在的理由，表与表之间的外键关系要经得起推敲。

3.1 核心表清单与职责划分

这套设计的核心逻辑是：用户产生内容，内容围绕钓点展开，互动促进活跃。你看post表里有个topic_id，这就是给帖子打话题标签，比如"装备交流""钓获分享""新手求助"，有了这个字段，首页就能做话题分区，功能看板上多了一个维度。

3.2 点赞、评论这种"频繁写"的数据为什么要单独建表

有个很常见的错误做法：在post表里直接加一个like_count字段，用户点赞就+1，取消就-1。这样省事是省事，但你没法判断"当前用户是否点赞过这个帖子"——除非你在post表里加liked_by_current_user，那更荒谬。正确的做法是点赞记录单独一张表，user_id + post_id建立唯一索引，查的时候判断记录是否存在；帖子的like_count可以作为冗余字段定期更新，也可以每次count一下，毕设规模建议后者，简单不容易出错。

3.3 地理坐标字段的类型选择

钓点打卡必然涉及经纬度。这里有个新手容易忽略的细节：经纬度字段不要用float，要用decimal(10, 6)。float是浮点数，存经纬度会出现精度误差，而且经纬度本身是一个"度"的概念，decimal精确到小数点后6位已经能定位到米级精度。查询附近钓点的时候，用一个简单的范围条件就好：

SELECT * FROM fishing_spot WHERE lat BETWEEN #{lat} - 0.05 AND #{lat} + 0.05 AND lng BETWEEN #{lng} - 0.05 AND #{lng} + 0.05

这个范围大概是半径5公里左右，作为毕设功能演示足够了。不用引入专业的GIS函数，答辩时你说"通过经纬度范围查询实现附近钓点检索"，这个答案既合理又不过度设计。当然你可以在论文里提一句"后续可引入Elasticsearch或PostGIS进一步提高地理位置检索性能"，显得你有扩展意识。

3.4 用户密码的存储方式

这个话题老生常谈，但每次看别人的毕设代码我都还是忍不住皱眉——明文密码一抓一大把。正确做法是使用Spring Security自带的BCryptPasswordEncoder，或者用MyBatis-Plus的加密工具。这里给一段最常见的写法：

// 注册时加密存储 String encodedPwd = new BCryptPasswordEncoder().encode(user.getPassword()); user.setPassword(encodedPwd); // 登录时校验 boolean matches = new BCryptPasswordEncoder().matches(rawPassword, user.getPassword());

BCrypt的好处是自动加盐，同一个密码每次加密出来的密文都不同，安全性远高于MD5。这虽然只是一个小细节，但在论文里可以写进"系统安全设计"章节，答辩的时候老师问"密码安全你怎么做的"，你答一句"使用BCrypt加盐哈希"就能瞬间显得专业。

4. 后端核心功能实拆：登录鉴权、发布帖子、附近钓点、组队约钓

4.1 登录鉴权：JWT的完整落地过程

APP端和后端之间没有Session的概念（或者说用Session跨端很痛苦），所以JWT成了移动端鉴权的标配。JWT的原理通俗讲就是：用户登录成功后，服务器生成一张带签名的"通行证"，客户端拿着这张通行证访问受保护的接口，服务器验签通过就放行。这张通行证本身携带用户id、过期时间等信息，不需要服务端保存状态。

落地过程分三步走：

第一步，写一个JWT工具类，负责生成和解析Token：

@Component public class JwtUtils { // 密钥，实际项目放配置文件，毕设写在常量里也行 private final String secret = "your-secret-key"; private final long expire = 7 * 24 * 60 * 60 * 1000; // 7天有效期 public String generateToken(Integer userId, String role) { return Jwts.builder() .setSubject(String.valueOf(userId)) .claim("role", role) .setIssuedAt(new Date()) .setExpiration(new Date(System.currentTimeMillis() + expire)) .signWith(SignatureAlgorithm.HS256, secret) .compact(); } public Integer parseToken(String token) { Claims claims = Jwts.parser() .setSigningKey(secret) .parseClaimsJws(token) .getBody(); return Integer.parseInt(claims.getSubject()); } }

第二步，写一个登录接口：

@PostMapping("/auth/login") public R<LoginVO> login(@RequestBody LoginDTO dto) { // 1. 根据username查用户 LambdaQueryWrapper<User> wrapper = new LambdaQueryWrapper<>(); wrapper.eq(User::getUsername, dto.getUsername()); User user = userMapper.selectOne(wrapper); // 2. 校验密码 if (user == null || !bcrypt.matches(dto.getPassword(), user.getPassword())) { return R.fail("用户名或密码错误"); } // 3. 生成Token String token = jwtUtils.generateToken(user.getId(), user.getRole()); LoginVO vo = new LoginVO(); vo.setToken(token); vo.setNickname(user.getNickname()); vo.setAvatar(user.getAvatar()); return R.ok(vo); }

第三步，写一个拦截器，拦截所有需要登录的接口：

@Component public class LoginInterceptor implements HandlerInterceptor { @Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { String token = request.getHeader("Authorization"); if (token == null) { response.setStatus(401); return false; } try { Integer userId = jwtUtils.parseToken(token); // 把用户id放到request作用域，方便Controller里取 request.setAttribute("userId", userId); return true; } catch (Exception e) { response.setStatus(401); return false; } } }

然后在WebMvcConfig里注册拦截器，同时放行登录、注册和钓点列表这些公开接口。这里有个细节：拦截器只做"是否登录"的校验，"是否有权限"（比如删除别人的帖子）要在Service层校验。因为有些权限判断需要查数据库，放在拦截器里会写得很别扭，放业务层拿当前用户id和目标资源的owner_id做比对，逻辑一清二楚。

4.2 帖子发布与图片上传：前端两难问题的后端解法

发帖子一定是图文混排吗？如果是，前端编辑器的复杂度会直线上升。毕业设计我建议做一个折中方案：帖子内容用文本，图片支持多图上传单独展示。具体实现方式是：前端先调/file/upload接口把图片传到服务器，拿到图片URL数组；再调/post/create接口，content字段传文本，images字段传JSON字符串数组。

后端接收文件上传也简单：

@PostMapping("/file/upload") public R<String> upload(@RequestParam("file") MultipartFile file) { if (file.isEmpty()) { return R.fail("上传文件不能为空"); } // 1. 校验文件类型 String originalFilename = file.getOriginalFilename(); String suffix = originalFilename.substring(originalFilename.lastIndexOf(".")); if (!Arrays.asList(".jpg", ".jpeg", ".png", ".gif").contains(suffix.toLowerCase())) { return R.fail("仅支持图片格式"); } // 2. 生成存储文件名，防止文件名冲突 String fileName = UUID.randomUUID().toString().replace("-", "") + suffix; // 3. 存储到本地目录 File dest = new File("D:/fishing-app/upload/" + fileName); file.transferTo(dest); // 4. 返回可访问的URL String url = "/upload/" + fileName; return R.ok(url); }

这里有个坑必须提醒：MultipartFile.transferTo方法的目录必须存在，否则会报FileNotFoundException。所以upload接口在存储之前要dest.getParentFile().mkdirs()。还有文件大小限制，Spring Boot默认上传文件上限是1MB，需要在application.yml里调大：

spring: servlet: multipart: max-file-size: 10MB max-request-size: 20MB

图片URL的访问映射也要配好。如果图片放在本地D:/fishing-app/upload/，可以用WebMvcConfigurer把/upload/**映射到这个目录：

@Override public void addResourceHandlers(ResourceHandlerRegistry registry) { registry.addResourceHandler("/upload/**") .addResourceHandler("file:D:/fishing-app/upload/"); }

这样APP端直接访问/upload/xxx.jpg就能显示图片。切记部署演示的时候，图片路径要跟你讲PPT的电脑路径一致，否则换台机器图片全挂——这个问题我在后面避坑章节还会提到。

4.3 附近钓点检索与详情页

钓点打卡是钓鱼平台的特色功能，它的核心数据链路是：用户发布钓点（写名称、描述、经纬度、上传图片）→ 其他人打开地图或列表查看附近钓点 → 点进详情看到完整信息和发布者的评论。

后端接口设计上，我推荐提供两个接口：

1. GET /spot/list?lat=&lng=范围查询附近钓点，返回列表（只要id、名称、图片、评分、距离）
2. GET /spot/{id}钓点详情，包含全部字段和发布者信息

距离计算可以用Haversine公式，也可以在列表查询返回时简化处理。不过毕设演示场景，前端拿到经纬度后可以调用高德地图API来渲染地图和点位，你根本不需要自己算距离——前端地图SDK已经帮你算好了。后端只需要保证lat和lng字段能准确入库和查询出来。

发布钓点这个动作本身不难，难在钓点名称和地图定位的联动。常见的做法是：前端调高德地图的搜索框组件，用户输入钓点名称后选择地图上的点，然后把该点的经纬度传给后端。这样在前端就完成了"名称→坐标"的转换，后端的活就简单了。

4.4 组队约钓与消息通知：引入WebSocket让系统"活"起来

组队约钓的业务逻辑是：用户创建一个组队活动（填标题、钓点、开始时间、人数上限），其他人看到后可以报名加入，人数满了自动满员。这个功能背后涉及两张表：group_activity(活动)和group_member(报名记录)。

报名接口的逻辑是：

@PostMapping("/group/join") public R<String> joinGroup(@RequestBody JoinGroupDTO dto, @RequestAttribute Integer userId) { GroupActivity activity = groupActivityMapper.selectById(dto.getGroupId()); // 1. 校验活动是否存在 if (activity == null) { return R.fail("活动不存在"); } // 2. 校验活动是否满员 Long currentCount = groupMemberMapper.selectCount( new LambdaQueryWrapper<GroupMember>() .eq(GroupMember::getGroupId, dto.getGroupId())); if (currentCount >= activity.getMaxPeople()) { return R.fail("活动已满员"); } // 3. 校验是否重复报名 Long alreadyJoined = groupMemberMapper.selectCount( new LambdaQueryWrapper<GroupMember>() .eq(GroupMember::getGroupId, dto.getGroupId()) .eq(GroupMember::getUserId, userId)); if (alreadyJoined > 0) { return R.fail("您已报名该活动"); } // 4. 插入报名记录 GroupMember member = new GroupMember(); member.setGroupId(dto.getGroupId()); member.setUserId(userId); groupMemberMapper.insert(member); return R.ok("报名成功"); }

别看这段代码简单，它其实覆盖了后端开发最重要的一个习惯：任何写操作之前，先想清楚"这个操作在什么情况下会非法"。活动不存在、活动满员、重复报名、活动已开始、活动已取消，你把这些边界情况过滤完，接口才是一个健壮的生产级接口。

组队报名成功之后，给活动发起人发一条通知。这个通知可以用WebSocket实现实时推送。架构很简单：后端维护一个WebSocket连接池，用户id和连接对象建立映射。有人报名成功时，后端拿到活动发起人的id，从他的连接里推送一条消息。WebSocket的配置类大概长这样：

@Component @ServerEndpoint("/ws/{userId}") public class WebSocketServer { private static ConcurrentHashMap<Integer, Session> sessions = new ConcurrentHashMap<>(); @OnOpen public void onOpen(Session session, @PathParam("userId") Integer userId) { sessions.put(userId, session); } @OnClose public void onClose(@PathParam("userId") Integer userId) { sessions.remove(userId); } public static void sendMessage(Integer userId, String message) { Session session = sessions.get(userId); if (session != null && session.isOpen()) { session.getAsyncRemote().sendText(message); } } }

需要注意，这个类不能直接用Spring的@Autowired注入Mapper（因为WebSocket是多实例的，跟Spring单例Bean的管理方式不同），需要静态工具类或者手动从SpringContext取。这个坑能卡住很多人，你要是卡住了，多半是注入失效了。

5. APP端怎么做：uni-app双端适配的关键路径

后端接口搞定之后，APP端的活其实就两件事：写界面、调接口。但很多做毕设的同学偏偏在这一步翻车，原因无非是：选了Android原生开发但不会Java的UI布局，或者选了Flutter发现自己连环境都跑不起来。我的建议很明确：如果你的目标是"顺利毕业+论文有料"，选uni-app(Vue3) + HBuilderX。

5.1 为什么是uni-app而不是Flutter或Android原生

对于大多数毕设场景，uni-app的效率优势是碾压级的。你不需要学习Android的生命周期、不需要处理屏幕适配、不需要为系统版本差异头痛，专注写好Vue组件就能出界面。而且答辩的时候你掏出手机扫码，同一套代码在安卓和iOS上都能跑，这个演示效果本身就加分。

5.2 网络请求封装：把后端错误处理统一到前端

在uni-app里，我用一个简单的Promise封装来统一所有接口请求：

// utils/request.js const BASE_URL = 'http://localhost:8080/api' export function request(path, method = 'GET', data = {}) { return new Promise((resolve, reject) => { uni.request({ url: BASE_URL + path, method: method, data: data, header: { 'Authorization': uni.getStorageSync('token') || '' }, success: (res) => { // 后端统一返回 { code, message, data } if (res.data.code === 200) { resolve(res.data.data) } else if (res.data.code === 401) { // Token失效，跳转登录页 uni.navigateTo({ url: '/pages/login/login' }) reject(res.data) } else { uni.showToast({ title: res.data.message, icon: 'none' }) reject(res.data) } }, fail: (err) => { uni.showToast({ title: '网络异常', icon: 'none' }) reject(err) } }) }) }

这个封装的精髓在于：每个页面不需要重复写Token传递和错误处理。登录成功把Token存到uni.setStorageSync('token')，之后所有请求自动带上。后端返回401就自动跳登录页，返回其他错误码就自动弹提示。配合这个封装，你写一个发布帖子页面只需要关心表单本身，其他事情都被抹平了。

5.3 核心页面骨架：首页信息流、钓点地图、个人中心

APP端最少需要这几个页面才能撑起完整演示：

1. 首页信息流：帖子列表 + 话题分类Tab。用onPullDownRefresh实现下拉刷新，页面滚动到底部自动加载下一页（onReachBottom）。
2. 钓点地图页：调用<map>组件 + 高德地图定位，把后端返回的钓点列表用markers属性渲染到地图上，点击marker弹窗显示钓点名称和评分，点击跳转详情。
3. 发布页：表单 + 多图上传。图片用uni.chooseImage选择，uni.uploadFile逐个上传拿到URL，最后拼装数据提交。
4. 消息页：用户私信、系统通知、组队邀请分类展示。WebSocket收到消息后更新红点提示。
5. 个人中心：用户信息、我的发布、我的收藏、我的组队、设置（退出登录）。

这五个页面做完，整个APP的闭环就通了。你在论文里画功能结构图的时候，按"首页/钓鱼圈/消息/我的"四个底部Tab来组织，层级关系一目了然。

5.4 演示环境的一个大坑：后端地址别写死

很多人的后端地址写的是http://localhost:8080，在模拟器上跑没毛病，一旦要在真机上演示就完蛋——手机访问不了你电脑的localhost。正确的做法是：后端启动时让它监听0.0.0.0，然后把BASE_URL改成你电脑在局域网里的IP地址，比如http://192.168.1.101:8080。手机和电脑连同一个WiFi，就能正常访问。这个坑每年都能绊倒一批人，答辩现场不过的很多都是死在这上面。

如果要在Android模拟器上调试，注意模拟器里访问宿主机不能用localhost，要用10.0.2.2。真机调试则直接用局域网IP。我建议你答辩前专门写一个小页面测试一下网络连通性，排除这些低级问题。

6. 论文怎么写才不翻车：从目录逻辑到答辩高频问题

很多同学代码写完就松口气，觉得论文随便凑凑就行。事实上，答辩翻车的人十个里有八个是论文的问题，而不是代码的问题。代码只要真跑通了，老师操作几下发现功能正常，这一关就过了；但论文里逻辑混乱、前后矛盾，老师三五个问题就把你问倒了。

6.1 论文目录的建议主线和每章字数参考

这个结构是毕设论文最稳妥的写法，你不需要创新，只需要把每一章写实。第五章系统实现是整个论文的重头戏，我的建议是每个功能模块配2-3张截图（前端界面+后端接口返回），代码贴关键片段而不是全部贴，配合文字描述"实现思路"。

写技术介绍的时候有个硬性要求：不要大段复制教材。老师一眼就能看出来你写的内容自己都没读懂。正确做法是"用自己的话概括 + 点名要用的具体技术点"。比如写MyBatis-Plus，你可以说"本系统采用MyBatis-Plus作为持久层框架，利用其内置的通用Mapper接口实现单表CRUD操作，通过LambdaQueryWrapper构造查询条件，配合PaginationInnerInterceptor实现分页"，这段文字同时提到了三个具体技术点，答辩被问到"你MyBatis-Plus怎么用的"，你能说出具体用法，老师就知道你确实用了。

6.2 答辩高频问题与应答框架

我把这些年收集到的答辩问题归一下类，基本跑不出下面这十个：

1. 为什么选Spring Boot而不是Spring MVC？应答要点：Spring Boot自动配置简化了项目搭建，内嵌Tomcat无需单独部署，生态丰富便于集成MyBatis、Redis等组件，适合快速开发前后端分离的后端服务。

2. JWT和Session有什么区别？为什么APP端用JWT？应答要点：Session是服务端存储状态，需要依赖Cookie；JWT是无状态的，客户端存储Token即可，天然适合APP端这种没有Cookie机制的客户端，也方便服务端水平扩展。

3. 如果有10万个钓点，附近查询怎么优化？应答要点：当前用经纬度范围查询，数据量大了可以引入MySQL的spatial索引或使用Elasticsearch的地理位置查询，也可以按城市或区域预分区建索引。

4. Redis在你的系统里起到了什么作用？应答要点：缓存热点钓点数据、存储短信验证码、可以配合拦截器做接口幂等性校验和限流。如果只写了JWT没用Redis，就如实说Redis用于验证码存储和热点缓存。

5. 你的系统存在什么不足？应答要点：并发处理能力有限、地理位置检索精度不高、缺少内容审核机制、UI交互细节有待优化。答辩老师说不足就点头，说一句"后续会从XX方向改进"。

6. APP端如何实现消息实时推送？应答要点：WebSocket长连接 + 服务端维护连接池，有业务消息时主动推送给指定用户。被问到断线重连、消息补发（用户离线时消息存到MySQL，上线后拉取未读消息）就说这是后续的优化方向。

7. 密码加密为什么要用BCrypt？应答要点：BCrypt是加盐哈希算法，每次加密结果不同，即使两个用户密码相同存储的密文也不同，抗彩虹表攻击能力强。MD5无盐且运算速度快，反而不安全。

8. 分页查询怎么实现的？应答要点：MyBatis-Plus的PaginationInnerInterceptor，前端传pageNum和pageSize，拦截器自动拼接LIMIT语句。部分教程里还会提一句逻辑分页和物理分页的区别，物理分页是数据库层面LIMIT，逻辑分页是把数据全查出来在内存里分页，物理分页性能更好。

9. 你系统里有哪些安全策略？应答要点：JWT鉴权、密码BCrypt加密、拦截器控制接口访问权限、统一异常处理和参数校验、上传文件时校验文件类型。这三四个点答出来就够了。

10. 为什么选择uni-app做APP？应答要点：跨平台复用一套代码，开发效率高；基于Vue语法，团队熟悉；生态中有现成的地图、上传、权限等组件，减少了原生开发的工作量。

回答这些问题的原则是：用你代码里真实的实现细节去答。你代码里写了什么就说什么，别去背那些百度来的空话套话。老师其实能看出来你到底做没做，真实细节一讲就让人信服。

7. 我踩过的坑，你大概率也会踩：毕设时间线建议

开头那些热词里有一堆奇怪的推荐词，但"spring boot四层架构""spring boot目录规范""spring boot actuator未授权访问"这几个词我想单独拉出来说说。四层架构和目录规范我前面已经讲透了，actuator这个点要特别提醒：Spring Boot Actuator会暴露一些运维监控接口，如果没做好安全控制，/actuator、/actuator/env、/actuator/heapdump等端点可能泄露系统配置信息和内存数据。虽然毕设不会有人真的攻击你，但论文安全测试章节写一条"系统对Actuator端点进行了权限控制"或者直接不引入这个依赖，都能避免答辩时被问倒。

7.1 前松后紧是毕设最大的杀手

以三个月为周期，我给一个经历过实战检验的时间安排参考：

大多数人倒在第8-10周。原因不是代码难写，而是第4周之后就没往后端加新接口，APP端联调的时候发现缺这个缺那个，反反复复改后端。所以我的建议是：开发阶段每完成一个后端模块，立刻拿Postman把所有接口测一遍，然后再做下一个模块。接口全部稳了之后才进入前端页面开发，这时候你会非常舒服——调接口几乎不用改后端。

7.2 演示环境的黄金准则：备份一套离线环境

答辩那天网络是最大的不可控因素。你的APP要调高德地图、要访问后端MySQL，万一答辩现场WiFi抽风，整个演示就瘫了。我吃过这个亏，现在养成的习惯是：答辩前准备一套本地离线演示方案。后端、MySQL、Nginx全部跑在本地，地图如果依赖外网就提前把关键页面截图存手机相册，万一地图加载不出来，翻相册也能把功能讲完。

另外，给后端做一个统一的初始化数据脚本（SQL文件里插好测试用户、测试帖子、测试钓点），方便换电脑时快速恢复演示状态。因为答辩用的电脑大概率跟你开发用的不是同一台，环境迁移是家常便饭。JDK版本不一致、MySQL版本不一致、Redis没启动，这些琐碎问题都能让你在答辩前一夜崩溃。

7.3 源码买回来怎么鉴别质量

现在网上卖毕设源码的太多了，到底好不好得一锤子买卖。我给几个快速鉴别方法：第一看是否有README文档，正规的会写明运行环境版本、数据库初始化脚本、启动步骤。第二看application.yml里的配置是否完整，数据源、端口、文件上传路径、日志配置等该有的都有才算能跑。第三看实体类和表结构是否对得上，很多打包货是改了个标题就把别人的代码换了层皮，表跟业务根本对不上。第四看是否有测试数据，发帖、评论、钓点这些核心表里有几条像样的数据，演示效果天差地别。

你最好是能直接跑起来，再花一个小时走一遍核心链路：注册→登录→发帖→评论→创建组队→报名→上传图片。这条链路通了，这个源码的质量基本就有保障了。如果没有源码，按我这篇文章的思路自己写，同样可以。

说到底，这个Spring Boot钓鱼爱好者交流平台APP的毕设题目，技术不深、业务清晰、展示效果好，是一个很好的选择。它让你在三个月内把Java后端的主流技术栈串了一遍，还顺带接触了移动端开发、数据库设计和接口对接。这些技能在找工作时都是实打实的敲门砖。别把毕设当成一个交差的任务，把它当作你学习生涯里第一个真正意义上完整的软件项目——做完它，你已经比那些只会改别人代码的同学值得一个更高的分数了。