做“定制化设计服务平台”这类项目我前前后后折腾过两版第一版是标准的SSM单机版第二版换成了SpringBoot重写顺便把前端也理了一遍。这个项目在毕业设计里出现频率很高但很多人一上来就陷入“先搭框架还是先画页面”的纠结最后代码写成一锅粥。这篇文章我不打算用“XX系统设计与实现”那种论文腔来写直接把从需求拆解到部署交付的完整链路讲清楚包括为什么放弃JPA选择MyBatis、订单状态机怎么设计、文件上传会踩哪些坑以及那套“源码LW调试文档讲解”的交付物到底该怎么准备才不会被答辩老师刁难。这个平台本质上是一个连接“有设计需求的人”和“设计师”的交易撮合系统。用户发布定制化设计需求平台把需求推给合适的创意设计人员设计师提交方案用户确认后完成订单管理员在后台做审核和监管。你把它理解成一个垂直领域的“猪八戒网”简化版就行核心不在多炫而在于流程闭环和状态清晰。适合用来做毕设、课程设计或者想练手SpringBootSSM整合的人。1. 项目定位与需求拆解1.1 定制化设计服务到底在解决什么问题市面上常见的模板化设计平台走的是“标准品”路线比如你选一个Logo模板直接套用价格固定。但定制化设计服务的特点是“需求不标准”每个用户要的东西都不一样有人要做一套企业VI有人只想改个海报排版还有人需要出一整套包装设计。需求不标准意味着平台不能用简单的SKU去承载必须通过“需求单方案提交”的方式来匹配供需。所以系统的核心其实是两个需求描述的结构化和交易流程的状态管理。前者解决“用户说不太清楚自己要什么”的问题平台通过表单引导用户把设计类型、风格偏好、参考图、预算范围内置为可选的字段这样设计师在后端能够快速筛选。后者解决“需求从发布到完成每个环节谁该干什么、什么状态下能干什么”的问题这是整个系统最值钱的部分。1.2 功能模块梳理与边界划分很多新手设计功能时喜欢堆功能什么在线聊天、实时消息、积分商城都往上加。但作为毕业设计或中小型项目功能边界一定要克制。我最终划成了四个端用户端、设计师端、管理员端和公共基础模块。用户端注册登录、发布需求、查看推荐设计师、提交订单、查看方案稿、确认完成、评价。设计师端注册登录、完善个人资料与作品集、浏览可接需求单、申请接单、上传设计稿件、修改稿件、查看订单收益。管理员端用户管理、设计师认证审核、需求单审核、订单仲裁、平台数据统计。公共模块登录认证、文件上传、消息通知、支付模拟、数据字典。注意这里我没有单独做“聊天模块”而是用“留言/备注”替代。原因很简单实时聊天需要WebSocket和离线消息机制复杂度会翻倍而在答辩时它并不能体现你对业务的理解。留言板式的沟通已经能说明问题而且实现起来稳。1.3 角色权限设计权限这块我推荐直接用Spring Boot的拦截器加注解实现不要一上来就引入Shiro或Spring Security除非你真的很熟。这个项目的角色就三种ROLE_USER、ROLE_DESIGNER、ROLE_ADMIN。设计权限表时只需要一张用户表加一个role字段不需要搞RBAC五张表。拦截器里做三件事检查用户是否登录、检查接口权限是否匹配、检查资源归属权比如设计师不能查看别人的订单。资源归属权很容易被忽略但却是答辩时老师最喜欢问的点。比如用户A的订单用户B调接口能不能查到如果你不做归属校验这就是一个大漏洞。我在Mapper层每个查询都强制带上当前用户ID而不是只查订单ID这样即使有人绕过接口也拿不到别人的数据。2. 技术选型为什么是SpringBootSSM这套组合2.1 SpringBoot与SSM的关系别被名字绕晕SSM是Spring Spring MVC MyBatis的缩写在SpringBoot出现之前搭建这三个框架需要写一堆XML配置文件数据源、事务、扫描包、映射器统统手动配光配置文件就有几百行。而SpringBoot做的事情就是把这些变成了“约定优先”自动装配帮你把大部分配置处理好你只需要在application.yml里写少量自定义项。所以“SpringBootSSM”这个说法并不冲突它指的是“用SpringBoot作为底座整合Spring MVC和MyBatis”。SpringBoot内部依然跑的是Spring MVC持久层你照常可以用MyBatis。这套组合的好处是既有SpringBoot的快速开发体验又有MyBatis的灵活SQL控制特别适合数据查询条件多的业务系统。2.2 数据访问层用MyBatis还是JPA我给这个项目选的是MyBatis理由有三个。第一定制化设计平台里查询条件复杂需求单列表需要按类型、风格、预算、状态、时间等字段动态过滤这种动态SQL在MyBatis里用where和if标签写起来非常顺手用JPA虽然也能拼Specification但可读性差很多。第二MyBatis里SQL是显式写的后期调优、复用方便对答辩时展示SQL能力也有帮助。第三绝大多数高校教材和模板还在讲MyBatis你遇到问题能搜到的资料更多。当然并不是说JPA不能用。如果你对Hibernate很熟或者项目简单到只有单表增删改查JPA的开发效率确实更高。但既然标题里写了SSM老老实实用MyBatis是最稳妥的。2.3 前端方案与交互设计前后端分离是大趋势但这里要看你自己的时间。如果是单人开发时间紧我建议用服务端渲染的Thymeleaf模板引擎页面直接用BootstrapJQuery来做后端返回ModelAndView表单、列表、详情页都能在服务端拼好。这样做的好处是不要考虑跨域、Token鉴权一个Tomcat就能跑完。缺点是交互感弱刷新明显。如果选择前后端分离Vue Element UI后端只提供JSON接口项目会更像工业级应用但你需要处理跨域、路由守卫、Axios封装、Token存储等问题。我在第二版里选择了前后端分离因为这个平台需要很多异步操作——设计师上传方案、用户切换订单状态、管理员审核操作这些如果用服务端渲染页面刷新会很痛苦。前端我用的是Vue2 Element UI打包后扔到SpringBoot的resources/static下由后端托管避免Nginx部署的麻烦这也是很多毕设项目常用的方式。3. 数据库设计与核心表结构3.1 用户、设计师、订单三张主表数据库是整个平台的基础我建议以订单为核心向外辐射。不要一开始就写20张表先把主链路打通再补。用户表user字段大概包括id、username、passwordBCrypt加密、phone、email、roleTINYINT1用户 2设计师 3管理员、status正常/禁用、avatar、create_time。设计师信息没必要单独建一张设计师表来存直接在user表里扩展几个字段就行real_name、design_style、skill_tags、intro、portfolio_url。如果你把设计师单独拆表反而会引入ID关联和联表查询的麻烦。订单表design_order是这个系统的核心字段要有id、order_no业务编号、user_id下单用户、designer_id接单设计师可空表示还没人接、demand_title、demand_desc、design_type分类LOGO/VI/海报/包装/UI等、style、budget_low、budget_high、deadline、status待接单/已接单/待提交/待确认/已完成/已取消/已仲裁、create_time、update_time。方案表design_scheme用来存设计师提交的稿件字段包括id、order_id、designer_id、scheme_title、file_url、cover_url、description、version、status草稿/提交/被驳回、create_time。3.2 需求单与方案稿件如何关联一个需求单对应多个设计版本这是很自然的业务逻辑。比如设计师第一次提交的初稿被用户打回那用户可能要看修改稿我们不应该覆盖原来的记录而是新增一条方案记录并将版本号加一。方案表里的order_id关联订单表version用来标识第几版。前端展示时用户端订单详情里默认展示最新一版方案但可以通过版本列表查看历史方案这个设计在答辩时很加分因为它体现了你对“版本追溯”这个业务痛点的理解。3.3 状态机设计与字段约束状态机是订单系统最重要的部分我强烈建议在数据库层面存状态值int型而不是字符串代码里用枚举类来定义常量。常用的状态值定义为状态值含义流转方向0待接单可变为1或6取消1已接单可变为2开始提交方案2方案已提交可变为3用户确认或4用户打回可继续提交3已完成终态4已打回可再次变为25已取消终态6已仲裁终态管理员介入在设计表结构时我故意没有把状态字段改成VARCHAR直接存“待接单”这种中文因为业务上后续要统计“待接单订单数量”或者做定时任务批量关单用数字判断性能更好、也避免中文编码问题。4. 后端核心功能实现细节4.1 登录认证与权限拦截登录我用的方案是JWT BCrypt。JWTJSON Web Token在前后端分离场景下非常常用用户登录后后端生成一个包含用户ID和角色信息的token前端存储到localStorage之后每次请求在Header里带上Authorization: Bearer token。后端主要做两件事写一个JwtUtil工具类负责生成和解析token写一个AuthInterceptor拦截器负责校验token并给请求上下文塞入当前用户信息。拦截器里用preHandle方法检查请求头如果是登录接口或白名单里的路径就放行其他接口一律验证。需要注意的一点是JWT的密钥不要硬编码在类里放到配置文件application.yml中防止源码泄露后token被伪造。这里有一个关键点解析token时除了验证签名还要验证用户是否存在、是否被禁用。不能只根据token里的数据就信任用户因为用户可能在有效期被管理员封禁。所以拦截器里每次解析token后还需要去查一次数据库确认用户状态虽然多了一次查询但保证了安全性。4.2 需求发布与设计师抢单/指派流程用户发布需求前端提交的表单内容很多我分了三个数据载体需求主信息标题、描述、类型、风格预算、参考图列表多图、补充留言。参考图我使用文件上传接口先传到本地拿到文件url列表后和订单主信息一并提交这样做的原因是文件上传耗时如果和表单一起提交容易因网络原因造成整个请求超时。需求提交后订单状态为待接单0。设计师端通过一个列表接口查询状态为0的需求单列表接口支持按分类和预算过滤。这里的SQL是动态拼接select idfindAvailableOrders resultTypecom.example.entity.DesignOrder SELECT * FROM design_order where status 0 if testdesignType ! null and designType ! AND design_type #{designType} /if if testbudgetMin ! null AND budget_high gt; #{budgetMin} /if if testbudgetMax ! null AND budget_low lt; #{budgetMax} /if /where ORDER BY create_time DESC /select设计师点击“接单”时后端要做一个乐观锁操作防止多人同时抢单导致把同一个订单派给两个人。做法是在订单表上加一个version字段更新时用SQL条件WHERE id #{id} AND status 0 AND version #{oldVersion}更新成功才表示抢到。4.3 方案上传、预览与版本管理设计师提交方案时上传的是一张封面图和一个PDF或者压缩包。文件上传我用的是本机路径存储在配置文件中指定file: upload-dir: D:/upload/ access-path: /upload/**注意两个坑第一SpringBoot默认单文件最大1MB多文件最大10MB这个必须调大第二存储路径最好不要包含空格和中文不然后续静态资源映射的时候容易出妖蛾子。上传接口返回文件的相对URL比如/upload/20240912/xxxx.pdf用年月日建子目录是常规操作方便后期按时间归档。数据库里只存相对路径不存磁盘绝对路径这样换服务器不用改数据库。设计方案的版本管理在代码里就是插入一条新记录同时把旧记录的status置为历史版本。用户端想看历史版本时按order_id查所有方案再按version倒序。4.4 订单支付与状态流转真实支付涉及商户号、密匙、回调地址对毕设来说又麻烦又没必要。我采用的是模拟支付用户提交订单后订单状态不变但生成一条支付记录order_payment然后弹窗提示“模拟支付成功”直接把状态流转到待接单。如果后续你想扩展可以把支付实现抽象成PaymentService接口接支付宝沙箱的时候再写一个AliPayServiceImpl替换核心逻辑不用动。状态流转的代码建议集中管理不要散落在Controller里。我写了一个OrderStateMachine组件内部放一个Map或Switch来定义每个状态允许执行的动作。比如动作USER_CONFIRM只允许在状态2执行你传入其他状态就会抛异常。这样避免用户通过接口越权跳转状态。5. 关键难点与踩坑记录5.1 MyBatis动态SQL拼接动态SQL是MyBatis的精髓但新手容易在if标签里留下SQL注入漏洞。一个常见错误是if testkeyword ! null AND title LIKE CONCAT(%, #{keyword}, %) /if注意必须用#{}而不是${}${}会直接把字符串拼进SQL导致注入。如果你实在要用${}比如动态排序列名那只能通过白名单校验别直接接前端传参。另外不得不提的是MyBatis的where标签和set标签能自动处理多余的AND和逗号这个一定要用。我自己第一版写SQL时还手动拼字符串结果每个查询条件都要判断是不是第一条代码臭得不行。后来全部换成了动态SQL标签简洁很多。5.2 文件上传大小限制与路径安全SpringBoot在application.yml里的配置是spring: servlet: multipart: max-file-size: 50MB max-request-size: 100MB这里的单位是MB不要写错成MB大写也没关系关键是配了之后如果还报MaxUploadSizeExceededException检查一下是不是用了旧版multipartResolver。另外文件上传接口要校验文件后缀和ContentType不能只信任前端传的扩展名否则很容易被恶意上传脚本文件。我这边写了一个白名单工具只允许jpg png gif pdf zip rar这几种。放到OSS里时也要留意OSS的访问权限配置但我这里用的是本地路径映射注意把access-path对应的目录权限设置好就行。5.3 定时任务清理过期订单如果用户发布需求后一直没有设计师接单那么这个订单会一直停留在“待接单”状态平台体验会变差。我用SpringBoot自带的Scheduled注解写了一个定时任务每10分钟扫描一次把超过24小时且状态还是0的订单自动取消。Component public class OrderTimeoutTask { Autowired private DesignOrderMapper designOrderMapper; Scheduled(cron 0 */10 * * * ?) public void autoCancelExpiredOrders() { designOrderMapper.autoCancelExpired(LocalDateTime.now().minusHours(24)); } }注意几点Scheduled默认是单线程串行执行的如果你的定时任务很多要加EnableScheduling注解并考虑线程池另外测试时如果时间不够可以把24小时改成1分钟实测确保链路通。5.4 前后端联调的常见问题前后端分离后最容易出现的就是跨域和请求头丢失。跨域我在后端写了一个CorsConfig用WebMvcConfigurer配置允许的源、方法和请求头。但更常见的问题是前端用Axios拦截器设置了Header而后端的拦截器没有放行OPTIONS预检请求导致浏览器报“CORS policy”。解决方式是拦截器里把OPTIONS请求直接放行。这个小问题卡了我一下午Cloud你千万别忽略。还有一个联调时的经典问题用户在iframe里上传文件或者用FormData提交时不会带Authorization头导致上传鉴权失败。解决办法是上传接口单独做白名单或者前端在上传请求里手动拼接token。我最终把文件上传接口无条件放行但文件上传的请求里带一个upload_token做轻量校验这样既安全又方便。6. 部署交付与文档编写心得6.1 本地开发环境配置开发环境建议用IDEA Maven MySQL8.0 JDK1.8额如果你装了JDK17需要改SpringBoot版本2.7.6以上才兼容。Java8的时代虽然老了但稳定性极好大部分学校机器也是这个版本。数据库初始化脚本我是用Flyway管理的每次改动都记录版本。不过对于一个小项目来说直接提供一个init.sql全量脚本更省事保证新来的同学导入后能跑起来。我交付时把init.sql放在项目根目录的db/文件夹下并在文档里写清楚创建数据库名、账号、密码。6.2 项目打包与部署后端打包命令很简单mvn clean package -DskipTests会在target/下生成一个xxx.jar然后命令行运行java -jar xxx.jar --spring.profiles.activeprod生产环境的配置写在application-prod.yml里数据库地址改成云主机、文件路径改成Linux路径。前端如果是Vue项目执行npm run build后把dist/目录下的文件复制到SpringBoot的static/目录中再重新打包这样整个系统就只有一个Jar包了。6.3 LW、调试文档与讲解怎么准备标题里带“源码LW调试文档讲解”这种交付物这个“LW”通常指论文/毕业论文但不管它叫什么核心就是让人能快速理解项目。调试文档我写的是“复现步骤手册”从导入数据库到启动项目再到测试每个页面的操作路径每一步都配上截图。写这种文档有个技巧多截图标红少写抽象描述。例如“点右上角登录按钮输入admin/admin123登录”比“后台系统登录后进入首页”清楚一百倍。论文/docs里不要大段贴代码更不要复制一整张数据表字段。老师想看到的是你的设计思路、流程分析和关键技术难点的解决方案。我会把系统架构图非Mermaid用Visio/UML画、订单时序图、ER图放进去这部分是拿分项。讲解视频/稿子我建议录一个10分钟左右的屏幕录制先讲背景与需求再演示功能最后讲一个你最有心得的技术点比如状态机或动态SQL这样整个项目就立住了。7. 复盘与扩展建议7.1 这套系统还能怎么升级技术上的扩展方向很明确把本地文件存储替换为云存储实现消息实时推送和站内聊天引入Spring Security OAuth2实现第三方登录再加上Elasticsearch做需求全文检索。但我更看重的是业务上的升级这个平台可以加一个“方案版权锁定”功能——设计师提交的方案在用户确认前带水印确认后才给高清原图。这个点在答辩时一提出来老师会觉得你有商业敏感度。实现上也不复杂前端展示时覆盖一层半透明水印原图下载链接改为订单状态为“已完成”时才返回。另外一个实际可做的就是数据分析统计比如按照设计类型统计平台订单量、热门风格排行、设计师成单率。管理员端通过ECharts展示这些图表会让系统显得更加完整和有亮点。7.2 给新手的几点实在建议第一功能宁少勿多但业务状态必须有闭环。你宁愿不做聊天功能也要把“需求发布-接单-打回-完成”这条主链路走得稳稳的。第二数据库先设计好再写代码。我见过太多人先写实体类再改表结构最后Mapper里全是NosuchField异常。建议直接手绘ER图把字段、关联键都定下来再进IDEA。第三权限校验别偷懒。哪怕只有三个角色每个接口都要带着横切权限判断。尤其是订单相关接口设计一个公共方法校验操作人与订单归属关系不要相信前端传什么你就信什么。第四答辩前一定要准备一个“为什么不用XX技术”的答案。比如为什么不用JPA为什么不用Redis缓存为什么不用分布式架构。不是非要使用这些技术而是你要能证明自己知道它们并做了取舍这个比硬堆技术更能让老师认可。最后分享一个我自己调试时踩过的坑SpringBoot的静态资源默认会处理/static/**下的内容但你自定义的WebMvcConfigurer里如果用registry.addResourceHandler(/upload/**)添加了资源映射文件路径在Linux服务器上大小写敏感如果配置的目录名和实际目录名对不上会一直报404调试很久才发现是大小写问题。这种基础问题让我养成了一个习惯所有自定义配置里的路径统一小写写完注释标注含义。希望后来的人少走点弯路。
SpringBoot+SSM构建定制化设计服务平台：订单状态机与文件上传踩坑实战
做“定制化设计服务平台”这类项目我前前后后折腾过两版第一版是标准的SSM单机版第二版换成了SpringBoot重写顺便把前端也理了一遍。这个项目在毕业设计里出现频率很高但很多人一上来就陷入“先搭框架还是先画页面”的纠结最后代码写成一锅粥。这篇文章我不打算用“XX系统设计与实现”那种论文腔来写直接把从需求拆解到部署交付的完整链路讲清楚包括为什么放弃JPA选择MyBatis、订单状态机怎么设计、文件上传会踩哪些坑以及那套“源码LW调试文档讲解”的交付物到底该怎么准备才不会被答辩老师刁难。这个平台本质上是一个连接“有设计需求的人”和“设计师”的交易撮合系统。用户发布定制化设计需求平台把需求推给合适的创意设计人员设计师提交方案用户确认后完成订单管理员在后台做审核和监管。你把它理解成一个垂直领域的“猪八戒网”简化版就行核心不在多炫而在于流程闭环和状态清晰。适合用来做毕设、课程设计或者想练手SpringBootSSM整合的人。1. 项目定位与需求拆解1.1 定制化设计服务到底在解决什么问题市面上常见的模板化设计平台走的是“标准品”路线比如你选一个Logo模板直接套用价格固定。但定制化设计服务的特点是“需求不标准”每个用户要的东西都不一样有人要做一套企业VI有人只想改个海报排版还有人需要出一整套包装设计。需求不标准意味着平台不能用简单的SKU去承载必须通过“需求单方案提交”的方式来匹配供需。所以系统的核心其实是两个需求描述的结构化和交易流程的状态管理。前者解决“用户说不太清楚自己要什么”的问题平台通过表单引导用户把设计类型、风格偏好、参考图、预算范围内置为可选的字段这样设计师在后端能够快速筛选。后者解决“需求从发布到完成每个环节谁该干什么、什么状态下能干什么”的问题这是整个系统最值钱的部分。1.2 功能模块梳理与边界划分很多新手设计功能时喜欢堆功能什么在线聊天、实时消息、积分商城都往上加。但作为毕业设计或中小型项目功能边界一定要克制。我最终划成了四个端用户端、设计师端、管理员端和公共基础模块。用户端注册登录、发布需求、查看推荐设计师、提交订单、查看方案稿、确认完成、评价。设计师端注册登录、完善个人资料与作品集、浏览可接需求单、申请接单、上传设计稿件、修改稿件、查看订单收益。管理员端用户管理、设计师认证审核、需求单审核、订单仲裁、平台数据统计。公共模块登录认证、文件上传、消息通知、支付模拟、数据字典。注意这里我没有单独做“聊天模块”而是用“留言/备注”替代。原因很简单实时聊天需要WebSocket和离线消息机制复杂度会翻倍而在答辩时它并不能体现你对业务的理解。留言板式的沟通已经能说明问题而且实现起来稳。1.3 角色权限设计权限这块我推荐直接用Spring Boot的拦截器加注解实现不要一上来就引入Shiro或Spring Security除非你真的很熟。这个项目的角色就三种ROLE_USER、ROLE_DESIGNER、ROLE_ADMIN。设计权限表时只需要一张用户表加一个role字段不需要搞RBAC五张表。拦截器里做三件事检查用户是否登录、检查接口权限是否匹配、检查资源归属权比如设计师不能查看别人的订单。资源归属权很容易被忽略但却是答辩时老师最喜欢问的点。比如用户A的订单用户B调接口能不能查到如果你不做归属校验这就是一个大漏洞。我在Mapper层每个查询都强制带上当前用户ID而不是只查订单ID这样即使有人绕过接口也拿不到别人的数据。2. 技术选型为什么是SpringBootSSM这套组合2.1 SpringBoot与SSM的关系别被名字绕晕SSM是Spring Spring MVC MyBatis的缩写在SpringBoot出现之前搭建这三个框架需要写一堆XML配置文件数据源、事务、扫描包、映射器统统手动配光配置文件就有几百行。而SpringBoot做的事情就是把这些变成了“约定优先”自动装配帮你把大部分配置处理好你只需要在application.yml里写少量自定义项。所以“SpringBootSSM”这个说法并不冲突它指的是“用SpringBoot作为底座整合Spring MVC和MyBatis”。SpringBoot内部依然跑的是Spring MVC持久层你照常可以用MyBatis。这套组合的好处是既有SpringBoot的快速开发体验又有MyBatis的灵活SQL控制特别适合数据查询条件多的业务系统。2.2 数据访问层用MyBatis还是JPA我给这个项目选的是MyBatis理由有三个。第一定制化设计平台里查询条件复杂需求单列表需要按类型、风格、预算、状态、时间等字段动态过滤这种动态SQL在MyBatis里用where和if标签写起来非常顺手用JPA虽然也能拼Specification但可读性差很多。第二MyBatis里SQL是显式写的后期调优、复用方便对答辩时展示SQL能力也有帮助。第三绝大多数高校教材和模板还在讲MyBatis你遇到问题能搜到的资料更多。当然并不是说JPA不能用。如果你对Hibernate很熟或者项目简单到只有单表增删改查JPA的开发效率确实更高。但既然标题里写了SSM老老实实用MyBatis是最稳妥的。2.3 前端方案与交互设计前后端分离是大趋势但这里要看你自己的时间。如果是单人开发时间紧我建议用服务端渲染的Thymeleaf模板引擎页面直接用BootstrapJQuery来做后端返回ModelAndView表单、列表、详情页都能在服务端拼好。这样做的好处是不要考虑跨域、Token鉴权一个Tomcat就能跑完。缺点是交互感弱刷新明显。如果选择前后端分离Vue Element UI后端只提供JSON接口项目会更像工业级应用但你需要处理跨域、路由守卫、Axios封装、Token存储等问题。我在第二版里选择了前后端分离因为这个平台需要很多异步操作——设计师上传方案、用户切换订单状态、管理员审核操作这些如果用服务端渲染页面刷新会很痛苦。前端我用的是Vue2 Element UI打包后扔到SpringBoot的resources/static下由后端托管避免Nginx部署的麻烦这也是很多毕设项目常用的方式。3. 数据库设计与核心表结构3.1 用户、设计师、订单三张主表数据库是整个平台的基础我建议以订单为核心向外辐射。不要一开始就写20张表先把主链路打通再补。用户表user字段大概包括id、username、passwordBCrypt加密、phone、email、roleTINYINT1用户 2设计师 3管理员、status正常/禁用、avatar、create_time。设计师信息没必要单独建一张设计师表来存直接在user表里扩展几个字段就行real_name、design_style、skill_tags、intro、portfolio_url。如果你把设计师单独拆表反而会引入ID关联和联表查询的麻烦。订单表design_order是这个系统的核心字段要有id、order_no业务编号、user_id下单用户、designer_id接单设计师可空表示还没人接、demand_title、demand_desc、design_type分类LOGO/VI/海报/包装/UI等、style、budget_low、budget_high、deadline、status待接单/已接单/待提交/待确认/已完成/已取消/已仲裁、create_time、update_time。方案表design_scheme用来存设计师提交的稿件字段包括id、order_id、designer_id、scheme_title、file_url、cover_url、description、version、status草稿/提交/被驳回、create_time。3.2 需求单与方案稿件如何关联一个需求单对应多个设计版本这是很自然的业务逻辑。比如设计师第一次提交的初稿被用户打回那用户可能要看修改稿我们不应该覆盖原来的记录而是新增一条方案记录并将版本号加一。方案表里的order_id关联订单表version用来标识第几版。前端展示时用户端订单详情里默认展示最新一版方案但可以通过版本列表查看历史方案这个设计在答辩时很加分因为它体现了你对“版本追溯”这个业务痛点的理解。3.3 状态机设计与字段约束状态机是订单系统最重要的部分我强烈建议在数据库层面存状态值int型而不是字符串代码里用枚举类来定义常量。常用的状态值定义为状态值含义流转方向0待接单可变为1或6取消1已接单可变为2开始提交方案2方案已提交可变为3用户确认或4用户打回可继续提交3已完成终态4已打回可再次变为25已取消终态6已仲裁终态管理员介入在设计表结构时我故意没有把状态字段改成VARCHAR直接存“待接单”这种中文因为业务上后续要统计“待接单订单数量”或者做定时任务批量关单用数字判断性能更好、也避免中文编码问题。4. 后端核心功能实现细节4.1 登录认证与权限拦截登录我用的方案是JWT BCrypt。JWTJSON Web Token在前后端分离场景下非常常用用户登录后后端生成一个包含用户ID和角色信息的token前端存储到localStorage之后每次请求在Header里带上Authorization: Bearer token。后端主要做两件事写一个JwtUtil工具类负责生成和解析token写一个AuthInterceptor拦截器负责校验token并给请求上下文塞入当前用户信息。拦截器里用preHandle方法检查请求头如果是登录接口或白名单里的路径就放行其他接口一律验证。需要注意的一点是JWT的密钥不要硬编码在类里放到配置文件application.yml中防止源码泄露后token被伪造。这里有一个关键点解析token时除了验证签名还要验证用户是否存在、是否被禁用。不能只根据token里的数据就信任用户因为用户可能在有效期被管理员封禁。所以拦截器里每次解析token后还需要去查一次数据库确认用户状态虽然多了一次查询但保证了安全性。4.2 需求发布与设计师抢单/指派流程用户发布需求前端提交的表单内容很多我分了三个数据载体需求主信息标题、描述、类型、风格预算、参考图列表多图、补充留言。参考图我使用文件上传接口先传到本地拿到文件url列表后和订单主信息一并提交这样做的原因是文件上传耗时如果和表单一起提交容易因网络原因造成整个请求超时。需求提交后订单状态为待接单0。设计师端通过一个列表接口查询状态为0的需求单列表接口支持按分类和预算过滤。这里的SQL是动态拼接select idfindAvailableOrders resultTypecom.example.entity.DesignOrder SELECT * FROM design_order where status 0 if testdesignType ! null and designType ! AND design_type #{designType} /if if testbudgetMin ! null AND budget_high gt; #{budgetMin} /if if testbudgetMax ! null AND budget_low lt; #{budgetMax} /if /where ORDER BY create_time DESC /select设计师点击“接单”时后端要做一个乐观锁操作防止多人同时抢单导致把同一个订单派给两个人。做法是在订单表上加一个version字段更新时用SQL条件WHERE id #{id} AND status 0 AND version #{oldVersion}更新成功才表示抢到。4.3 方案上传、预览与版本管理设计师提交方案时上传的是一张封面图和一个PDF或者压缩包。文件上传我用的是本机路径存储在配置文件中指定file: upload-dir: D:/upload/ access-path: /upload/**注意两个坑第一SpringBoot默认单文件最大1MB多文件最大10MB这个必须调大第二存储路径最好不要包含空格和中文不然后续静态资源映射的时候容易出妖蛾子。上传接口返回文件的相对URL比如/upload/20240912/xxxx.pdf用年月日建子目录是常规操作方便后期按时间归档。数据库里只存相对路径不存磁盘绝对路径这样换服务器不用改数据库。设计方案的版本管理在代码里就是插入一条新记录同时把旧记录的status置为历史版本。用户端想看历史版本时按order_id查所有方案再按version倒序。4.4 订单支付与状态流转真实支付涉及商户号、密匙、回调地址对毕设来说又麻烦又没必要。我采用的是模拟支付用户提交订单后订单状态不变但生成一条支付记录order_payment然后弹窗提示“模拟支付成功”直接把状态流转到待接单。如果后续你想扩展可以把支付实现抽象成PaymentService接口接支付宝沙箱的时候再写一个AliPayServiceImpl替换核心逻辑不用动。状态流转的代码建议集中管理不要散落在Controller里。我写了一个OrderStateMachine组件内部放一个Map或Switch来定义每个状态允许执行的动作。比如动作USER_CONFIRM只允许在状态2执行你传入其他状态就会抛异常。这样避免用户通过接口越权跳转状态。5. 关键难点与踩坑记录5.1 MyBatis动态SQL拼接动态SQL是MyBatis的精髓但新手容易在if标签里留下SQL注入漏洞。一个常见错误是if testkeyword ! null AND title LIKE CONCAT(%, #{keyword}, %) /if注意必须用#{}而不是${}${}会直接把字符串拼进SQL导致注入。如果你实在要用${}比如动态排序列名那只能通过白名单校验别直接接前端传参。另外不得不提的是MyBatis的where标签和set标签能自动处理多余的AND和逗号这个一定要用。我自己第一版写SQL时还手动拼字符串结果每个查询条件都要判断是不是第一条代码臭得不行。后来全部换成了动态SQL标签简洁很多。5.2 文件上传大小限制与路径安全SpringBoot在application.yml里的配置是spring: servlet: multipart: max-file-size: 50MB max-request-size: 100MB这里的单位是MB不要写错成MB大写也没关系关键是配了之后如果还报MaxUploadSizeExceededException检查一下是不是用了旧版multipartResolver。另外文件上传接口要校验文件后缀和ContentType不能只信任前端传的扩展名否则很容易被恶意上传脚本文件。我这边写了一个白名单工具只允许jpg png gif pdf zip rar这几种。放到OSS里时也要留意OSS的访问权限配置但我这里用的是本地路径映射注意把access-path对应的目录权限设置好就行。5.3 定时任务清理过期订单如果用户发布需求后一直没有设计师接单那么这个订单会一直停留在“待接单”状态平台体验会变差。我用SpringBoot自带的Scheduled注解写了一个定时任务每10分钟扫描一次把超过24小时且状态还是0的订单自动取消。Component public class OrderTimeoutTask { Autowired private DesignOrderMapper designOrderMapper; Scheduled(cron 0 */10 * * * ?) public void autoCancelExpiredOrders() { designOrderMapper.autoCancelExpired(LocalDateTime.now().minusHours(24)); } }注意几点Scheduled默认是单线程串行执行的如果你的定时任务很多要加EnableScheduling注解并考虑线程池另外测试时如果时间不够可以把24小时改成1分钟实测确保链路通。5.4 前后端联调的常见问题前后端分离后最容易出现的就是跨域和请求头丢失。跨域我在后端写了一个CorsConfig用WebMvcConfigurer配置允许的源、方法和请求头。但更常见的问题是前端用Axios拦截器设置了Header而后端的拦截器没有放行OPTIONS预检请求导致浏览器报“CORS policy”。解决方式是拦截器里把OPTIONS请求直接放行。这个小问题卡了我一下午Cloud你千万别忽略。还有一个联调时的经典问题用户在iframe里上传文件或者用FormData提交时不会带Authorization头导致上传鉴权失败。解决办法是上传接口单独做白名单或者前端在上传请求里手动拼接token。我最终把文件上传接口无条件放行但文件上传的请求里带一个upload_token做轻量校验这样既安全又方便。6. 部署交付与文档编写心得6.1 本地开发环境配置开发环境建议用IDEA Maven MySQL8.0 JDK1.8额如果你装了JDK17需要改SpringBoot版本2.7.6以上才兼容。Java8的时代虽然老了但稳定性极好大部分学校机器也是这个版本。数据库初始化脚本我是用Flyway管理的每次改动都记录版本。不过对于一个小项目来说直接提供一个init.sql全量脚本更省事保证新来的同学导入后能跑起来。我交付时把init.sql放在项目根目录的db/文件夹下并在文档里写清楚创建数据库名、账号、密码。6.2 项目打包与部署后端打包命令很简单mvn clean package -DskipTests会在target/下生成一个xxx.jar然后命令行运行java -jar xxx.jar --spring.profiles.activeprod生产环境的配置写在application-prod.yml里数据库地址改成云主机、文件路径改成Linux路径。前端如果是Vue项目执行npm run build后把dist/目录下的文件复制到SpringBoot的static/目录中再重新打包这样整个系统就只有一个Jar包了。6.3 LW、调试文档与讲解怎么准备标题里带“源码LW调试文档讲解”这种交付物这个“LW”通常指论文/毕业论文但不管它叫什么核心就是让人能快速理解项目。调试文档我写的是“复现步骤手册”从导入数据库到启动项目再到测试每个页面的操作路径每一步都配上截图。写这种文档有个技巧多截图标红少写抽象描述。例如“点右上角登录按钮输入admin/admin123登录”比“后台系统登录后进入首页”清楚一百倍。论文/docs里不要大段贴代码更不要复制一整张数据表字段。老师想看到的是你的设计思路、流程分析和关键技术难点的解决方案。我会把系统架构图非Mermaid用Visio/UML画、订单时序图、ER图放进去这部分是拿分项。讲解视频/稿子我建议录一个10分钟左右的屏幕录制先讲背景与需求再演示功能最后讲一个你最有心得的技术点比如状态机或动态SQL这样整个项目就立住了。7. 复盘与扩展建议7.1 这套系统还能怎么升级技术上的扩展方向很明确把本地文件存储替换为云存储实现消息实时推送和站内聊天引入Spring Security OAuth2实现第三方登录再加上Elasticsearch做需求全文检索。但我更看重的是业务上的升级这个平台可以加一个“方案版权锁定”功能——设计师提交的方案在用户确认前带水印确认后才给高清原图。这个点在答辩时一提出来老师会觉得你有商业敏感度。实现上也不复杂前端展示时覆盖一层半透明水印原图下载链接改为订单状态为“已完成”时才返回。另外一个实际可做的就是数据分析统计比如按照设计类型统计平台订单量、热门风格排行、设计师成单率。管理员端通过ECharts展示这些图表会让系统显得更加完整和有亮点。7.2 给新手的几点实在建议第一功能宁少勿多但业务状态必须有闭环。你宁愿不做聊天功能也要把“需求发布-接单-打回-完成”这条主链路走得稳稳的。第二数据库先设计好再写代码。我见过太多人先写实体类再改表结构最后Mapper里全是NosuchField异常。建议直接手绘ER图把字段、关联键都定下来再进IDEA。第三权限校验别偷懒。哪怕只有三个角色每个接口都要带着横切权限判断。尤其是订单相关接口设计一个公共方法校验操作人与订单归属关系不要相信前端传什么你就信什么。第四答辩前一定要准备一个“为什么不用XX技术”的答案。比如为什么不用JPA为什么不用Redis缓存为什么不用分布式架构。不是非要使用这些技术而是你要能证明自己知道它们并做了取舍这个比硬堆技术更能让老师认可。最后分享一个我自己调试时踩过的坑SpringBoot的静态资源默认会处理/static/**下的内容但你自定义的WebMvcConfigurer里如果用registry.addResourceHandler(/upload/**)添加了资源映射文件路径在Linux服务器上大小写敏感如果配置的目录名和实际目录名对不上会一直报404调试很久才发现是大小写问题。这种基础问题让我养成了一个习惯所有自定义配置里的路径统一小写写完注释标注含义。希望后来的人少走点弯路。
