做毕业设计选“基于SpringBoot的摄影分享网站系统”说实话是个很稳的选择。SpringBoot本身在企业级开发里已经是事实标准摄影类网站又有明确的业务场景、丰富的交互功能、清晰的角色边界用来展示技术能力和工程化素养非常合适。我自己带过的学生里选这个方向的不在少数但做得好和做得一般的差距往往不在框架本身而在于细节——权限怎么设计、上传怎么处理、检索怎么做、部署怎么落地。这篇就把“有光”摄影分享网站从立项到答辩的完整思路拆开讲清楚每个环节要做什么、为什么要这么做、坑在哪里。不管你是想直接照着做还是想理解底层逻辑方便答辩时应对提问都值得看完。1. 项目立项与整体设计思路1.1 需求定位光为主题、分享为核“有光”这个名字很好摄影本来就是捕捉光的艺术。围绕这个主题系统核心任务可以拆成两条线一条是内容线也就是摄影师上传作品、展示作品一条是互动线用户浏览、点赞、评论、收藏形成社区氛围。从毕业设计的评审角度来看这两条线恰好覆盖了大部分技术点。内容线涉及文件上传、存储、图片处理、数据管理互动线涉及用户鉴权、关系表设计、通知机制、并发控制。把这两条线完整做下来系统的业务完整性就有了不再是“看起来很浅”的CRUD。用户角色建议分三类普通用户、摄影师、管理员。不用过度设计三类的权限边界足够讲清楚RBAC的思路。普通用户可以浏览、评论、点赞、收藏摄影师可以额外上传作品、管理自己的作品集管理员负责审核内容、管理用户、处理举报。1.2 技术选型为什么是SpringBoot这套组合后端框架用SpringBoot 2.7.x别用3.x。3.x虽然已经发布很久但很多第三方库的兼容性、参考资料的匹配度都不如2.7成熟对毕业设计来说没必要冒险。SpringBoot 2.7既是主流教材覆盖的版本又能平滑适配后续要用的所有中间件。持久层建议用MyBatis-Plus不是因为它比JPA“更好”而是因为它的代码生成器、分页插件、条件构造器能极大压缩开发时间而且接口设计直观。这里有一点容易被质疑MyBatis-Plus是不是太“傻瓜化”了答辩时你可以这样答项目核心难点不在单表CRUD而在多表关联、分布式文件存储、检索排序这些场景MyBatis-Plus负责提升基础开发效率复杂SQL仍然手写二者相辅相成。存储层选用MySQL 8.0缓存用Redis文件对象存储用MinIO检索用Elasticsearch加分词器。这套组合几乎是当前中小型项目的标准配置每一项都对应明确的业务场景不会显得堆砌。1.3 模块划分与功能矩阵系统拆成六个核心模块用户中心、作品管理、社交互动、内容检索、数据看板、后台管理。每个模块再细分成小功能画成表格会更直观模块功能点技术要点用户中心注册/登录/个人信息JWT鉴权、Redis会话、头像上传作品管理上传/编辑/相册分组MinIO存储、图片压缩、EXIF读取社交互动点赞/评论/收藏/关注Redis缓存计数、异步通知内容检索关键词搜索/标签筛选/排行ElasticsearchIK分词数据看板用户画像/作品统计ECharts可视化后台管理用户审核/作品审核/举报处理权限校验、多条件分页权限控制统一基于Spring Security JWT实现。JWT无状态、适合前后端分离相比Session方案在分布式环境下更友好。这里要注意JWT的密钥要配置在application.yml里并通过环境变量覆盖不要把硬编码的密钥直接提交到Git仓库。2. 核心细节解析与关键实现2.1 数据库设计五张核心表之间的关系表设计是整个项目的地基很多学生在这里翻车后面返工非常痛苦。用户表、作品表、评论表、点赞表、收藏表、关注表是六张必需的前四张人人都会建容易出错的是点赞和收藏。点赞表和收藏表建议单独设计而不建议在作品表里加一个“like_count”字段就完事。单独设计的好处有两点一是可以记录“谁点赞过”支持用户点进自己的点赞列表查看二是通过唯一约束user_id work_id防止重复点赞。作品表里的like_count只作为冗余计数在事务里与点赞表同步更新避免每次统计都走count查询。作品表有一个字段容易忽略cover_url。列表页只需要显示封面详情页才需要加载所有图片。把封面单独存列表查询就只需要扫一行数据不用查JSON数组性能差异在数据量上来之后非常明显。2.2 文件上传MinIO与图片处理的完整链路摄影网站的核心资源是图片上传模块的设计直接影响用户体验和系统稳定性。整体流程是前端先请求后端获取预签名上传地址拿到地址后直接传给MinIO再由前端通知后端“上传完成”后端再做数据落库。这套流程很多人第一次接触会觉得绕为什么要多一步原因有两条一是文件不经过应用服务器避免了大文件传输占用应用内存和带宽二是MinIO的预签名URL可以限制有效时间和对象大小安全性更有保障。如果实在想简化也可以走应用服务器再转发但对并发上传场景不友好。图片处理建议在服务端做多尺寸裁剪。原始图片能到5MB甚至更大直接展示会拖慢首屏。业界常见做法是生成三种规格缩略图200px列表图800px原图最长边不超过2048px用于详情页。图片处理可以用Thumbnailator或Java自带的ImageIO抗几个大图就完了。如果追求工程化用ffmpeg或者ImgScalr都行。2.3 全文检索Elasticsearch与IK分词的集成搜索模块是“有光”系统里最能拉开技术档次的功能。作品标题、描述、标签都可以作为检索字段单纯用MySQL的LIKE查询不是不行但一旦数据量大起来性能和多条件组合查询的复杂度都会失控。我在项目里用的是Elasticsearch 7.x IK分词器。索引的mapping设计要注意分词器选择标题和标签用ik_max_word保证可切分成最细粒度的词描述字段可以不用索引或者用ik_smart减少索引体积。检索时用bool_query组合must、should、filter三种条件分别处理“关键词匹配”“标签命中”“类型筛选”三种需求。索引同步是另一个容易踩坑的点。方案可以选择监听MySQL的binlog也可以选择在业务代码里显式同步后者对毕设来说更可控。上传作品和编辑作品时在同一事务内完成MySQL写入和ES索引更新失败就回滚。查询时优先查ES拿不到再降级查MySQL。2.4 并发与缓存Redis在互动场景中的角色点赞这个功能看起来简单但高频并发下容易出问题。我的处理方式是记录在Redis的Hash结构里key是作品IDfield是用户IDvalue是点赞状态。用户点赞时不再直接写MySQL而是先写Redis再通过异步任务批量把Redis数据回写到MySQL。有人可能会问为什么不直接写MySQL因为热点作品的点赞频率可能达到每秒几十上百次直接落在数据库上会持续触发行锁和IO而Redis的写入性能是内存级别的。回写采用定时任务每5分钟跑一次把变更的点赞记录批量合并写入同时同步更新作品表的冗余计数。评论功能要控制最大深度。嵌套评论在视觉上很自然但查询时递归展开代价很高。经验做法是只支持两级一级评论挂在作品下二级评论挂在一级评论下查询时一次取出在内存里做树形组装。数据库里用parent_id字段表达层级再额外存一个root_id方便清理整棵评论树。2.5 安全与异常处理全局过滤器与统一异常体系XSS攻击在交互类网站是不能忽视的。评论和作品描述都允许用户输入文本如果不对