简介面向软件工程专业学生、毕业设计开发者及需要规范化文档支撑的校园项目团队这份校园二手交易系统概要设计说明书以真实场景为依托系统解决从需求确认到详细设计之间的蓝图缺失问题。文档遵循标准概要设计规范完整涵盖编写目的、背景、定义与参考资料并重点展开总体设计明确系统模块划分用户管理、商品发布、交易管理、支付、评价、系统管理等模块通过系统模块图与流程图直观展示模块间交互及数据流转同时详细说明功能需求与程序模块的映射关系给出用户接口、管理员接口及系统接口的设计要点并涉及运行环境、出错处理与安全设计为后续编码奠定坚实基础。资源包为1个docx文档压缩后大小441KB内容结构规范、层级清晰既可作为软件工程课程设计或毕业设计的模板也可为实际开发二手交易平台提供直接参考。目前已有8123人学习下载适合需要快速理解概要设计写法或落地校园交易项目的读者。 校园二手交易系统这类选题在毕业设计和课程项目中几乎是常青树。每年都有大量学生会选它但真正能把“概要设计说明书”写得像样的不多。多数人要么堆模板要么把需求分析和概要设计混为一谈最后数据库设计表结构一贴就以为万事大吉了。这篇内容我按照一份能直接用来指导编码、能通过评审的概要设计标准来拆解。不论你是正在做毕业设计还是想完整走一遍系统设计流程这篇文章都能给你一套可以落地、可以复用的思路。1. 先弄清楚这套系统到底要解决什么问题写概要设计说明书最容易犯的错误就是一上来画架构图、贴技术栈。实际上概要设计的起点应该是回答一个问题这套系统为谁、解决什么痛点、核心业务流程长什么样想不清楚这三件事后面所有设计都是空中楼阁。1.1 校园闲置交易的痛点与系统目标校园里的二手交易需求非常真实。毕业生离校时成堆的教材、考研资料、台灯、自行车低年级学生又确实需要这些但不想全价买新的。过去的交易方式无非是QQ群发消息、贴吧发帖、朋友圈吆喝问题很突出信息分散、容易被刷屏淹没、没有检索功能、交易双方缺乏信任和约束机制。所以这套系统的核心目标不是做一个花哨的电商平台而是解决三个具体问题信息聚合让校园内的闲置商品能在一个统一平台上展示和检索。可信交易通过校内身份认证、信用记录、交易评价等机制降低交易风险。流程闭环从商品发布、浏览、下单、成交到评价形成完整的线上流程。这一点需要在说明书的需求概述部分讲透因为后面所有的模块划分和数据结构设计都是围绕这三个目标展开的。1.2 角色划分与边界约定系统的用户角色建议划分为三类不要贪多角色核心职责关键用例普通用户买家/卖家合一发布闲置、浏览搜索、下单购买、管理个人物品商品发布、商品搜索、订单创建、订单确认收货系统管理员用户管理、商品审核、举报处理、数据统计商品下架、用户禁用、分类管理、交易数据报表访客浏览公开信息作为潜在用户商品搜索浏览、查看商品详情之所以把“买家和卖家”合并为普通用户是因为在实际校园场景里一个学生可能今天卖书明天买别人的自行车身份随时切换。如果强行分离成两个角色会让权限设计和数据库结构都变复杂完全没有必要。管理员权限只需要做到能审核、能下架、能禁用不要过多干预交易流程。1.3 核心业务流程必须在这里跑通概要设计说明书里业务流程图是必须的。但这个阶段不要求画得太细画出主干流程即可。我的建议是重点画两条一条是商品交易主流程一条是管理员审核流程。商品交易主流程大致是用户登录 → 发布商品 → 系统自动提交审核 → 管理员通过后商品上架 → 买家浏览搜索 → 买家下单 → 卖家确认 → 买家确认收货 → 互相评价。这里有一个容易忽略的设计点商品是否需要审核我见过不少系统设计把发布商品设计成即时上架省去审核环节。从技术实现上确实更简单但从实际运营角度看如果不设审核一天之内就会充斥着各种违规信息。为了安全起见建议设计为“发布后自动进入待审核状态管理员通过后正式上架”。技术实现上只需要在商品表上加一个status字段0-待审核1-上架中2-已下架3-审核拒绝开销极低但对系统生态的洁净度帮助非常大。2. 技术选型不是“越新越好”的游戏技术选型是概要设计说明书里的重头戏也是很多学生最纠结的部分。我的观点很明确选技术栈优先考虑你对该技术的掌握程度和社区资料的丰富程度而非技术本身是否前沿。2.1 前后端分离还是服务端渲染目前主流且适合毕设和中小型校园项目的方案有两种方案一经典单体 服务端渲染如 Spring Boot Thymeleaf / JSP优点结构简单部署方便适合新手。所有业务代码在一个工程里启动一个应用就搞定调试和排错成本低。缺点前后端耦合较紧后期如果要做移动端或者小程序后端接口需要额外提供。方案二前后端分离如 Vue Spring Boot / Django优点前后端职责清晰分工明确更接近企业实际开发模式。前端调后端接口数据格式以 JSON 为主。缺点需要同时维护两个工程部署时要处理跨域和静态资源问题工作量有一定增加。我的建议是如果时间紧张或者后端是你的主攻方向选方案一如果想把项目经验写得好看一点或者打算将来往全栈方向发展选方案二。两种方案都要在说明书中讲清楚为什么选它面试时也能有话可说。2.2 数据库和中间件的选型逻辑数据库方面MySQL依然是这个场景下最稳妥的选择。原因很简单校园项目并发量不会特别高MySQL完全能扛住你遇到的大部分报错都能在搜索引擎上找到答案。如果想要一个加分项可以引入 Redis 做缓存比如首页热门商品列表、商品详情缓存、登录会话等。但注意Redis 的引入必须有明确的使用场景别为了用而用。在概要设计里要写清楚哪些数据会进 Redis采用什么淘汰策略缓存和数据库的一致性怎么做。至于文件存储商品图片建议使用本地文件存储加 Nginx 映射即可。如果服务器资源有限可以考虑对象存储服务但那样会引入外网依赖。非要画一张技术架构图的话层级不要超过五层前端展示层 → 网关/入口层可选→ 应用服务层 → 数据缓存层 → 数据库与文件存储层。2.3 运行环境与版本约定这部分在说明书中容易被一笔带过但到后面部署时会卡住很多人。建议在概要设计说明书里明确写下统一的环境版本JDK 1.8不要用太新的大版本避免兼容性问题MySQL 5.7 或 8.08.0 默认字符集utf8mb4对表情符号支持更好Redis 6.x如果引入缓存Maven 3.6 或 Gradle构建工具二选一Node.js 14如果用前后端分离把这些写进文档是为了保证团队多人协作或导师复核时环境是一致的。否则你本地能跑、别人拉下来跑不起来排查问题先折腾半天。3. 系统架构在“让学生用起来爽”和“让老师看得懂”之间找平衡概要设计说明书里的系统架构图既不能画成天书也不能瞎画。很多同学喜欢把架构图画得特别复杂微服务、消息队列、容器编排全都堆上去。我作为看惯了这类设计的人可以负责任地说校园二手交易系统这个量级老老实实画一张分层架构图比什么都管用。3.1 分层架构怎么画才通俗又专业推荐画四层架构从上到下依次是表现层Presentation Layer负责与用户交互接受用户的输入请求渲染页面或返回 JSON 数据。如果是前后端分离这一层就是 Vue/React 应用如果是服务端渲染就是 Thymeleaf 模板页面。业务逻辑层Business Logic Layer系统的核心。负责处理具体业务规则比如商品发布校验、订单状态流转、积分计算等。建议在代码结构上按模块分包如user、product、order、transaction、admin。数据访问层Data Access Layer负责与数据库交互封装对 MySQL、Redis 的底层操作。可以用 MyBatis Plus 或 Spring Data JPA 等工具来简化开发在概要设计阶段注明即可。基础设施层Infrastructure Layer包括 MySQL 主库、Redis 缓存、文件存储系统等。在这里需要单独强调一个点架构图中不要出现“XX功能模块图”和“XX架构图”混用的情况。功能模块图是树的形状描述的是系统有哪些功能块架构图是分层或组件交互的形状描述的是系统在运行时的结构和协作关系。两者不能互相替代。3.2 模块化设计划分原则与模块清单在做模块划分时有一个检验标准每个模块应该可以独立描述它负责的业务范围模块与模块之间的依赖应当清晰可控。推荐按以下方式划分模块用户模块注册、登录、个人信息管理、校园认证、地址管理商品模块商品发布、商品审核、商品编辑、商品上下架、商品详情、商品搜索订单模块购物车、创建订单、订单状态管理、支付状态模拟校园场景建议引入在线支付或平台担保模式如果不想接第三方支付就做成“确认订单 线下交易”模式在文档里要写清楚收藏模块收藏商品、查看收藏列表评论与留言模块商品留言、交易评价管理后台用户管理、商品审核、举报处理、公告管理、数据统计至于要不要做“支付系统”这是很多学生特别纠结的点。我的建议是除非你打算接第三方支付沙箱环境否则不要引入真实支付流程。校园二手交易本身就是低额低频的场景把支付环节做成“在线下单 双方线下成交”的模式反而更真实、更贴近学生需求。在概要设计说明书中把这个取舍写清楚体现的是你独立思考和需求分析能力。3.3 接口文档的规范在这里就要定好接口层面概要设计不要求把所有接口都定义完但需要对接口规范做一个总体的约定。我建议在说明书中用一小节来定义统一返回格式。{ code: 200, message: success, data: {} }我推荐的状态码设计是200成功400参数错误401未登录403无权限404资源不存在500服务器错误。需要特别注意的是禁止直接用 HTTP 状态码做业务状态码。例如登录时密码错误HTTP 状态码是 200但业务 code 应该定义为400或1001这样前端才能根据业务 code 做统一拦截处理。4. 数据库设计这套系统的灵魂在表和表之间的关系说到数据库设计这往往是一份概要设计说明书中评审老师看得最仔细的部分。也是最有干货、最值得反复推敲的地方。很多同学的数据库设计就是简单堆几张表、写几个字段毫无关联设计。实际上表之间的关系决定了业务逻辑的复杂度也决定了后续 SQL 写起来顺不顺畅。4.1 核心数据表全景我建议按业务模块划分至少设计以下核心表用户表存储用户基本信息包括学号/工号、密码、手机号、邮箱、头像URL、角色普通用户/管理员、账号状态、注册时间。商品表关联用户表卖家存储商品标题、描述、原价、现价、图片URL列表、分类ID、成色等级、交易地点、商品状态、浏览量、创建时间、上架时间。订单表关联买家用户ID和商品ID存储订单状态、下单时间、成交价格、完成时间。收藏表关联用户ID和商品ID是典型的“用户-商品”多对多关系的中间表。评价表关联订单ID、评价者ID、被评价者ID、评分、内容、回复内容、评价时间。消息表站内留言或双方私信沟通关联发送者ID、接收者ID、消息内容、状态、时间。分类表商品分类例如教材书籍、生活用品、电子产品、自行车、服饰等。管理员操作日志表记录管理员审核、下架、禁用等操作便于责任追溯。4.2 关键表的字段设计细节附设计示例以商品表为例字段设计需要重点关注status和images字段。CREATE TABLE product ( id int(11) NOT NULL AUTO_INCREMENT COMMENT 商品ID, seller_id int(11) NOT NULL COMMENT 卖家ID关联user表, category_id int(11) NOT NULL COMMENT 分类ID, title varchar(100) NOT NULL COMMENT 商品标题, description text COMMENT 商品描述, original_price decimal(10, 2) NOT NULL COMMENT 商品原价, current_price decimal(10, 2) NOT NULL COMMENT 出售价, quality tinyint(4) DEFAULT 3 COMMENT 成色1-全新 2-几乎全新 3-轻微使用痕迹 4-明显磨损, status tinyint(4) NOT NULL DEFAULT 0 COMMENT 状态0-待审核 1-上架中 2-已下架 3-已售出 4-审核拒绝, images varchar(1024) DEFAULT NULL COMMENT 图片URL多张用逗号分隔, view_count int(11) DEFAULT 0 COMMENT 浏览量, created_at datetime NOT NULL COMMENT 发布时间, updated_at datetime NOT NULL COMMENT 更新时间, PRIMARY KEY (id), KEY idx_status (status), KEY idx_seller_id (seller_id), KEY idx_category_id (category_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT商品表;这里有几个容易被忽视的细节第一status字段一定要单独建索引因为商品列表页默认查询都是WHERE status 1上架中没有索引的话数据量大了之后会很慢。第二images字段用逗号分隔的 URL 拼接很多人觉得不规范但对于图片数量最多不超过9张的校园项目来说这比单独建一张商品图片表要实用得多。第三decimal(10, 2)是价格字段的标配千万不要用 float/double。浮点数在计算时会产生精度问题涉及金额的字段必须用decimal。4.3 表关系设计的三个避坑经验第一个坑订单表直接存商品快照不要只存商品ID引用。如果卖家的商品在买家下单后发生了价格修改或者商品被下架了订单表里只存一个商品ID买家看到的历史订单就会显示异常。正确做法是在订单表里把成交时的重要信息冗余存储例如product_title商品标题快照product_image商品图片快照product_price成交价格快照虽然这违背了数据库第三范式但在订单这种场景下是非常必要的数据冗余设计。第二个坑用户表中不要存“余额”或“积分”字段来模拟钱包功能。如果设计说明书里出现“用户钱包”相关字段会引出一连串你驾驭不了的账务一致性问题。校园二手场景下线下交易是最正常的模式在线支付和平台资金托管不是现阶段该解决的问题。第三个坑收藏表、购物车等中间表建议给“用户ID商品ID”建联合唯一索引。比如收藏表同一用户重复收藏同一商品如果代码里没判断好就会插入重复记录用UNIQUE KEY uk_user_product (user_id, product_id)这种约束来兜底比纯靠业务代码判断要稳得多。5. 接口层面为什么值得单独写一节很多概要设计说明书功能模块画完、数据库设计完就草草结束。但如果你能在说明书中加上“接口设计规范”和“关键接口定义”这一节这份说明书的完整度和专业度会直接上一个大台阶。5.1 关键接口概览在这个阶段不需要把所有接口穷举完但核心业务接口应当列出来。以商品模块为例至少包含商品发布接口POST /api/product/publish——需要登录需校验字段商品列表查询接口GET /api/product/list——支持分页、分类筛选、关键字搜索、价格排序商品详情接口GET /api/product/detail/{id}——需要增加浏览量计数商品下架接口PUT /api/product/off/{id}——仅卖家本人可操作商品审核接口PUT /api/admin/product/audit——仅管理员可操作接口的请求方法和 URL 设计听起来不难但对初学者来说是个门槛。我见过不少项目所有接口都用 GET 请求更新操作用 GET 带参数也照做。这种设计在答辩时很容易被挑出毛病。基础的 RESTful 规范还是要注意的查询用 GET新增用 POST修改用 PUT删除用 DELETE这本身就是概要设计说明书里值得写一小节的内容。5.2 搜索功能的设计取舍搜索是二手交易系统的核心功能。比较简单的实现是用 SQL 的LIKE模糊查询例如SELECT * FROM product WHERE status 1 AND (title LIKE CONCAT(%, #{keyword}, %) OR description LIKE CONCAT(%, #{keyword}, %))这个方案对于几千条数据量完全够用。但如果你的项目想体现一点技术追求可以考虑为商品加一个关键字匹配的keyword字段并在该字段和标题上建全文索引。在概要设计说明书中我建议把搜索设计描述为两步方案常规场景走 MySQL 模糊查询配合分类筛选、排序、分页。如果搜索频率高或者数据量大引入 ElasticSearch不推荐在这个阶段使用或使用 MySQL 全文索引作为过渡方案。这样做的好处是你既给出了当前系统的简单可行方案又考虑到了未来可能的性能瓶颈体现的是系统设计思维而不只是一个 CURD 代码工。6. 并发、安全和异常流程不在拼功能但必不可少校园二手交易系统虽然不属于高并发项目但作为一份合格的概要设计说明书你不要完全不考虑并发和安全问题。能在这个部分写出一两点让评审眼前一亮的思考这就是拉开分数差距的地方。6.1 并发场景这只“秒杀”其实是乐观锁能解决的二手交易平台最大的并发风险在于多人同时对同一件商品下单。如果下单逻辑是先查status是否为“上架中”再改status为“已售出”在并发情况下可能一件商品被两个人同时下单成功。解决方案有两种。方案一推荐使用乐观锁更新时带上条件判断。UPDATE product SET status 3 WHERE id #{productId} AND status 1判断影响行数如果返回 0说明商品状态已被其他用户更新下单失败。这个方案不需要引入复杂的锁机制代码逻辑也很简单。在概要设计说明书中把这种并发控制方案写清楚会是很加分的细节。方案二使用 Redis 分布式锁。对高并发场景效果更好但对于校园二手交易项目有点杀鸡用牛刀了引入的复杂性大于收益。6.2 权限控制的三重防护权限控制是安全设计的核心。我建议至少做三层接口级别使用 Spring MVC 拦截器或 Shiro/Spring Security 框架对需要登录的接口做拦截未登录请求直接返回 401。数据级别不能只校验“是否登录”还要校验“登录人是否有权限操作这笔数据”。例如用户删除商品接口参数传了id100此时必须校验商品seller_id是否等于当前登录用户的 ID。前端展示级别敏感按钮如“下架商品”“审核通过”根据当前用户的角色动态渲染避免普通用户看到管理功能入口。三层防护中数据级权限最容易漏掉。很多项目只做了用户是否登录的判断没做归属于判断导致一个普通用户可以改掉别人的商品信息。这个经典的上线事故各位务必在说明书中写清楚你的防护措施。6.3 敏感操作与异常兜底图片上传是另一个需要注意的安全点。校园项目里上传图片建议代码里明确校验文件类型、大小并把文件扩展名白名单限制在jpg、jpeg、png、gif、webp上。将文件保存到独立目录后不要用原始文件名用 UUID 重新生成避免路径穿越和文件名冲突问题。数据库操作中的事务控制也要单独说明涉及订单创建的接口必须使用Transactional事务注解。例如买家下单时需要同时执行“生成订单记录”和“修改商品状态”两个操作任何一个失败两个操作都必须一起回滚否则就会出现订单存在但商品状态没有改变的死数据。7. 文档写得好不好看这几个细节就够最后聊一个多数人写概要设计说明书时都不会注意的点文档的边界感。概要设计说明书不是需求文档也不是详细设计文档更不是代码注释的集合。它应该停留在“让评审者明白系统怎么搭、模块怎么划分、数据怎么组织”这个粒度。7.1 写好数据字典和枚举值说明在数据库设计章节强烈建议增加一张枚举值说明表。比如商品状态0、1、2、3、4分别是什么意思订单状态0、1、2、3分别代表什么。不要小看这个细节开发后期如果状态码没有统一文档前端和后端很容易各写一套到时候联调就是一场灾难。枚举值业务含义说明商品状态 - 0待审核用户发布后自动进入商品状态 - 1上架中管理员审核通过前台可见商品状态 - 2已下架用户或管理员手动下架商品状态 - 3已售出订单流程完成商品状态 - 4审核拒绝管理员拒绝用户可修改后重新提交7.2 几个能改善阅读体验的排版细节写技术文档要注意可扫描性。一段文字超过五六行阅读体验就会明显下降。善用表格来罗列字段、枚举值、接口参数和返回码比大段文字阐述高效得多。每个核心模块至少配一张流程图或者一张表结构关系图。注意架构图、流程图一定要用稳定的、可嵌入到文档里的工具来绘制比如 draw.io、ProcessOn 或者直接 Markdown 内嵌图片避免用什么在线流程图网站生成链接过几天就挂了。所有章节的编号要统一。第一章、第二章清晰划分。目录是评审老师快速定位内容的工具没有目录的说明书看起来会非常劝退。7.3 最后别把“非功能需求”写成空话概要设计说明书里必须有“非功能需求”这一节不能只写“系统应该可靠、安全、易用”这种废话。要写具体的指标或方案比如性能指标首页接口响应时间不超过 500ms搜索接口不超过 1s。可用性系统支持每天 2000 个 UV独立访客核心交易链路支持 100 人并发下单。安全指标用户密码采用 BCrypt 加密存储不用明文和 MD5。兼容性支持 Chrome、Edge、Safari 等主流浏览器最近两个大版本。能把这些指标写出来说明你真的考虑过系统上线后怎么运行而不是只应付一份文档。我在带项目的过程中有一个很深的体会很多人不是不会写代码而是设计文档阶段就没想清楚结果编码时反复返工。一份好的概要设计说明书写的不是“这个系统长了什么样子”而是“为什么这个系统应该长成这样”。把每一张表、每一个模块、每一个状态字段背后的设计理由写出来你已经是一份真正能指导落地的“超详细”设计文档了。本文还有配套的精品资源点击获取
简介面向软件工程专业学生、毕业设计开发者及需要规范化文档支撑的校园项目团队这份校园二手交易系统概要设计说明书以真实场景为依托系统解决从需求确认到详细设计之间的蓝图缺失问题。文档遵循标准概要设计规范完整涵盖编写目的、背景、定义与参考资料并重点展开总体设计明确系统模块划分用户管理、商品发布、交易管理、支付、评价、系统管理等模块通过系统模块图与流程图直观展示模块间交互及数据流转同时详细说明功能需求与程序模块的映射关系给出用户接口、管理员接口及系统接口的设计要点并涉及运行环境、出错处理与安全设计为后续编码奠定坚实基础。资源包为1个docx文档压缩后大小441KB内容结构规范、层级清晰既可作为软件工程课程设计或毕业设计的模板也可为实际开发二手交易平台提供直接参考。目前已有8123人学习下载适合需要快速理解概要设计写法或落地校园交易项目的读者。 校园二手交易系统这类选题在毕业设计和课程项目中几乎是常青树。每年都有大量学生会选它但真正能把“概要设计说明书”写得像样的不多。多数人要么堆模板要么把需求分析和概要设计混为一谈最后数据库设计表结构一贴就以为万事大吉了。这篇内容我按照一份能直接用来指导编码、能通过评审的概要设计标准来拆解。不论你是正在做毕业设计还是想完整走一遍系统设计流程这篇文章都能给你一套可以落地、可以复用的思路。1. 先弄清楚这套系统到底要解决什么问题写概要设计说明书最容易犯的错误就是一上来画架构图、贴技术栈。实际上概要设计的起点应该是回答一个问题这套系统为谁、解决什么痛点、核心业务流程长什么样想不清楚这三件事后面所有设计都是空中楼阁。1.1 校园闲置交易的痛点与系统目标校园里的二手交易需求非常真实。毕业生离校时成堆的教材、考研资料、台灯、自行车低年级学生又确实需要这些但不想全价买新的。过去的交易方式无非是QQ群发消息、贴吧发帖、朋友圈吆喝问题很突出信息分散、容易被刷屏淹没、没有检索功能、交易双方缺乏信任和约束机制。所以这套系统的核心目标不是做一个花哨的电商平台而是解决三个具体问题信息聚合让校园内的闲置商品能在一个统一平台上展示和检索。可信交易通过校内身份认证、信用记录、交易评价等机制降低交易风险。流程闭环从商品发布、浏览、下单、成交到评价形成完整的线上流程。这一点需要在说明书的需求概述部分讲透因为后面所有的模块划分和数据结构设计都是围绕这三个目标展开的。1.2 角色划分与边界约定系统的用户角色建议划分为三类不要贪多角色核心职责关键用例普通用户买家/卖家合一发布闲置、浏览搜索、下单购买、管理个人物品商品发布、商品搜索、订单创建、订单确认收货系统管理员用户管理、商品审核、举报处理、数据统计商品下架、用户禁用、分类管理、交易数据报表访客浏览公开信息作为潜在用户商品搜索浏览、查看商品详情之所以把“买家和卖家”合并为普通用户是因为在实际校园场景里一个学生可能今天卖书明天买别人的自行车身份随时切换。如果强行分离成两个角色会让权限设计和数据库结构都变复杂完全没有必要。管理员权限只需要做到能审核、能下架、能禁用不要过多干预交易流程。1.3 核心业务流程必须在这里跑通概要设计说明书里业务流程图是必须的。但这个阶段不要求画得太细画出主干流程即可。我的建议是重点画两条一条是商品交易主流程一条是管理员审核流程。商品交易主流程大致是用户登录 → 发布商品 → 系统自动提交审核 → 管理员通过后商品上架 → 买家浏览搜索 → 买家下单 → 卖家确认 → 买家确认收货 → 互相评价。这里有一个容易忽略的设计点商品是否需要审核我见过不少系统设计把发布商品设计成即时上架省去审核环节。从技术实现上确实更简单但从实际运营角度看如果不设审核一天之内就会充斥着各种违规信息。为了安全起见建议设计为“发布后自动进入待审核状态管理员通过后正式上架”。技术实现上只需要在商品表上加一个status字段0-待审核1-上架中2-已下架3-审核拒绝开销极低但对系统生态的洁净度帮助非常大。2. 技术选型不是“越新越好”的游戏技术选型是概要设计说明书里的重头戏也是很多学生最纠结的部分。我的观点很明确选技术栈优先考虑你对该技术的掌握程度和社区资料的丰富程度而非技术本身是否前沿。2.1 前后端分离还是服务端渲染目前主流且适合毕设和中小型校园项目的方案有两种方案一经典单体 服务端渲染如 Spring Boot Thymeleaf / JSP优点结构简单部署方便适合新手。所有业务代码在一个工程里启动一个应用就搞定调试和排错成本低。缺点前后端耦合较紧后期如果要做移动端或者小程序后端接口需要额外提供。方案二前后端分离如 Vue Spring Boot / Django优点前后端职责清晰分工明确更接近企业实际开发模式。前端调后端接口数据格式以 JSON 为主。缺点需要同时维护两个工程部署时要处理跨域和静态资源问题工作量有一定增加。我的建议是如果时间紧张或者后端是你的主攻方向选方案一如果想把项目经验写得好看一点或者打算将来往全栈方向发展选方案二。两种方案都要在说明书中讲清楚为什么选它面试时也能有话可说。2.2 数据库和中间件的选型逻辑数据库方面MySQL依然是这个场景下最稳妥的选择。原因很简单校园项目并发量不会特别高MySQL完全能扛住你遇到的大部分报错都能在搜索引擎上找到答案。如果想要一个加分项可以引入 Redis 做缓存比如首页热门商品列表、商品详情缓存、登录会话等。但注意Redis 的引入必须有明确的使用场景别为了用而用。在概要设计里要写清楚哪些数据会进 Redis采用什么淘汰策略缓存和数据库的一致性怎么做。至于文件存储商品图片建议使用本地文件存储加 Nginx 映射即可。如果服务器资源有限可以考虑对象存储服务但那样会引入外网依赖。非要画一张技术架构图的话层级不要超过五层前端展示层 → 网关/入口层可选→ 应用服务层 → 数据缓存层 → 数据库与文件存储层。2.3 运行环境与版本约定这部分在说明书中容易被一笔带过但到后面部署时会卡住很多人。建议在概要设计说明书里明确写下统一的环境版本JDK 1.8不要用太新的大版本避免兼容性问题MySQL 5.7 或 8.08.0 默认字符集utf8mb4对表情符号支持更好Redis 6.x如果引入缓存Maven 3.6 或 Gradle构建工具二选一Node.js 14如果用前后端分离把这些写进文档是为了保证团队多人协作或导师复核时环境是一致的。否则你本地能跑、别人拉下来跑不起来排查问题先折腾半天。3. 系统架构在“让学生用起来爽”和“让老师看得懂”之间找平衡概要设计说明书里的系统架构图既不能画成天书也不能瞎画。很多同学喜欢把架构图画得特别复杂微服务、消息队列、容器编排全都堆上去。我作为看惯了这类设计的人可以负责任地说校园二手交易系统这个量级老老实实画一张分层架构图比什么都管用。3.1 分层架构怎么画才通俗又专业推荐画四层架构从上到下依次是表现层Presentation Layer负责与用户交互接受用户的输入请求渲染页面或返回 JSON 数据。如果是前后端分离这一层就是 Vue/React 应用如果是服务端渲染就是 Thymeleaf 模板页面。业务逻辑层Business Logic Layer系统的核心。负责处理具体业务规则比如商品发布校验、订单状态流转、积分计算等。建议在代码结构上按模块分包如user、product、order、transaction、admin。数据访问层Data Access Layer负责与数据库交互封装对 MySQL、Redis 的底层操作。可以用 MyBatis Plus 或 Spring Data JPA 等工具来简化开发在概要设计阶段注明即可。基础设施层Infrastructure Layer包括 MySQL 主库、Redis 缓存、文件存储系统等。在这里需要单独强调一个点架构图中不要出现“XX功能模块图”和“XX架构图”混用的情况。功能模块图是树的形状描述的是系统有哪些功能块架构图是分层或组件交互的形状描述的是系统在运行时的结构和协作关系。两者不能互相替代。3.2 模块化设计划分原则与模块清单在做模块划分时有一个检验标准每个模块应该可以独立描述它负责的业务范围模块与模块之间的依赖应当清晰可控。推荐按以下方式划分模块用户模块注册、登录、个人信息管理、校园认证、地址管理商品模块商品发布、商品审核、商品编辑、商品上下架、商品详情、商品搜索订单模块购物车、创建订单、订单状态管理、支付状态模拟校园场景建议引入在线支付或平台担保模式如果不想接第三方支付就做成“确认订单 线下交易”模式在文档里要写清楚收藏模块收藏商品、查看收藏列表评论与留言模块商品留言、交易评价管理后台用户管理、商品审核、举报处理、公告管理、数据统计至于要不要做“支付系统”这是很多学生特别纠结的点。我的建议是除非你打算接第三方支付沙箱环境否则不要引入真实支付流程。校园二手交易本身就是低额低频的场景把支付环节做成“在线下单 双方线下成交”的模式反而更真实、更贴近学生需求。在概要设计说明书中把这个取舍写清楚体现的是你独立思考和需求分析能力。3.3 接口文档的规范在这里就要定好接口层面概要设计不要求把所有接口都定义完但需要对接口规范做一个总体的约定。我建议在说明书中用一小节来定义统一返回格式。{ code: 200, message: success, data: {} }我推荐的状态码设计是200成功400参数错误401未登录403无权限404资源不存在500服务器错误。需要特别注意的是禁止直接用 HTTP 状态码做业务状态码。例如登录时密码错误HTTP 状态码是 200但业务 code 应该定义为400或1001这样前端才能根据业务 code 做统一拦截处理。4. 数据库设计这套系统的灵魂在表和表之间的关系说到数据库设计这往往是一份概要设计说明书中评审老师看得最仔细的部分。也是最有干货、最值得反复推敲的地方。很多同学的数据库设计就是简单堆几张表、写几个字段毫无关联设计。实际上表之间的关系决定了业务逻辑的复杂度也决定了后续 SQL 写起来顺不顺畅。4.1 核心数据表全景我建议按业务模块划分至少设计以下核心表用户表存储用户基本信息包括学号/工号、密码、手机号、邮箱、头像URL、角色普通用户/管理员、账号状态、注册时间。商品表关联用户表卖家存储商品标题、描述、原价、现价、图片URL列表、分类ID、成色等级、交易地点、商品状态、浏览量、创建时间、上架时间。订单表关联买家用户ID和商品ID存储订单状态、下单时间、成交价格、完成时间。收藏表关联用户ID和商品ID是典型的“用户-商品”多对多关系的中间表。评价表关联订单ID、评价者ID、被评价者ID、评分、内容、回复内容、评价时间。消息表站内留言或双方私信沟通关联发送者ID、接收者ID、消息内容、状态、时间。分类表商品分类例如教材书籍、生活用品、电子产品、自行车、服饰等。管理员操作日志表记录管理员审核、下架、禁用等操作便于责任追溯。4.2 关键表的字段设计细节附设计示例以商品表为例字段设计需要重点关注status和images字段。CREATE TABLE product ( id int(11) NOT NULL AUTO_INCREMENT COMMENT 商品ID, seller_id int(11) NOT NULL COMMENT 卖家ID关联user表, category_id int(11) NOT NULL COMMENT 分类ID, title varchar(100) NOT NULL COMMENT 商品标题, description text COMMENT 商品描述, original_price decimal(10, 2) NOT NULL COMMENT 商品原价, current_price decimal(10, 2) NOT NULL COMMENT 出售价, quality tinyint(4) DEFAULT 3 COMMENT 成色1-全新 2-几乎全新 3-轻微使用痕迹 4-明显磨损, status tinyint(4) NOT NULL DEFAULT 0 COMMENT 状态0-待审核 1-上架中 2-已下架 3-已售出 4-审核拒绝, images varchar(1024) DEFAULT NULL COMMENT 图片URL多张用逗号分隔, view_count int(11) DEFAULT 0 COMMENT 浏览量, created_at datetime NOT NULL COMMENT 发布时间, updated_at datetime NOT NULL COMMENT 更新时间, PRIMARY KEY (id), KEY idx_status (status), KEY idx_seller_id (seller_id), KEY idx_category_id (category_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT商品表;这里有几个容易被忽视的细节第一status字段一定要单独建索引因为商品列表页默认查询都是WHERE status 1上架中没有索引的话数据量大了之后会很慢。第二images字段用逗号分隔的 URL 拼接很多人觉得不规范但对于图片数量最多不超过9张的校园项目来说这比单独建一张商品图片表要实用得多。第三decimal(10, 2)是价格字段的标配千万不要用 float/double。浮点数在计算时会产生精度问题涉及金额的字段必须用decimal。4.3 表关系设计的三个避坑经验第一个坑订单表直接存商品快照不要只存商品ID引用。如果卖家的商品在买家下单后发生了价格修改或者商品被下架了订单表里只存一个商品ID买家看到的历史订单就会显示异常。正确做法是在订单表里把成交时的重要信息冗余存储例如product_title商品标题快照product_image商品图片快照product_price成交价格快照虽然这违背了数据库第三范式但在订单这种场景下是非常必要的数据冗余设计。第二个坑用户表中不要存“余额”或“积分”字段来模拟钱包功能。如果设计说明书里出现“用户钱包”相关字段会引出一连串你驾驭不了的账务一致性问题。校园二手场景下线下交易是最正常的模式在线支付和平台资金托管不是现阶段该解决的问题。第三个坑收藏表、购物车等中间表建议给“用户ID商品ID”建联合唯一索引。比如收藏表同一用户重复收藏同一商品如果代码里没判断好就会插入重复记录用UNIQUE KEY uk_user_product (user_id, product_id)这种约束来兜底比纯靠业务代码判断要稳得多。5. 接口层面为什么值得单独写一节很多概要设计说明书功能模块画完、数据库设计完就草草结束。但如果你能在说明书中加上“接口设计规范”和“关键接口定义”这一节这份说明书的完整度和专业度会直接上一个大台阶。5.1 关键接口概览在这个阶段不需要把所有接口穷举完但核心业务接口应当列出来。以商品模块为例至少包含商品发布接口POST /api/product/publish——需要登录需校验字段商品列表查询接口GET /api/product/list——支持分页、分类筛选、关键字搜索、价格排序商品详情接口GET /api/product/detail/{id}——需要增加浏览量计数商品下架接口PUT /api/product/off/{id}——仅卖家本人可操作商品审核接口PUT /api/admin/product/audit——仅管理员可操作接口的请求方法和 URL 设计听起来不难但对初学者来说是个门槛。我见过不少项目所有接口都用 GET 请求更新操作用 GET 带参数也照做。这种设计在答辩时很容易被挑出毛病。基础的 RESTful 规范还是要注意的查询用 GET新增用 POST修改用 PUT删除用 DELETE这本身就是概要设计说明书里值得写一小节的内容。5.2 搜索功能的设计取舍搜索是二手交易系统的核心功能。比较简单的实现是用 SQL 的LIKE模糊查询例如SELECT * FROM product WHERE status 1 AND (title LIKE CONCAT(%, #{keyword}, %) OR description LIKE CONCAT(%, #{keyword}, %))这个方案对于几千条数据量完全够用。但如果你的项目想体现一点技术追求可以考虑为商品加一个关键字匹配的keyword字段并在该字段和标题上建全文索引。在概要设计说明书中我建议把搜索设计描述为两步方案常规场景走 MySQL 模糊查询配合分类筛选、排序、分页。如果搜索频率高或者数据量大引入 ElasticSearch不推荐在这个阶段使用或使用 MySQL 全文索引作为过渡方案。这样做的好处是你既给出了当前系统的简单可行方案又考虑到了未来可能的性能瓶颈体现的是系统设计思维而不只是一个 CURD 代码工。6. 并发、安全和异常流程不在拼功能但必不可少校园二手交易系统虽然不属于高并发项目但作为一份合格的概要设计说明书你不要完全不考虑并发和安全问题。能在这个部分写出一两点让评审眼前一亮的思考这就是拉开分数差距的地方。6.1 并发场景这只“秒杀”其实是乐观锁能解决的二手交易平台最大的并发风险在于多人同时对同一件商品下单。如果下单逻辑是先查status是否为“上架中”再改status为“已售出”在并发情况下可能一件商品被两个人同时下单成功。解决方案有两种。方案一推荐使用乐观锁更新时带上条件判断。UPDATE product SET status 3 WHERE id #{productId} AND status 1判断影响行数如果返回 0说明商品状态已被其他用户更新下单失败。这个方案不需要引入复杂的锁机制代码逻辑也很简单。在概要设计说明书中把这种并发控制方案写清楚会是很加分的细节。方案二使用 Redis 分布式锁。对高并发场景效果更好但对于校园二手交易项目有点杀鸡用牛刀了引入的复杂性大于收益。6.2 权限控制的三重防护权限控制是安全设计的核心。我建议至少做三层接口级别使用 Spring MVC 拦截器或 Shiro/Spring Security 框架对需要登录的接口做拦截未登录请求直接返回 401。数据级别不能只校验“是否登录”还要校验“登录人是否有权限操作这笔数据”。例如用户删除商品接口参数传了id100此时必须校验商品seller_id是否等于当前登录用户的 ID。前端展示级别敏感按钮如“下架商品”“审核通过”根据当前用户的角色动态渲染避免普通用户看到管理功能入口。三层防护中数据级权限最容易漏掉。很多项目只做了用户是否登录的判断没做归属于判断导致一个普通用户可以改掉别人的商品信息。这个经典的上线事故各位务必在说明书中写清楚你的防护措施。6.3 敏感操作与异常兜底图片上传是另一个需要注意的安全点。校园项目里上传图片建议代码里明确校验文件类型、大小并把文件扩展名白名单限制在jpg、jpeg、png、gif、webp上。将文件保存到独立目录后不要用原始文件名用 UUID 重新生成避免路径穿越和文件名冲突问题。数据库操作中的事务控制也要单独说明涉及订单创建的接口必须使用Transactional事务注解。例如买家下单时需要同时执行“生成订单记录”和“修改商品状态”两个操作任何一个失败两个操作都必须一起回滚否则就会出现订单存在但商品状态没有改变的死数据。7. 文档写得好不好看这几个细节就够最后聊一个多数人写概要设计说明书时都不会注意的点文档的边界感。概要设计说明书不是需求文档也不是详细设计文档更不是代码注释的集合。它应该停留在“让评审者明白系统怎么搭、模块怎么划分、数据怎么组织”这个粒度。7.1 写好数据字典和枚举值说明在数据库设计章节强烈建议增加一张枚举值说明表。比如商品状态0、1、2、3、4分别是什么意思订单状态0、1、2、3分别代表什么。不要小看这个细节开发后期如果状态码没有统一文档前端和后端很容易各写一套到时候联调就是一场灾难。枚举值业务含义说明商品状态 - 0待审核用户发布后自动进入商品状态 - 1上架中管理员审核通过前台可见商品状态 - 2已下架用户或管理员手动下架商品状态 - 3已售出订单流程完成商品状态 - 4审核拒绝管理员拒绝用户可修改后重新提交7.2 几个能改善阅读体验的排版细节写技术文档要注意可扫描性。一段文字超过五六行阅读体验就会明显下降。善用表格来罗列字段、枚举值、接口参数和返回码比大段文字阐述高效得多。每个核心模块至少配一张流程图或者一张表结构关系图。注意架构图、流程图一定要用稳定的、可嵌入到文档里的工具来绘制比如 draw.io、ProcessOn 或者直接 Markdown 内嵌图片避免用什么在线流程图网站生成链接过几天就挂了。所有章节的编号要统一。第一章、第二章清晰划分。目录是评审老师快速定位内容的工具没有目录的说明书看起来会非常劝退。7.3 最后别把“非功能需求”写成空话概要设计说明书里必须有“非功能需求”这一节不能只写“系统应该可靠、安全、易用”这种废话。要写具体的指标或方案比如性能指标首页接口响应时间不超过 500ms搜索接口不超过 1s。可用性系统支持每天 2000 个 UV独立访客核心交易链路支持 100 人并发下单。安全指标用户密码采用 BCrypt 加密存储不用明文和 MD5。兼容性支持 Chrome、Edge、Safari 等主流浏览器最近两个大版本。能把这些指标写出来说明你真的考虑过系统上线后怎么运行而不是只应付一份文档。我在带项目的过程中有一个很深的体会很多人不是不会写代码而是设计文档阶段就没想清楚结果编码时反复返工。一份好的概要设计说明书写的不是“这个系统长了什么样子”而是“为什么这个系统应该长成这样”。把每一张表、每一个模块、每一个状态字段背后的设计理由写出来你已经是一份真正能指导落地的“超详细”设计文档了。本文还有配套的精品资源点击获取
