简介：校园二手交易系统概要设计说明书是一份面向软件工程课程设计、毕业设计及实际项目开发的重要蓝图文档，帮助开发团队在需求分析之后、详细设计之前明确系统解决方案、功能分配、程序总体结构、输入输出与接口设计。文档以用户管理、商品发布、交易管理、支付、评价和系统管理等核心模块为基础，通过模块图和流程图清晰呈现数据流转与模块交互，并详细说明运行环境、出错处理及安全设计等要求。资料包仅1个docx文档，大小441KB，内容覆盖引言、总体设计、接口设计、数据结构设计等章节，结构规范、层次清晰，模块划分与处理流程说明完整，可直接作为课程报告或项目文档的参考模板。已有8123人学习下载，适合需要完成概要设计说明书的学生、开发人员快速掌握撰写方法，也可用于同类校园二手类系统开发的前期设计参考。
1. 概要设计说明书到底要设计什么
说实话，很多同学写概要设计说明书，写着写着就变成了“详细设计说明书”，甚至直接贴代码。这个坑我踩过，所以这次写校园二手交易系统的时候，我特意把“概要”和“详细”的边界划得很清楚：概要设计只回答三个问题——系统分几层、每层有哪些模块、模块之间怎么通信；至于某个接口的参数怎么定义、某张表索引怎么写，那是详细设计的事。
写这份说明书之前，我先把系统的核心定位想明白了：校园二手交易不是电商平台的低配版，它有自己的特殊约束——用户身份可信（学生/教职工）、商品流转范围小（校园内）、交易频次低但信任成本高。所以概要设计里，登录认证、商品可信度、线下交易撮合这三块是重头戏，而不是像淘宝那样去设计复杂的营销系统。
整份文档我的结构安排是这样的：先做总体架构设计，再拆功能模块，然后是最核心的数据库设计，接着梳理关键流程，最后补充接口和异常处理约定。这套顺序刚好是从“宏观到微观”，评审老师或者接手开发的同学，沿着这个顺序读下来，大脑不需要来回切换视角。
有一点我特别想提醒：概要设计说明书不是写给自己看的，是写给三类人看的——评审老师（判断方案是否合理）、以后接手的开发者（照着文档能搭起框架）、还有你自己（过几个月回来看还能想起来为什么要这么做）。所以我在文档里专门加了一节“设计约束与取舍记录”，把某些方案为什么不用另一个方案的原因写清楚，这个后面细说。
2. 总体架构：为什么选用分层架构而不是微服务
2.1 架构选型的取舍逻辑
校园二手交易系统，第一反应很多人会想上微服务：用户服务、商品服务、订单服务、支付服务拆开。我直接否掉这个方案。原因很现实：这个系统的并发量决定了它根本不需要微服务，一台中等配置的云服务器跑单体能扛住几百并发，而校园二手交易的真实场景是闲时多、高峰少，微服务引入的注册中心、配置中心、服务网关反而成了运维负担。
我选了经典的三层架构——表现层、业务逻辑层、数据访问层，单体应用部署。这不是保守，是“够用就好”。三层架构的另一个好处是团队协作方便：一个人负责前端页面，一个人负责业务逻辑，一个人负责数据库，边界清晰，互不干扰。对于课程设计或者小团队开发，这个模式最稳。
2.2 技术栈选择的依据
技术栈上我写的是Spring Boot + MyBatis Plus + MySQL + Redis，前端用Vue + Element UI。选Spring Boot没什么好犹豫的，它省掉了大量XML配置，内置Tomcat，打一个jar包就能跑；选MyBatis Plus是因为二手交易系统的查询条件非常灵活——按价格区间查、按成色查、按发布时间排序，Plus的动态SQL能少写很多if判断。
Redis在这里不是做缓存那么简单，我还设计了两个用途：一是存登录态，用token + Redis代替传统的Session，方便移动端和PC端共用一套认证逻辑；二是做商品浏览计数的缓冲，用户点开详情页的时候先写Redis，定时批量刷回MySQL，避免频繁更新热点数据把数据库拖垮。
安全方面，接口层面加了JWT鉴权 + 接口签名校验。很多学生项目会忽略接口安全，觉得“能跑就行”，但二手交易涉及真实金钱往来，证明“你是你”这件事很重要。JWT的token里我会塞userId和role，过期时间设成24小时，登出时把token加入Redis黑名单。
3. 功能模块拆分：从需求到模块的映射方法
3.1 模块划分的边界原则
需求分析阶段你可能整理出二三十条功能点，但概要设计阶段要做一步“归类合并”。我的做法是，按“用户角色 + 核心业务对象”两个维度划分模块。用户角色就三种：普通学生（买家/卖家）、管理员；核心业务对象是：用户、商品、订单、交易流水、收藏、评价。
按这个思路，我把系统拆成六个功能模块：
- 用户模块：注册、登录、个人信息维护、学生认证、信用分管理
- 商品模块：发布、编辑、上下架、分类浏览、搜索、商品详情
- 订单模块：创建订单、确认收货、取消订单
- 支付与结算模块：余额充值、下单锁定金额、确认收货后打款给卖家
- 消息模块：站内信、交易提醒
- 管理后台：用户管理、商品审核、举报处理、数据统计
这套划分的边界原则是：一个模块只负责一类业务对象的完整生命周期。比如订单模块只管订单从创建到完成的状态流转，至于订单对应的支付金额怎么算、什么时候冻结，那是支付模块的事，两个模块通过接口联动，不能互相写对方的表。
3.2 模块间的依赖关系设计
模块划完了，还得理依赖关系。我画了一张简单的依赖表：用户模块被所有模块依赖，商品模块被订单和收藏依赖，订单模块依赖支付模块。这个依赖方向必须朝着一个方向流，不能出现“订单模块调支付模块，支付模块又反过来调订单模块”的循环调用，否则后期维护会特别痛苦。
为了让依赖关系落地，我在文档里额外约定了一条铁律：上层模块可以调用下层模块的接口，但下层模块禁止反向依赖。比如商品模块不能因为“需要判断用户有没有完成学生认证”就去查用户表，而应该由用户模块提供一个checkStudentVerified(userId)接口。这条规定看起来死板，但它能保证每个模块独立可测试。
4. 数据库设计：这套系统的灵魂所在
4.1 核心表的梳理与命名规范
数据库设计是重头戏，我整整写了文档里最大的篇幅。先丢结论，我一共设计了12张表：用户表、商品表、商品图片表、商品分类表、订单表、支付流水表、余额流水表、收藏表、评价表、举报表、消息表、学生认证信息表。
命名规范上我统一了三条：表名用小写复数形式（users、goods、orders），字段名用蛇形命名（user_id、created_at），所有表必须有id主键、created_at、updated_at三个基础字段。前两条是常识，第三条很多人偷懒不加updated_at，等到排查数据异常找不到原因的时候就后悔了。
4.2 商品表的字段设计思路
商品表是最核心的表，我把字段设计拆开说明一下：
| 字段名 | 类型 | 说明 |
|---|---|---|
| id | bigint | 主键，自增 |
| user_id | bigint | 卖家ID，索引 |
| title | varchar(100) | 商品标题 |
| description | text | 商品详细描述 |
| category_id | int | 分类ID，比如教材、数码、生活用品 |
| price | decimal(10,2) | 售价，单位元 |
| original_price | decimal(10,2) | 原价，用于展示折扣力度 |
| condition_level | tinyint | 成色：1全新 2几乎全新 3轻微使用痕迹 4明显磨损 |
| status | tinyint | 状态：0草稿 1在售 2已售出 3下架 4审核不通过 |
| view_count | int | 浏览次数，默认0 |
| is_negotiable | tinyint | 是否可议价 |
condition_level这个字段是校园二手区别于普通电商的重要维度。二手商品的核心交易顾虑是“东西跟描述符不符”，所以成色分级要单独拎出来。我在文档里额外定义了一套分级的判定标准，比如“几乎全新”要求外观无划痕，所有功能正常；“轻微使用痕迹”允许有细微划痕，但不得影响使用。这套标准后面在商品审核和纠纷仲裁时都会用到。
4.3 订单表与资金安全设计
订单表我要重点讲讲金额拆分。字段长这样：order_no（订单编号）、goods_id、seller_id、buyer_id、amount（商品金额）、status（待付款/待发货/待收货/已完成/已取消）、created_at、paid_at、completed_at。
一个关键的字段是status的状态流转，我明确规定了只能按固定方向走：待付款→待发货→待收货→已完成，或者在任何一步可以走到已取消。为了防止并发下重复下单，我在goods_id上加了唯一约束，同一个商品同一时刻只能有一条有效订单。
资金安全我设计的是“平台担保交易”模式：买家下单后，钱不是直接打给卖家，而是冻结在平台的账户体系里；买家确认收货之后，系统再把钱从冻结余额转到卖家的可提现余额。对应到表结构，需要一张balance_transaction（余额流水表），每条资金变动都记录流水号、变动金额、变动类型（充值/冻结/解冻/收入）、关联订单号和创建时间。这样做的好处是，任何一笔钱怎么走的，都能查得清清楚楚，对账的时候直接按流水表汇总就行。
我做了一个数字推演：假设商品金额100元，买家充值100元→余额流水记一条+100；付款时记一条-100冻结；确认收货后，买家流水中-100（冻结减少）、卖家流水中+100（余额增加）。每一步都有流水可查。
4.4 学生认证表的设计
为什么单独建一张认证表而不是在用户表里加一个is_verified字段？因为认证信息包含学号、学院、入学年份、认证提交时间和审核状态，这些信息不是每次登录都需要的低频数据，拆出去能减轻用户表的查询负担。
我设计的表字段是：id、user_id、student_no（学号）、college、grade、id_card_photo_url（学生证照片）、status（待审核/通过/拒绝）、remark（拒绝原因）、created_at、reviewed_at。审核通过后，会在用户表冗余一个verified_status字段，这样商品发布时判断用户是否认证，就不用再去查认证表了。用空间换时间，这个账划算。
5. 关键业务流程：把抽象设计落到具体走查
5.1 发布商品的完整流程
很多文档会把流程画成流程图，我这次没有画图，用文字带大家走一遍。
用户从前端提交商品表单，后端接收后先做第一道校验：用户是否存在、有没有完成学生认证、有没有被拉黑。通过后再做第二道校验：商品标题长度（5~50个字符）、价格合理性（0.01~9999元）、描述字数（不少于10字）、图片数量（1~9张）。两道校验都过了，商品状态置为“待审核”，因为二手平台必须要有管理员审核环节，防止有人挂违规商品。
这里有一个容易被忽略的细节：商品如果审核不通过，需要记录reject_reason并通知用户。很多项目砍掉这个功能，结果用户体验极差——用户根本不知道自己的商品为什么消失。我在消息表里设计了一条站内信通知，审核结果一出来就自动推送。
5.2 交易的时序推演
交易流程我按“买家视角”拆成七个步骤：
- 买家浏览商品，看到在售状态，点击“立即购买”
- 系统检查商品状态，确认还是“在售”，生成订单，状态置为“待付款”
- 商品状态同步改为“锁定”（防止别人同时下单），这一步要用数据库乐观锁，检查
status=1再更新 - 买家在15分钟内完成支付，系统将金额从买家余额冻结
- 支付成功后订单状态变“待发货”（实际上校园二手大多是线下见面交易，所以没有快递环节）
- 双方线下交易完成后，买家点击“确认收货”，系统将冻结金额解冻并转入卖家余额
- 双方互相评价，交易完成
走查这个流程的时候我发现一个隐患：如果买家付款后一直不点确认收货，也没有物流信息可以自动确认，卖家就永远收不到钱。所以我在设计里加了超时自动确认机制——订单付款48小时后，系统自动确认收货并打款卖家。这个规则在用户协议里明确写了，设计师得把异常路径想全，不能只走“快乐路径”。
5.3 接口约定的规范
概要设计文档里接口部分不需要写每个接口的具体参数，但要定义清楚接口风格和规范。我定的规范是：统一使用RESTful风格，返回结构统一为{ code: 0, message: "success", data: {} }，分页接口统一用page和pageSize两个参数，排序字段统一用sortBy和order。
为什么统一返回结构这么重要？前后端联调的时候，如果有的接口返回{ success: true }，有的返回{ status: 200 }，前端就得为每个接口写不同的解析逻辑，那是纯粹的浪费时间。我见过太多学生项目挂在联调阶段，根因就是前后端没说好“黑话”。
6. 写文档踩过的坑和总结的避坑清单
6.1 四个最容易翻车的细节
第一，字段类型选的太随意。金额字段必须用decimal(10,2)，不能用float/double，因为二进制浮点数算钱会有精度问题，这是老生常谈但总有人踩。商品价格如果出现99.999999这种数，页面显示都会出bug。
第二，逻辑删除和物理删除没分清。用户发布的商品、订单等数据要保留痕迹，适合逻辑删除（加is_deleted标记字段），而消息通知这种数据可以根据需求物理删除。我在文档里标注清楚了哪些表用逻辑删除、哪些用物理删除，避免开发者各写各的。
第三，索引建少了。二手的核心查询场景是“按分类和价格筛选”“按发布时间排序”，所以category_id要建索引，created_at要建索引。我之前见过有人只在主键上建索引，数据量一到几千条，列表页查询就明显变慢。
第四，状态字段没有预留扩展空间。商品状态用tinyint取值0~4，看起来够用，但如果以后想加“管理员锁定”状态，就得改约束。我在文档里专门留了一个附件“状态枚举扩展表”，提醒后续维护者，加状态不叫改代码，叫设计演进。
6.2 概要设计文档里没写但实际要准备的东西
评审的时候老师大概率会问“性能怎么保证”“缓存策略是什么”。所以我在概要设计的大框架里，额外补全了两个细节：一个是商品列表查询用Redis缓存热门前100条，刷新策略是“写入数据库后主动删除缓存，下次查询重建”，这样能保证数据一致性；另一个是数据库定期备份方案，每天凌晨做一次全量备份，binlog做增量备份，保证真的出问题了能恢复到分钟级。
这两个点其实超出了概要设计的范围，但写进去之后文档的完整度立刻上了一个台阶。评审老师的反馈是“这个方案可以拿去落地”，冲这句话，前期多掉几根头发也值。
7. 写在最后的个人体会
这套校园二手交易系统的概要设计说明书，前后改了四版。第一版偏详细设计，第二版数据库过度设计（加了优惠券和拼团表），第三版砍掉所有非核心功能，第四版才算真正达到“概要”的要求——框架清晰、取舍有理、重点突出。
我个人的体会是：写概要设计说明书，最难的不是写出来，而是想清楚“系统长什么样”。在这个过程中你要不停逼自己做判断——做加法容易，做取舍很难。我的建议是，动手写文档之前，先花一晚上的时间把所有功能点写在小卡片上，然后开始分类、排序、删减，直到剩下的一定是你这个系统最核心、最不可省的内容，再打开文档开始写。到那天你会突然发现，文档其实一点也不难写，难的是前面的“想明白”。
本文还有配套的精品资源，点击获取
