老年社区资源共享平台毕业设计：Spring Boot核心实现与踩坑全解析

做老年社区资源共享平台的毕业设计，拿到这个题目的时候，很多人的第一反应是"这不就是个简单的CRUD吗"。说实话，一开始我也这么想，但是真正动手做下去才发现，这个题目里藏着不少值得琢磨的东西。

先说清楚这个项目是干什么的：它面向老年人群体，解决的是社区里"闲置物品不知道怎么处理、求助信息没地方发布、社区活动报名靠喊"这些问题。平台把线下的社区资源分享搬到了线上，老年人或者他们的子女可以把家里闲置的物品发布出来，需要的人可以申请，社区管理员负责审核把关，形成一个最基础的资源共享闭环。

对于正在选毕业设计题目的同学来说，这个题目的性价比很高。技术上覆盖了Spring Boot最核心的几块内容（权限认证、数据持久化、文件上传、前后端交互），业务上又不像电商系统那么复杂，完全可以在三个月内独立完成。而且老年社区这个场景天然带有社会价值，答辩的时候能讲的东西很多。

下面我会从设计思路、技术选型、核心功能实现、踩坑记录这四个维度，把这个项目的完整脉络整理出来，代码部分给出来可以直接参考的版本，希望能帮到正在做类似选题的朋友。

1. 项目整体设计与需求拆解

1.1 这个平台到底需要解决什么问题

做任何系统之前，先把业务场景想清楚。老年社区资源共享平台不是简单的"二手交易平台"，它的使用群体决定了它和普通交易类项目有本质区别。

老年人使用互联网产品有几个特点：操作路径要短、界面字号要大、流程不能有太多分支、错误提示要友好。更关键的一点是，大部分老年人不会自主注册账号，通常是在子女或社区工作人员的帮助下使用。所以这个系统的用户体系必须设计得足够简单，最好支持手机号+验证码登录，管理和审核职责交给社区管理员。

从业务链路来看，核心场景有三个：

• 闲置资源发布：老人家里有闲置的轮椅、拐杖、旧书、小家电，拍个照写个描述就能发布到平台。
• 资源申请与获取：其他用户看到资源后发起申请，发布者审核通过后线下交接。
• 社区管理兜底：管理员需要对发布的资源进行审核，防止出现违规内容，也要能处理用户之间的纠纷。

围绕这三条主线，系统的功能模块就很清晰了：用户模块、资源模块、申请模块、评论模块、通知模块、管理后台。

1.2 角色权限怎么划分最合理

我见过不少同学在这个项目上把权限设计得特别复杂，搞出五六种角色，每种角色还要配一套权限表，结果把自己绕进去了。实际上，这种规模的系统，三种角色完全够用：

权限控制的实现，用Spring Boot + Sa-Token或者Spring Security都可以。如果是毕业设计，我更推荐Sa-Token，理由在后面技术选型部分细说。这里先提一个设计上的建议：不要在页面上给普通用户展示任何管理入口，权限控制要做两层，前端的按钮渲染是一层，后端接口的鉴权是另一层，后端这层才是真正的安全边界。

1.3 数据库表结构设计思路

表结构设计是这个项目中最能体现"设计感"的部分。核心表应该有这八张左右：

• 用户表（user）：主键、手机号、密码、昵称、头像、年龄、楼栋信息、角色标识、状态
• 资源分类表（resource_category）：分类名称、排序号
• 资源表（resource）：标题、描述、图片URL列表、分类ID、发布用户ID、状态（待审核/已上架/已下架/已领取）、领取方式、发布时间
• 申请记录表（resource_apply）：资源ID、申请人ID、申请说明、状态（待确认/已同意/已拒绝/已取消）、申请时间
• 评论表（comment）：资源ID、评论人ID、内容、父评论ID、回复目标ID、评论时间
• 公告表（notice）：标题、内容、发布人ID、创建时间、置顶标识
• 通知消息表（message）：接收人ID、内容、关联业务ID、已读标识、创建时间
• 管理员操作日志表（operation_log）：操作人ID、操作类型、操作详情、操作时间

这里有一个特别容易踩的坑：资源的状态字段不能用简单的"0/1"来标记。我见过有人只设计了"上架/下架"两个状态，结果申请流程根本跑不通。资源的生命周期至少是四个状态：待审核、已上架、已领取、已下架。申请记录的状态也不能省，因为要把"申请-同意-线下交接-完成"这条链路的数据都留痕，答辩的时候老师问起来才有东西讲。

2. 技术选型：为什么用这一套组合

2.1 Spring Boot版本怎么定

关于Spring Boot版本，这几乎是每个做毕业设计的人都会纠结的问题。我的建议非常明确：不要追求最新，选自己最熟悉、资料最多的版本，能用2.7就别硬上3.x。

原因有三个。第一，3.x版本要求JDK 17+，很多学校的实验环境还是JDK 8，版本不匹配直接编译不过。第二，3.x升级了Jakarta命名空间，很多老教程里的javax代码全部要改，网上搜到的解决方案有一半是失效的。第三，毕业设计的核心是完成度，不是技术新颖度，用2.7.x版本完全不会影响答辩评分。

具体到组件版本，我当时用的是这一套：

• Spring Boot 2.7.18（这是2.x的最终版本，bug修复最充分）
• JDK 8（兼容性最好，打包部署都不挑环境）
• MySQL 8.0（上到5.7也完全没问题，SQL注意别用太新的特性）
• MyBatis-Plus 3.5.x（CRUD不用写SQL，分页查询一行搞定）
• Sa-Token 1.34.0（权限认证，比Spring Security简单太多）
• Redis（用于验证码缓存、token会话管理）
• Vue 2 + Element UI（前端，选Vue2的原因是资料多，遇到问题搜得到答案）

有个小细节想提醒一下：尽量用MyBatis-Plus而不是原生MyBatis。这个项目有大量的单表CRUD、分页查询、逻辑删除，MyBatis-Plus的BaseMapper自带的方法能省掉你一半的XML代码，而且它生成的SQL日志对排查问题很有帮助。既然是毕业设计，重点放在业务逻辑上就好了，别在ORM框架层面折磨自己。

2.2 前后端分离还是服务端渲染

这个选择我也纠结过。最初想用Thymeleaf做服务端渲染，觉得省事，不用配前端环境。但后来发现，这个项目里前端交互并不少：图片上传预览、分页加载、弹窗表单、状态切换，用Thymeleaf硬写会非常痛苦，页面代码又会变得很长，几乎没办法维护。

后来决定改成前后端分离，前端用Vue2 + Element UI，后端只提供JSON接口。这么做的同时给自己增加了一部分工作量：需要额外写接口文档，需要处理跨域，需要分别部署前端和后端。但反过来，答辩的时候可以讲的东西多太多了，还可以把"前后端分离架构设计"作为一个亮点来讲。

接口命名规范建议用REST风格：/api/user/login、/api/resource/list、/api/resource/apply。统一返回结构体是必须的，我用的结构是这样的：

java复制public class Result<T> {
    private Integer code;
    private String message;
    private T data;
    
    public static <T> Result<T> success(T data) {
        Result<T> result = new Result<>();
        result.code = 200;
        result.message = "操作成功";
        result.data = data;
        return result;
    }
    
    public static <T> Result<T> error(String message) {
        Result<T> result = new Result<>();
        result.code = 500;
        result.message = message;
        return result;
    }
}

前端所有请求都走axios封装，统一拦截code，code不是200就弹出message提示。这个设计虽然基础，但是能保证前后端联调的时候不会出现"后端报错了前端完全不知道"的情况。

2.3 目录结构如何组织才清晰

因为这是一个偏传统的业务系统，不建议用DDD那种「领域驱动设计」的分包方式来做，会显得特别堆砌、大材小用，而且不少人会把它做得很不地道。最稳妥的方案是经典的三层架构加controller/service/mapper：

code复制com.elderly.community
├── config            # 配置类（跨域、Sa-Token、MyBatis-Plus分页插件）
├── controller        # 接口层，只做参数接收和结果封装
│   ├── admin         # 管理端接口
│   └── app           # 用户端接口
├── service           # 业务逻辑层，核心计算和事务都在这层
│   └── impl
├── mapper            # 数据访问层，MyBatis-Plus的Mapper接口
├── entity            # 数据库实体类
├── dto               # 接口出入参对象
├── vo                # 视图对象（组合多个表的数据返回给前端）
├── common            # 通用工具类、异常处理、常量定义
└── utils             # 工具类

特别提醒一下，实体类、DTO、VO千万不要混着用。很多人图省事，直接把数据库实体类返回给前端，这样会带来两个问题：一是实体类中密码这种敏感字段会直接暴露出去，如果前端F12抓个包就能看到很麻烦；二是有些字段结构并不是前端正好要的展示结构，就会有大量空字段被返回，浪费流量。哪怕多写几个转换方法，也远比混着用安全。

3. 核心功能实现与关键代码

3.1 登录认证与权限拦截

这个模块是整个系统的地基。我用的是Sa-Token，相比Spring Security，Sa-Token最明显的优势就是一个注解搞定权限校验，不用配置一大坨SecurityConfig。

先看登录接口的核心逻辑：

java复制@Service
public class UserServiceImpl implements UserService {
    
    @Autowired
    private UserMapper userMapper;
    
    @Override
    public LoginResponse login(String phone, String code) {
        // 1. 校验验证码（从Redis取，比对完成后立即删除）
        String cacheCode = redisTemplate.opsForValue().get("login:code:" + phone);
        if (cacheCode == null || !cacheCode.equals(code)) {
            throw new BizException("验证码错误或已过期");
        }
        redisTemplate.delete("login:code:" + phone);
        
        // 2. 查询用户，如果不存在则自动注册
        LambdaQueryWrapper<User> wrapper = new LambdaQueryWrapper<>();
        wrapper.eq(User::getPhone, phone);
        User user = userMapper.selectOne(wrapper);
        if (user == null) {
            user = new User();
            user.setPhone(phone);
            user.setNickname("用户" + phone.substring(phone.length() - 4));
            user.setRole(0); // 0普通用户，1管理员
            user.setStatus(1);
            userMapper.insert(user);
        }
        
        // 3. 禁用状态校验
        if (user.getStatus() == 0) {
            throw new BizException("账号已被禁用，请联系社区管理员");
        }
        
        // 4. 登录，Sa-Token自动生成token
        StpUtil.login(user.getId());
        LoginResponse response = new LoginResponse();
        response.setToken(StpUtil.getTokenValue());
        response.setUserInfo(user);
        return response;
    }
}

这里有一个容易忽略的点：手机号验证码登录的场景下，验证码发送接口必须做频率限制。我的做法是同一个手机号60秒内只能发送一次，然后再存一个发送次数，一天超过10次就锁住，这个逻辑用Redis的increment和expire就能轻松实现。不要觉得这是小事，接口被脚本刷了，短信费用是小事，平台被垃圾账号灌满才是大事。

接口拦截配置如下：

java复制@Configuration
public class SaTokenConfig implements WebMvcConfigurer {
    
    @Override
    public void addInterceptors(InterceptorRegistry registry) {
        registry.addInterceptor(new SaInterceptor(handle -> StpUtil.checkLogin()))
                .addPathPatterns("/**")
                .excludePathPatterns("/api/user/login", 
                                      "/api/user/sendCode",
                                      "/api/resource/list",
                                      "/api/resource/detail/**",
                                      "/api/category/list",
                                      "/api/notice/list");
    }
}

注意拦截器的拦截顺序问题。我把资源列表和详情接口放开了登录限制，因为游客也要能浏览资源，但浏览的时候前端要判断登录状态，在线下申请操作发起前引导用户先登录。这种做法在用户体验上比"一进首页就强制登录"好太多了。

3.2 资源发布与审核流程

资源发布是系统的主线业务，这条链路涉及到的表和数据操作很多，我直接把核心逻辑拆开讲。

发布资源的接口，前端传过来的参数包括：标题、描述、分类ID、图片URL列表（实际上传的字符串）、领取方式（线下自取/送货上门）。后端接收后用DTO接收：

java复制@Data
public class ResourceDTO {
    @NotBlank(message = "资源标题不能为空")
    @Size(max = 50, message = "资源标题长度不能超过50字符")
    private String title;
    
    @NotBlank(message = "资源描述不能为空")
    @Size(max = 500, message = "资源描述长度不能超过500字符")
    private String description;
    
    @NotNull(message = "分类不能为空")
    private Long categoryId;
    
    private String[] images;    // 图片URL数组
    
    @NotBlank(message = "领取方式不能为空")
    private String receiveType;
    
    private String contact;     // 联系方式
}

参数校验一定要有。我在项目里全局使用了javax.validation的注解，然后写了一个全局异常处理器把校验失败的信息统一格式返回。这个细节在答辩时特别加分，它展示了你对规范性的理解和经验。

发布之后，资源状态置为待审核（status = 0），用户在"我的发布"里能看到"审核中"的字样。管理员登录后台后，在待审核列表里看到新发布的资源，点击"通过"后资源才真正出现在前台资源列表中。

这里我给一个建议：审核接口一定要加管理员权限注解，否则任何人都可以调用审核接口。我用的是Sa-Token的注解：

java复制@SaCheckRole("admin")
@PostMapping("/admin/resource/audit")
public Result<Void> audit(@RequestBody AuditDTO dto) {
    resourceService.audit(dto.getId(), dto.getPass(), dto.getReason());
    return Result.success(null);
}

因为我配置了Sa-Token的角色校验，普通用户没有"admin"角色，调用这个接口会直接被拦截。这就是前面说的"后端鉴权是安全边界"的意义，前端页面不显示审核按钮是一回事，接口层面直接拦死是另一回事。

3.3 申请记录与状态流转

申请流程是最能体现业务逻辑复杂度的部分。用户在资源详情页点击"申请领取"，填入申请说明，系统生成一条申请记录，然后发布者可以在"收到的申请"列表里看到申请，选择同意或拒绝。

这张表要扛住的状态流转是这样的：

code复制发起申请（待确认） → 发布者同意（待领取）
                → 发布者拒绝（已拒绝） → 流程结束
                → 申请人取消（已取消） → 流程结束

待领取 → 发布者确认已领取（已完成） → 流程结束

这个状态流转适合用一个专门的Service方法处理，防止状态乱跳。我这里给一个关键代码，是申请状态校验的逻辑，防止二次操作：

java复制public void updateApplyStatus(Long applyId, Long operatorId, Integer targetStatus) {
    ResourceApply apply = applyMapper.selectById(applyId);
    if (apply == null) {
        throw new BizException("申请记录不存在");
    }
    
    // 状态机校验：只有特定状态能流转到目标状态
    Integer current = apply.getStatus();
    boolean valid = (current == 0 && targetStatus == 1)   // 待确认 -> 已同意
                 || (current == 0 && targetStatus == 2)   // 待确认 -> 已拒绝
                 || (current == 1 && targetStatus == 3)   // 已同意 -> 已完成
                 || (current == 0 && targetStatus == 4);  // 待确认 -> 已取消
    if (!valid) {
        throw new BizException("当前状态不允许此操作");
    }
    
    apply.setStatus(targetStatus);
    applyMapper.updateById(apply);
    
    // 状态变更后发送通知消息给关联用户
    sendMessage(apply, targetStatus);
}

这个"当前状态不允许此操作"的提示在答辩时简直是个王炸，很多同学的代码里没有状态机校验，用户狂点按钮就会把数据改乱。我在开发后期花了一整天把所有状态流转捋了一遍，做成这样的状态机校验方式，效果是线上数据再也没乱过。

还有个小功能细节：当某条资源的申请"被同意"后，这条资源应该自动变成"已领取"状态，其他用户看到这条资源时就只能浏览，不能继续申请。这个逻辑我放在同意申请的方法里，第一步更新申请状态，第二步更新资源状态，并且用@Transactional保证两步要么都成功要么都失败。

java复制@Transactional(rollbackFor = Exception.class)
public void agreeApply(Long applyId) {
    ResourceApply apply = applyMapper.selectById(applyId);
    if (apply == null) {
        throw new BizException("申请记录不存在");
    }
    if (apply.getStatus() != 0) {
        throw new BizException("该申请已被处理");
    }
    
    // 1. 更新申请状态为已同意
    apply.setStatus(1);
    applyMapper.updateById(apply);
    
    // 2. 更新资源状态为已领取，其他申请自动失效
    Resource resource = resourceMapper.selectById(apply.getResourceId());
    resource.setStatus(2); // 已领取
    resourceMapper.updateById(resource);
    
    // 3. 给发布者发站内信
    
    // 4. 通知申请人
    
}

3.4 文件上传与图片处理

资源发布需要上传图片，这一步也是很多同学爱卡住的地方。我这里的做法是：文件先传到本地服务器的一个目录，通过nginx做静态映射访问。

配置很简单，在application.yml里加：

yaml复制file:
  upload-path: /data/uploads/

spring:
  web:
    resources:
      static-locations: file:${file.upload-path}

上传接口：

java复制@PostMapping("/api/upload")
public Result<String> upload(@RequestParam("file") MultipartFile file) {
    if (file.isEmpty()) {
        throw new BizException("文件不能为空");
    }
    
    // 校验文件类型
    String originalFilename = file.getOriginalFilename();
    String ext = originalFilename.substring(originalFilename.lastIndexOf("."));
    if (!Arrays.asList(".jpg", ".jpeg", ".png", ".gif").contains(ext.toLowerCase())) {
        throw new BizException("仅支持jpg/jpeg/png/gif格式图片");
    }
    
    // 校验文件大小，限制5MB
    if (file.getSize() > 5 * 1024 * 1024) {
        throw new BizException("图片大小不能超过5MB");
    }
    
    // 生成唯一文件名，防止重名覆盖
    String fileName = UUID.randomUUID().toString().replace("-", "") + ext;
    File dest = new File(UPLOAD_PATH + fileName);
    
    try {
        file.transferTo(dest);
        return Result.success("/uploads/" + fileName);
    } catch (IOException e) {
        throw new BizException("文件上传失败，请重试");
    }
}

关于文件上传有两个容易踩的坑：第一个是删除文件时，不要只删数据库里的记录而不删磁盘上的文件，时间长了磁盘会堆满，要单独写一个清理历史图片的定时任务，每周扫描一次没有引用的文件删掉；第二个是前端上传时用Element UI的el-upload组件，action属性指到上传接口，但必须带上登录后的token，否则上传接口因为鉴权会返回401。

3.5 后台数据统计与展示

后台管理页面上，除了基础的数据列表管理，最好加一个简单的首页统计看板。统计维度不需要太复杂，就四个数字加一个趋势图：

• 今日新增用户数
• 今日新增资源数
• 总资源数
• 待审核资源数
• 最近一周每日资源发布趋势

对应后端一个统计聚合接口：

java复制@GetMapping("/admin/stats/overview")
public Result<OverviewVO> overview() {
    OverviewVO vo = new OverviewVO();
    vo.setTodayUserCount(userMapper.selectCount(new LambdaQueryWrapper<User>()
            .apply("DATE(create_time) = CURDATE()")));
    vo.setTodayResourceCount(resourceMapper.selectCount(new LambdaQueryWrapper<Resource>()
            .apply("DATE(create_time) = CURDATE()")));
    vo.setTotalResourceCount(resourceMapper.selectCount(null));
    vo.setAuditPendingCount(resourceMapper.selectCount(new LambdaQueryWrapper<Resource>()
            .eq(Resource::getStatus, 0)));
    return Result.success(vo);
}

数据库查询用count(*)来做，数据量小没问题，千万别在代码里把所有记录查出来再list.size()这样数，那样会出性能问题，也不是一个规范的工程师该有的习惯。趋势图的话，前端用ECharts的折线图展示，后端返回一个按日分组的数量列表即可。

4. 常见问题与排查记录

4.1 项目启动报错与依赖兼容问题

这个是做这个项目最容易遇到的一类问题，也是必须会解决的"基本功"。我把当初踩过的坑和解决思路整理出来。

第一个问题：Spring Boot 3.x + JDK 8直接启动失败。这是典型的版本不匹配问题，错误信息会提示UnsupportedClassVersionError或类似内容。解决方案就是降级到Spring Boot 2.7.x版本，前提是JDK也用8。这里特别提醒一下IntelliJ IDEA项目设置里要确认Project SDK和Project language level都设置为8。

第二个问题：mybatis-plus和mybatis-spring的版本兼容性。如果你用了MyBatis-Plus 3.5.x，千万不要再手动引入mybatis-spring包，因为MyBatis-Plus自带，手动引入会发生jar包冲突，启动报BeanCreationException。排查方法很简单，打开项目依赖树（IDEA的Maven面板里点Show Dependencies），看到重复的依赖就排除掉。

第三个问题：端口被占用。Spring Boot默认8080端口，本地开着其他服务很容易冲突。启动日志里会看到Web server failed to start. Port 8080 was already in use，此时要么改配置，要么kill掉占用进程。我习惯在application.yml里直接写一个server.port=8081来做开发环境，避免和本机其他服务冲突。

第四个问题：配置文件格式錯誤导致数据库连不上。很多时候是yml文件里缩进不对。要注意spring.datasource.url这类配置的缩进是必须非常严格的，yml对空格数量有要求，不是简单对齐就行。建议先用Spring Initializr生成的项目模板来改，这样格式基本不会错。

我把这些常见问题整理成了一个速查表，方便对照排查：

4.2 数据库层面的常见坑

这个项目的大多数问题都集中在数据库设计和使用上。我这么说是因为自己栽过跟头，也帮别人排查过不少。

第一个巨坑就是字段类型设计不合理。例如资源描述字段用varchar(255)存，实际能写的内容远不止255字，超过长度直接插入失败，前端报错还不知道为什么。这种字段一开始就应该是TEXT类型。另外，如果存图片URL列表，不要用单独一张表来存图片，直接用一个TEXT字段存JSON字符串数组就行，对这种小项目来说可以大幅精简表和查询逻辑。

第二个坑：时间字段的精度问题。用户注册时间和资源发布时间插入后，如果发现时间戳全都是"00:00:00"这种，说明数据库字段是DATE类型而不是DATETIME类型。在MySQL里，日期和时间一定要用DATETIME，否则前端展示的时间会误导数据统计。

第三个坑：逻辑删除与唯一索引的冲突。用MyBatis-Plus的逻辑删除功能后，如果手机号字段有唯一索引，用户注册时删除过的记录再注册会撞索引。MyBatis-Plus逻辑删除会生成UPDATE语句，但唯一索引依然存在。解决思路一般是：要么不用唯一索引，业务代码里先查后插；要么在不允许逻辑删除的表上不做唯一索引。我当时在用户表上就遇到了这个问题，后来把逻辑删除的字段拼进唯一索引里才解决的。

第四个坑：数据库连接池耗尽。开发时本地没问题，一部署到服务器，压力稍微大一点就报"Too many connections"。这个问题在配置里加上连接池参数就能解决，在yml中配置：

yaml复制spring:
  datasource:
    hikari:
      max-pool-size: 20
      min-idle: 5
      connection-timeout: 30000

配合合理的连接池参数和数据库max_connections设置，这个问题基本不会出现。如果是测试时遇到，先看下后台有多少Sleep连接，确认是不是代码里的连接没有释放。

4.3 部署上线时容易忽略的细节

好多同学做完了毕设，兴致勃勃地想部署到云服务器上演示，结果遇到各种奇怪问题。我总结一下最容易被忽略的几件事。

首先是前端打包的问题。Vue项目执行npm run build后生成的dist目录，里面是静态资源。访问的时候如果接口请求报404，大概率是前端调用接口的baseURL写的是localhost:8080，这是写死在代码里的。部署到服务器上要改成服务器的IP和端口，或者通过nginx的proxy_pass反向代理，将/api/路径转发到后端端口。

其次是后端打包。Spring Boot项目用mvn clean package打成jar包，在服务器上java -jar就能跑。要注意的地方是打包时不要带dev环境的配置，或者在配置里区分多环境，用spring.profiles.active来指定。我一直建议同学们做三个配置：application.yml（公共配置）、application-dev.yml（本地开发）、application-prod.yml（服务器生产），部署时用--spring.profiles.active=prod指定。

第三是一直被忽略的：时区问题。服务器默认可能是UTC时区，数据库也是UTC时区的连接，前端展示时间会差8个小时。解决方案是在JDBC连接URL上加上serverTimezone=Asia/Shanghai，然后在服务器上设置时区，timedatectl set-timezone Asia/Shanghai，这能让定时任务和日志时间都准确。

最后，上传目录的权限。后端上传接口在服务器上没有write权限，会报Permission denied。我吃过这个亏，后来在部署文档里专门写明了要给上传目录设置权限，chmod 755 /data/uploads。这类问题报错信息其实很明确，但第一次遇到时完全想不到是权限问题。

4.4 答辩前需要重点准备的功能点

既然这个项目是毕业设计，那答辩环节也是不可忽视的一部分。我建议在答辩前，至少把这几个功能点做到"张嘴就能讲清楚细节"的程度。

第一，登录验证码的实现链路。从用户点击发送验证码，到Redis存储，到校验删除，到60秒倒计时，每一步都要能在白板上画出来。这个功能小小的，但是能体现出你对Web开发基础流程的理解，老师很爱问。

第二，事务的使用场景。资源发布、申请同意、公告发布这三个场景都有多个数据变动，@Transactional的rollbackFor为什么要设置成Exception.class，默认情况下RuntimeException会回滚但Exception不一定回滚，这点要说得出来。

第三，状态机设计。申请记录从待确认到已完成有几种流转路径，为什么要限制用户只能顺序操作，不能乱跳状态。这块我前面的状态机校验代码就是现成的答案。

第四，权限控制的实现细节。角色标识存在哪，拦截器怎么判断有没有登录，@SaCheckRole和@SaCheckLogin这两个注解背后做了什么。这个讲清楚，你的项目在老师眼里就不会被认为是纯粹的CRUD了。

从我自己写这个项目的经验来看，老年社区资源共享平台的难点不在技术，而在于你是否把业务流程的每个细节想清楚了。技术栈都是Spring Boot最常规的东西，图的是稳定和资料多，把时间花在业务流程设计、状态流转控制、部署排错这些真正决定项目完成度的事情上，才是这个毕业设计能拿到高分的正确路径。

最后再分享一个小技巧：后台管理里可以加一个简单的导出功能，把申请记录或资源列表导出成Excel，用EasyExcel几十行代码就能搞定。答辩演示的时候，现场导出一份数据表格，比在界面上翻半天列表的效果好太多了。这个小功能的加分效果，远超你的想象。