“摄影作品分享与交流社区平台”这个题目几乎是我见过的计算机毕业设计里最典型的SpringBoot实战项目之一。它不光是简单的CRUD而是把用户、摄影师、作品、预约这几条核心业务线都串在了一起技术栈覆盖从前端交互到后端权限、从文件上传到分页检索非常适合用来检验一个学生是否真正理解了一门后端框架的核心能力。我最近刚把这套系统完整落地从需求建模到数据库设计从接口开发到部署上线踩了一遍坑。这篇文章就把整个设计思路、核心模块实现、关键细节和排错过程都摊开来讲给准备拿这个题目做毕设或者想练手SpringBoot的同学一条可以直接参考的路径。1. 整体设计与技术选型思路拆解1.1 需求拆解这个系统到底要解决什么先别急着写代码把需求看清楚比什么都重要。摄影交流系统听起来很宽泛但拆开来看核心链路由四个角色和四类操作构成四类核心角色分别是“游客”“注册用户”“摄影师”“管理员”。游客可以浏览作品、搜索标签注册用户在前者基础上可以点赞、评论、收藏摄影师则额外拥有发布作品、管理个人主页、处理预约请求的能力管理员负责内容审核、用户管理和数据统计。关键业务链路有三条。第一条是作品从上传、审核到展示的曝光链路涉及文件存储、内容过滤、列表分页第二条是用户从浏览、收藏到评论的互动链路涉及关联查询、点赞去重、消息通知第三条是用户浏览摄影师主页后发起预约排期的交易链路涉及预约状态自动流转。所以在设计阶段我就确定了核心原则这个平台不是单纯的图片展示站而是一个带社交属性和交易属性的双边平台。数据库建模时就不能只做单表CRUD至少要有用户表、角色表、作品表、作品图片表、评论表、点赞表、收藏表、预约表、摄影师信息表这九张核心表。1.2 技术选型为什么是SpringBoot这套生态关于技术选型我的建议很直接SpringBoot加MyBatis-Plus加MySQL加Redis加JWT这套组合是当前Java后端新手项目里的主流配置既有足够的技术亮点又不会因为过度设计把自己绕晕。SpringBoot本身解决了Spring配置地狱的问题内嵌Tomcat让部署变得极其简单打成一个jar包直接跑毕业后写进简历里也算“独立完成服务端开发与部署”的完整经历。MyBatis-Plus在单表操作上提供了非常舒服的封装内置的分页插件让列表接口的开发效率直线提升这点后面会展开细说。Redis在项目里承担两个职责一是缓存热门作品列表和摄影师排行降低数据库压力二是存储验证码和JWT黑名单实现登录状态控制。如果商用项目要考虑分布式Session但毕设场景用JWT方式更简洁状态无状态化前端拿到token放请求头后端拦截器解析即可。这里有个容易纠结的点用不用Spring Cloud我的答案是别用。摄影交流系统的业务量远没到需要微服务拆分的程度强行引入服务注册、网关、配置中心只会增加部署和调试成本。单体应用加缓存、加索引优化就是完全合理的架构。我见过不少同学为了“展示技术广度”硬上微服务结果答辩时被老师问服务间调用失败怎么办、数据一致性怎么保证反而答不上来得不偿失。1.3 数据库模型设计的几个关键细节数据库设计是整个项目的地基表关系理不清楚后面写接口全是坑。我反复调整过三轮最终确定下来的核心设计如下用户表设计时特别注意了角色区分我没有用单独的role表去关联而是在sys_user表里直接加了role字段用1表示普通用户、2表示摄影师、0表示管理员。因为系统角色固定且互相排斥摄影师也是用户可以浏览评论直接用字段存角色比中间关联表省一层查询。摄影师额外的作品集介绍、擅长风格、地区信息单独放photographer_profile表这样用户表和摄影师信息表解耦普通用户查询时不需要带着无用的摄影档案字段。作品表是最核心的表设计要点在状态字段。photo_works表里必须有status状态位0待审核、1已发布、2已下架、3审核不通过。不能省掉审核流程哪怕管理员审核逻辑写得再简单这个环节的存在能说明你考虑到了内容安全答辩时这就是一个可讲的安全设计点。作品图片我单独拆了一张表没有把图片URL直接存字符串字段里原因是必须支持一个作品多图展示同时封面图需要单独标记。photo_works_images表存作品ID、图片URL、排序号、是否封面四个字段联查时按sort_order排序这样每张图的职责清晰后续做瀑布流也方便。2. 核心功能模块拆解与实操要点2.1 用户认证与权限控制JWT拦截器到底拦什么登录认证用的是JWT加拦截器方案没有引入Spring Security因为Spring Security的学习成本对毕设来说偏高配置SecurityConfig、UserDetailsService、过滤器连等一大串调试周期长。JWT自签名加拦截器已经足够保证接口安全。具体实现分三步。用户登录成功后用userId、用户名、角色生成Token设置7天过期时间返回给前端。自定义一个AuthInterceptor拦截器在preHandle里从请求头取出Authorization字段解析Token解析成功就把userId放入request的attribute里供Controller取用。注册WebMvcConfigurer把拦截器注册到需要登录的接口路径上。这里值得讨论的是拦截匹配规则。项目里把接口按 /api/auth/、/api/works/、/api/user/、/api/photographer/、/api/admin/ 分段管理。全部接口都允许OPTIONS请求通过重要跨域时前端会先发预检请求拦截器放行OPTIONS是必须的否则前端在这卡半天。公开接口只有作品浏览列表、作品详情、摄影师主页接口剩下的点赞、评论、收藏、预约接口全部要登录态。权限控制的粒度上我额外做了两级校验。第一级是登录拦截第二级是角色校验用自定义注解加拦截器实现在需要摄影师权限的接口上标注RequireRole(photographer)拦截器解析到该注解后从请求上下文取当前用户角色与要求比对不匹配直接返回403。为什么不用代码里复制粘贴if判断因为接口一多每个Controller都写一遍角色判断非常容易漏用注解加拦截器的方式集中处理新增接口时加一行注解就行也不容易误放权限。2.2 摄影师作品展示与分页检索作品列表页是用户第一眼看到的内容交互上我借鉴了瀑布流布局后端不关心前端怎么排版只需要提供统一的分页数据源。接口设计为GET /api/works/page接收pageNum、pageSize、sortType、tagId、keyword五个参数。sortType支持latest最新发布、popular按点赞数排序、featured管理员推荐。这里我用了一个不算复杂但很实用的优化策略热门排序不能每次都去计算点赞数而是给photo_works表冗余一个like_count字段点赞接口操作时同时更新这张表的计数。用MyBatis-Plus实现分页第一步是在配置里注入PaginationInnerInterceptor配置数据库类型为mysql。这个步骤漏掉的话分页方法执行时表面上看很平静实际查出来的是全表数据——这是用MyBatis-Plus分页最经典的坑后面排查章节我会专门讲。分页查询的具体写法我的方案是展示列表场景用LambdaQueryWrapper条件构造器LambdaQueryWrapperPhotoWorks wrapper Wrappers.lambdaQuery(); wrapper.eq(PhotoWorks::getStatus, 1); // 只展示已审核通过的作品 if (StringUtils.isNotBlank(keyword)) { wrapper.like(PhotoWorks::getTitle, keyword); } if (tagId ! null) { wrapper.apply(EXISTS (SELECT 1 FROM photo_works_tag_ref ref WHERE ref.work_id photo_works.id AND ref.tag_id {0}), tagId); } if (popular.equals(sortType)) { wrapper.orderByDesc(PhotoWorks::getLikeCount); } else { wrapper.orderByDesc(PhotoWorks::getCreateTime); } PagePhotoWorks page worksMapper.selectPage(new Page(pageNum, pageSize), wrapper);标签过滤用EXISTS子查询而不用IN子查询是因为EXISTS在大数据量下通常性能更好且能避免IN子查询返回过多数据这也是一个面试官常问的优化点。2.3 作品上传与内容安全处理文件上传是整个系统里最容易让新手崩溃的模块技术点密集坑也最多。我最终定了这个方案后端接口接收MultipartFile数组存储到服务器本地磁盘图片URL记录相对路径通过Nginx映射到静态资源目录对外访问。上传参数有两个特别值得注意的配置项。spring.servlet.multipart.max-file-size设为10MBmax-request-size设为50MB这两个不设置的话默认只有1MB传稍微大点的摄影作品原图直接报MaxUploadSizeExceededException。存储路径按“业务类型/日期/随机文件名”组织即uploads/works/20250612/uuid.jpg避免把所有图片塞在一个目录里目录文件太多会影响IO速度。文件名处理上必须重新生成坚决不能使用用户上传的原始文件名。原始文件名可能包含中文、空格、特殊字符直接存路径里轻则URL编码问题重则路径穿越漏洞这是安全问题不能含糊。我用UUID加原始文件扩展名重新拼文件名扩展名白名单校验只接受jpg、jpeg、png、gif、webp五种格式。内容安全处理是我重点强调的模块。除了图片后缀校验还要用Java自带的ImageIO对上传图片进行重新读取并校验判断文件格式与扩展名是否一致防止有人把伪造图片扩展名上传。同时对于作品标题、简介、评论内容我之前踩过XSS注入的坑特地在系统里做了全局XSS过滤器对所有非富文本请求参数做转义。做法是自定义一个XssFilter包装HttpServletRequest重写getParameter和getParameterValues方法对输入内容里的脚本标签、javascript伪协议、onclick这类事件属性做HTML转义处理。public class XssFilter implements Filter { Override public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, ServletException { HttpServletRequest req (HttpServletRequest) request; chain.doFilter(new XssHttpServletRequestWrapper(req), response); } }XssHttpServletRequestWrapper里重写方法做转义转义核心逻辑就是用regex匹配script、javascript:、on\w\s*等危险模式并替换成安全字符。这里有一个很关键的取舍全局过滤器不能把作品的正文描述和评论内容这类富文本也一律转义掉否则用户写的换行、加粗格式全没了。我的方案是参数级别加白名单内容类字段在包装类里跳过统一转义调整为只过滤危险标签保留B、I、P这类基础格式标签。2.4 预约互动系统设计与状态流转预约模块是这个平台区别于普通相册网站的核心功能也是很多评审老师眼里“有实际应用价值”的功能点。用户浏览摄影师主页后提交预约请求时需要提供这些信息期望拍摄类型婚纱、亲子、个人写真等、期望拍摄日期、期望城市、联系电话、补充说明。后端生成预约单号初始状态是待摄影师确认。数据库设计上预约表我设置了几个关键字段id、user_id、photographer_id、shoot_type、expect_date、city、contact_phone、remark、status、create_timestatus用整数存1待确认、2已接受、3已拒绝、4已完成、5已取消。为什么不用字符串因为整数存状态位在查询统计时更方便这点在答辩时可以提。预约状态流转有几个必须校验的规则用户只能取消状态为待确认的预约摄影师只能操作待确认的预约已完成状态的预约不能再变更。这些逻辑写成一个独立的方法集中控制不能在接到前端请求的Controller里散布否则漏掉某个判断就出越权了。还有个体验细节用户预约成功或者摄影师确认预约之后系统要向关联方发送站内通知通知表结构包含recipient_id、content、is_read。我实现时直接在预约状态变更服务里调用了notifyService推送消息没有做成消息队列。虽然消息队列是更好的解耦方案但毕设场景引入RabbitMQ会增加部署复杂度站内通知的实时性要求也不高用同步调用完全可以接受。3. 实操过程与核心环节实现记录3.1 初始化SpringBoot项目JDK版本与配置踩坑项目初始化这一步百分之八十的新手会卡在JDK版本问题上。我复盘一下自己的实操过程尽量帮你避开最常见的雷。我用的是SpringBoot 2.7.18加JDK 8的组合。为什么不用SpringBoot 3因为SpringBoot 3最低要求JDK 17而很多学校的毕设环境和课程教学还是基于JDK 8如果用了SpringBoot 3本机如果只装了JDK 8IDEA里创建项目就会直接报错。具体表现为IDEA新建Spring Initializr项目时选择SpringBoot 3.x版本Server URL选择的start.spring.io默认生成工程需要JDK 17以上如果本机是JDK 8项目创建后pom文件引入依赖Maven一刷新就报类库版本不兼容。自己如果直接用IDEA创建Spring Boot 2.7.18要注意在Project Structure把Project SDK选到8Module的Language Level也选8。否则会出现编译时给你报“java: 警告: 源发行版 17 需要目标发行版 17”实际就是Java Compiler里把Java Compiler的Target bytecode version错误地设置成了17但本机没有安装JDK 17。如果你是跟着在线教程初始化项目pom.xml里确认这几个关键依赖别漏了dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-web/artifactId /dependency dependency groupIdcom.baomidou/groupId artifactIdmybatis-plus-boot-starter/artifactId version3.5.3.1/version /dependency dependency groupIdmysql/groupId artifactIdmysql-connector-java/artifactId version8.0.33/version /dependency dependency groupIdcom.auth0/groupId artifactIdjava-jwt/artifactId version4.4.0/version /dependency dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-data-redis/artifactId /dependencyLombok也建议加上虽然有些老师不喜欢但项目里的实体类GetterSetter代码量确实太大了Lombok能减少大量样板代码主流的Java项目里使用率非常高。3.2 配置文件的坑与统一返回体application.yml里最容易被忽视的配置有三个。第一个是Jackson的日期格式。默认情况下LocalDateTime类型返回给前端的是一个数组结构或很长的时间戳字符串前端解析非常痛苦。必须配置spring: jackson: date-format: yyyy-MM-dd HH:mm:ss time-zone: GMT8第二个是MyBatis-Plus的逻辑删除配置。我设计表时加了deleted字段软删除的好处是数据不会真正消失管理员可以恢复同时保留完整的操作审计记录。逻辑删除配置好后select默认自动过滤已删除记录。mybatis-plus: global-config: db-config: logic-delete-field: deleted logic-delete-value: 1 logic-not-delete-value: 0这是MyBatis-Plus 3.x的标准写法要注意logic-delete-field字段名称必须和实体类成员变量名一致之前有同学图省事只加了这个配置却省略了实体类注解结果全局过滤器并没有正确识别出逻辑删除字段所有接口都查到了已删除数据。第三个是文件上传路径配置。不要用绝对路径因为部署环境变了就会挂。我把上传根目录配置成项目运行目录下的uploads文件夹app: upload-dir: ./uploads/实际存储时再拼接工作目录的绝对路径。这样IDEA里跑和服务器上jar包跑都能找到正确的目录。统一返回体是我强烈建议在项目第一天就做的事。所有Controller直接返回Result对象Result里包含code、message、data三个字段。成功时code为200、message为success业务异常时返回500或者401、403这种状态码。好处非常明显前端处理接口逻辑不需要每次单独判断返回结构前端联调效率大幅提升异常处理也集中在全局异常处理器里统一包一层。Data public class ResultT { private Integer code; private String message; private T data; public static T ResultT ok(T data) { ResultT r new Result(); r.setCode(200); r.setMessage(success); r.setData(data); return r; } }全局异常处理器用RestControllerAdvice注解实现捕获业务异常直接返回Result格式的JSON这个设计在答辩时可以解释成“全局异常与统一响应规范”。3.3 分页插件配置与列表接口实战分页插件配置完全是被忽略就翻车的典型。需要在Configuration类里注入两个BeanConfiguration MapperScan(com.example.photography.mapper) public class MybatisPlusConfig { Bean public MybatisPlusInterceptor mybatisPlusInterceptor() { MybatisPlusInterceptor interceptor new MybatisPlusInterceptor(); interceptor.addInnerInterceptor(new PaginationInnerInterceptor(DbType.MYSQL)); return interceptor; } }为什么要这一步因为MyBatis-Plus的分页功能不是内置默认开启的而是依赖拦截器插件来实现SQL拼接没配置这个Bean调用selectPage方法时并不会真的执行limit语句而是静默地查询全表再把内存对象截断。数据库几万条数据时还好数据量一大就会内存溢出而且接口响应会特别慢。配置完成之后列表接口核心代码并不复杂。加上自定义VO对象把作品表数据和图片列表组合起来返回给前端。为什么要用VO因为photo_works表和photo_works_images表是一对多关系直接把两张表的数据查出来返回前端要么处理嵌套结构要么发多次请求。我在Service层通过查询作品列表后批量查图片关联手动封装成WorkVO对象里面包含作品基本信息、封面图URL、图片数量、点赞数、作者昵称、作者头像。特别注意不要用for循环里查数据库否则N1问题立刻出现。我这里的处理方式是收集所有作品ID后用一次IN查询查出全部图片再用Map按workId分组复杂度是O(nm)性能上完全没有问题。3.4 文件上传与静态资源映射实现上传接口的实现我按照“三步验证”的思路来组织代码。第一步验证参数文件列表非空、单个文件不超过大小限制、扩展名命中白名单。第二步执行存储通过UUID生成新文件名保存到oss的works子目录如果当天日期目录不存在就在FileUtil里自动创建。第三步返回结果保存成功后把存储的相对路径封装成URL返回给前端。静态资源访问我这里接了一层Nginx。dev环境调试用SpringBoot直接映射Configuration public class WebConfig implements WebMvcConfigurer { Override public void addResourceHandlers(ResourceHandlerRegistry registry) { String uploadPath System.getProperty(user.dir) File.separator uploads File.separator; registry.addResourceHandler(/uploads/**) .addResourceLocations(file: uploadPath); } }这行配置非常关键不加的话即使文件成功落盘前端访问http://localhost:8080/uploads/xxx.jpg也只能得到404。如果你的项目里配置了拦截器一定要记得在拦截器注册的排除路径里加上/uploads/**否则静态资源请求也会被认证拦截器拦下来我见过好几个同学在这个位置卡了一两个小时。上线部署时把上传目录交给Nginx的location /uploads/配置去处理加上alias指向服务器上的实际目录配合client_max_body_size配置整个文件服务链路才算完整。摄影作品都是高分辨率大图Nginx的client_max_body_size如果保持默认1m前端上传稍微大一点的作品原图就会被Nginx返回413错误这个也要提前改大。4. 常见问题与排查技巧实录4.1 IDEA里创建SpringBoot项目时JDK不兼容的坑这个问题在毕设群里被反复问了无数遍我在这里单独梳理一遍排查思路。第一步看报错信息。如果提示“源发行版 17 需要目标发行版 17”或“Cannot determine embedded database driver class for database type NONE”第一反应不是去改依赖而是先确认项目用的是哪个JDK。打开IDEA的File - Project Structure - Project看Project SDK是否选择了8Language Level是否是8。Module设置里也要检查尤其是初次导入Maven项目时IDEA有时会自动帮你选成JDK 17的默认值导致编译不通过。第二步检查Maven的编译配置。pom.xml里加上这段代码基本就能把编译版本锁死properties java.version1.8/java.version maven.compiler.source1.8/maven.compiler.source maven.compiler.target1.8/maven.compiler.target /properties第三步检查系统环境变量。JAVA_HOME是否指向JDK 8PATH里是否存在两个Java路径。Windows下如果装了新版本JDK后忘记改JAVA_HOME控制台里java -version明明显示17而IDEA里却正常这种错位是最让人懵的。我之前还遇到过一个很无语的情况IDEA右下角提示“Project isnt configured yet”Maven刷新一直报错最后发现是settings.xml里配置的镜像源无法访问导致的。所以排查顺序应该是先看Maven依赖是否能正常解析再看JDK版本最后才考虑代码问题。4.2 分页查询不生效接口一直返回全量数据这是MyBatis-Plus分页最经典的问题我总结几种可能原因。第一种MybatisPlusInterceptor没有注入。前面说的PaginationInnerInterceptor Bean没配置只要用了MyBatis-Plus框架第一件事就要确认这个配置类存在。判断方法很简单查看SQL日志如果执行的SQL里没有LIMIT关键字说明分页插件根本没生效。第二种自定义SQL分页不生效。如果你在Mapper里写了自定义的联表查询使用了IPage参数而没有在Mapper接口方法里把它作为第一个参数分页也会失效。注意MyBatis-Plus规定分页拦截器要生效IPage必须作为Mapper方法的第一个参数并且SQL不要自己写limit。第三种分页总数查询不准。如果使用了多表联查分组查询MyBatis-Plus自动生成的count SQL可能会出错。解决方案是手动提供count方法用Select写一个专门查总数的语句。第四种前端传参问题。pageNum传0甚至负数MyBatis-Plus默认强制第一页为1但如果你传的是字符串格式Spring参数绑定的类型转换可能报400。习惯上前后端约定pageNum从1开始pageSize上限设为20或者50超过就按上限截断避免有人一口气请求一万条数据把服务拖挂。4.3 图片上传成功但前端加载404这种问题排查路径非常固定从上到下按顺序验证。首先看控制台请求的URL是什么然后在浏览器直接访问这个URL。如果返回404检查Spring的静态资源配置里addResourceHandler和addResourceLocations是否匹配。一个常见细节是file:后面必须跟磁盘绝对路径如果你写了相对路径file:uploads/IDEA里正常运行是因为工作目录是项目根目录部署后工作目录变成jar包同级目录路径自然就失效了。其次确认数据库存的路径和实际落盘路径是否一致。我调试的时候喜欢在存储后打印log包括文件名称、相对路径、绝对路径、URL拼接结果四个字段打出来一眼就能看出问题。第三种可能是拼接URL的时候少了一层/uploads前缀。比如代码里存储路径是uploads/works/1.jpg实际映射URL应该拼成http://localhost:8080/uploads/works/1.jpg如果没有加这个前缀请求的是http://localhost:8080/works/1.jpg自然404。4.4 全局XSS过滤器误杀富文本内容的调整我在做XSS过滤的时候踩了一个比较深远的坑写出来供大家避雷。最初我的过滤器设计是统一对请求里的所有参数做HTML转义逻辑很简单地把替换成lt;替换成gt;。测试登录、评论接口一切正常但到了作品详情内容展示时摄影师的个人介绍和作品描述文本里的换行符、加粗标签全变成了乱码整个页面排版彻底崩溃。后面我在脏数据里排查发现是过滤器的转义逻辑“一刀切”对原本就是用户正常输入内容的字符串也做了全文转义。正确的做法应该是区分参数类型来针对性处理对标题、简介这类短文本字段做严格的HTML标签过滤去掉所有非白名单标签对正文和长描述这类富文本字段只过滤危险标签比如script、iframe、object、embed保留基础的排版标签和纯文本。我最终的实现方案是在过滤器里维护一个字段白名单列表判断当前参数名是否属于内容类字段如果是就走“软过滤”只替换危险模式其他字段一律走“硬过滤”跳过HTML标签。这样既保证了XSS防护能力又不破坏正常内容展示。另外还有一个关于上传PDF和XSS的细节。项目里如果涉及PDF预览这类功能要注意上传文件时同样要通过内容校验不能只靠扩展名白名单PDF文件里可以嵌入JavaScriptXSS的风险比图片更高。对于摄影系统来说我建议别开放PDF上传只允许图片上传安全边界更清晰答辩时老师问到也能给出合理的取舍理由。4.5 Redis缓存与数据库一致性问题我这个项目给热门作品列表加了Redis缓存缓存key设计为works:hot:page:1缓存时间30分钟。这里有一个非常容易被问到的技术问题点赞数更新后Redis里的热门列表数据可能已经过期怎么保证一致性我的做法是采用“主动失效加延迟刷新的策略”。点赞接口更新数据库的同时删除对应热门列表的缓存key下次请求再查库并重新构建缓存。为什么不更新缓存而直接删除因为更新缓存需要考虑排序位置的变动成本高且容易出错删除缓存让下次请求重建实现简单、效果可靠。如果觉得直接删缓存太粗暴还可以用“双删缓存”的补偿方案。具体流程是先删除缓存再更新数据库等待几百毫秒后再次删除缓存。主要是为了应对并发场景下第一次删除后、数据库更新完成前有其他请求把旧数据又写回缓存的情况。毕设业务量不大单删缓存就够用但如果有老师追问能说出来双删策略会加不少印象分。再来个冷门小细节Redis存储热门列表时会用JSON序列化如果列表元素是LocalDateTime类型默认的Jackson序列化可能会报错或者格式不对需要在RedisConfig里自定义RedisTemplate的序列化器或者把LocalDateTime字段避免放在缓存对象里用长整型时间戳代替这个也算我在实际开发中踩过的一个小坑。5. 部署上线与项目答辩的几个经验之谈先说说部署环境搭建的经验。为了省事我租了一台最基础的云服务器系统选Linux装好JDK 8、MySQL 8、Redis和Nginx按上面的流程修改配置后上传jar包跑起来。项目结构里需要提前写好初始化SQL最好包含建库语句、建表语句和基础测试数据这样换环境部署时一条命令就能初始化数据库。应用进程用nohup启动日志通过nohup.out输出并配合--spring.profiles.activeprod参数切换生产配置数据库连接串、Redis连接串放在application-prod.yml里避免把密码提交到代码仓库。数据库迁移时注意字符集设置数据库和表都使用utf8mb4不然用户上传的作品描述里如果有表情符号存库会报错或变问号。连接串参数也需要加上useUnicodetruecharacterEncodingutf8serverTimezoneAsia/Shanghai。接口写完一定要去写一份接口说明文档。不用写得很正式按接口路径分好类列出请求参数、响应示例、权限要求后续自己联调方便答辩时也可以打印出来当辅助材料。方案这个词在毕设答辩里几乎一定会被问到你提前把这些边界条件写清楚回答的时候才有底气。项目做完并发量很低但也建议在数据库里测试几张表建好索引。photo_works表的status和create_time建联合索引因为列表页最核心的查询条件是按照已发布状态按时间倒序photo_like表如果单独拆了表建user_id和work_id的唯一索引防止点赞重复插入。数组越界这个错误我在做评论分页时出现过一次原因是没处理评论删除后评论序号断档的情况。解决办法是查评论列表时只查状态正常的评论并在逻辑删除时对总数做减法避免前端页码出现空洞。最后再分享一个写代码的习惯所有状态字段和业务异常码都定义成枚举或常量类不要随手在Service里写魔法值。比如“1待确认、2已接受”这种状态位如果散落在代码里后期维护或者答辩时被老师问得稍微细一点你就得回去翻代码而用枚举集中定义后看常量类就能看懂全部流程。这个习惯很多老师都很看重能作为加分项。整个项目我前后花了大约三周时间从设计数据库到完成部署。由于需求理得清、技术选型没跟风核心流程走下来反而没有遇到特别大的阻碍。如果你也打算做这个题目我建议第一阶段先花两到三天把数据库表和接口边界定死不要急着写Controller业务逻辑第二阶段集中解决文件上传、登录认证、分页列表三个核心难点这三个点通过了系统的基本盘就稳了最后再花时间做交互细节和异常边界把各种不合理输入都测试一遍。这条路走通之后你会发现SpringBoot的实际开发能力已经有了质的提升毕业设计答辩也自然不用发愁。