《在线画稿交易平台设计与实现》项目解析

一、项目概述

一个面向画稿交易场景的垂直电商平台。设计师可以入驻平台发布画稿、定价销售；普通用户可以浏览、购买画稿；管理员负责审核设计师身份、画稿内容和处理交易纠纷。

解决的核心问题

通用电商（淘宝等）卖画稿不专业，版权和审核机制不到位
国外平台（Etsy、Dribbble、Behance）设计师认证流程繁琐，效率低
国内平台（站酷、猪八戒）设计师认证不严，低质内容混入；交易透明度不足

项目定位

不是要替代淘宝或 Etsy，而是垂直化——专注画稿/数字设计作品交易场景，做精做深。

二、技术栈

层	技术
前端	Vue.js + Ant Design Vue + Vue Router + Vuex + axios
后端	Python 3.11 + Django + Django REST Framework (DRF)
数据库	MySQL 8.0
鉴权	JWT (JSON Web Token)
支付	支付宝 SDK（alipay-sdk-python）
开发工具	PyCharm 2024.3 + Node v18
部署环境	Linux 服务器

选型理由

Django：自带 ORM、Admin、用户认证、表单处理，开发效率高
Vue：中文文档完善、模板语法接近 HTML、配合 Ant Design Vue 快速出 UI
MySQL：交易场景需要 ACID 保证，画稿/订单/用户关系结构化
JWT：前后端分离架构友好，无状态利于水平扩展

三、系统架构

四层架构

┌─────────────────────────────────┐│  用户层（Chrome / Firefox）      ││  Vue.js + Ant Design Vue         │└─────────────────┬───────────────┘                  │ REST API┌─────────────────▼───────────────┐│  Web 应用服务层（Django）        ││  ├── 视图表示层（API 接收）      ││  ├── 业务处理层（核心逻辑）      ││  └── 数据访问层（ORM）           │└─────────────────┬───────────────┘                  │ ORM┌─────────────────▼───────────────┐│  数据库层（MySQL）               │└─────────────────┬───────────────┘                  │┌─────────────────▼───────────────┐│  操作系统层（Linux/Windows）     │└─────────────────────────────────┘

前后端分离的好处

职责清晰，前端专注 UI，后端专注业务
后端只提供 REST API，可同时支持 Web、小程序、App
前后端独立部署、独立迭代
前端静态资源可走 CDN 加速

四、用户角色

1. 普通用户

浏览/搜索/购买画稿
个人信息管理
申请成为设计师
余额充值（走支付宝）

2. 设计师

拥有普通用户的所有权限
发布、编辑、下架自己的画稿
查看自己作品的订单情况
余额提现

3. 管理员

审批设计师认证申请
审核设计师发布的画稿
处理订单纠纷（执行退款）
管理用户（封禁等）

五、核心功能模块

1. 用户管理模块

注册（含密码加密）
登录（JWT 鉴权）
个人信息维护
申请认证
余额充值
浏览记录

2. 画稿中心模块

搜索画稿
发布画稿
编辑画稿
画稿详情
购买画稿

3. 订单管理模块

创建订单
查询订单
取消订单
删除订单
修改订单

4. 后台管理模块

用户管理
画稿审核
设计师审批
订单管理（含退款）

六、关键业务流程

1. 注册 / 登录流程

注册：用户提交信息 → 后端校验 → make_password 加密 → 入库登录：验证用户名密码 → check_password 校验 → 生成 JWT → 返回前端后续请求：前端在 Header 带 token → 后端验签 → 通过则处理

2. 余额充值流程（支付宝）

用户点充值 → 创建充值订单（status=pending） → 调用支付宝 SDK 生成支付 URL→ 用户扫码支付 → 支付宝异步回调 notify_url→ 系统验签 → 更新订单状态为 paid → 增加用户余额

3. 画稿交易流程（核心闭环）

设计师发布画稿（待审核）  ↓管理员审核通过  ↓买家浏览 → 下单（订单状态 pending）  ↓判断余额是否充足？  ├── 不足 → 引导充值  └── 充足 → 扣买家余额 + 加卖家余额 → 订单状态 completed

关键设计：交易不直接走支付宝，而是走"平台内余额"——

充值进余额（支付宝实付）
交易扣余额（平台内部转账）
提现走支付宝（平台付出）

形成一个闭环。

4. 设计师认证流程

普通用户填申请理由 → 提交申请 → 状态 pending  ↓管理员后台查看申请列表 → 审批  ├── 通过 → 用户角色更新为"设计师"  └── 拒绝 → 记录拒绝理由

5. 退款流程

只有管理员能退款，且只能对 completed 订单退款：

管理员发起退款 → 检查设计师余额够不够  ↓扣设计师余额 → 退回买家余额 → 订单状态改回 pending

七、数据库设计

实体关系（E-R）

用户 (1) ─── 创建 ─── (n) 订单用户 (1) ─── 关联 ─── (1) 设计师设计师 (1) ── 绘制/发布 ── (n) 画稿订单 (n) ─── 属于 ─── (n) 画稿用户 (1) ─── 浏览/购买 ── (n) 画稿

核心表

user 表（用户表）

字段	类型	说明
id	bigint(20)	主键，自增
username	varchar(64)	账号
password	varchar(128)	密码（哈希）
nickname	varchar(32)	昵称
gender	int	性别
phone	varchar(32)	手机号
is_ban	int	是否禁用
balance	float	余额

draft 表（画稿表）

字段	类型	说明
id	bigint(20)	主键
title	varchar(64)	标题
description	varchar(1024)	描述
image_url	varchar(1024)	图片路径
price	float	价格
category	bigint	类别 ID
user_id	bigint	设计师 ID（外键）
status	varchar(20)	审核状态
online_time	datetime/bigint	发布时间
is_outline	int	是否下架

orders 表（订单表）

字段	类型	说明
id	bigint(20)	主键
user_id	bigint	买家 ID（外键）
amount	float	金额
status	varchar(20)	状态
draft_id	bigint	画稿 ID（外键）
create_time	datetime	下单时间
is_cancel	int	是否取消

designer 表（设计师表）

字段与 user 表一致，可视为 user 的扩展角色（实际设计冗余）。

设计原则

主键用 BIGINT，留扩展空间
外键约束保证关联完整性
NOT NULL 约束关键字段
设置默认值提高稳定性
高频查询字段加索引（username、user_id 等）
字符集 utf8mb4（支持 emoji 和生僻字）
引擎 InnoDB（支持事务和行锁）

八、安全机制

身份层

JWT 鉴权，每个请求验签
密码用 PBKDF2-SHA256 + 盐哈希存储
设计师人工审核
角色权限隔离

传输层

HTTPS 加密通信
支付宝接口 RSA 签名 + 验签

资金层

支付宝官方接口处理资金
异步回调验签防伪造
订单号 UUID 防重放

攻击防护

ORM 参数化查询防 SQL 注入
Vue/Django 默认转义防 XSS
JWT 放 Header 免疫 CSRF

九、创新点（论文宣称）

多角色管理机制：普通用户、设计师、管理员三级权限，支持设计师入驻和审核
前后端分离架构：提升可维护性和开发效率
JWT 无状态鉴权：服务器无需存会话，支持水平扩展
真实在线支付：集成支付宝接口，实现充值-交易-提现完整闭环

十、项目薄弱点（设计 / 实现层面）

数据库设计

❌ 金额用 float（应该用 DECIMAL）
❌ user 表和 designer 表字段重复（应单表 + role 字段）
❌ orders 表 is_cancel 与 status 语义重叠
❌ 时间字段类型不统一（datetime vs bigint）
❌ isban、isoutline 应该用 tinyint(1)
❌ gender 用 int 浪费空间

代码实现

❌ pay 函数没用数据库事务保护
❌ 没有并发控制（selectforupdate）
❌ 支付宝回调缺少幂等检查
❌ 没有全局越权访问校验

工程实践

❌ 配置硬编码（私钥写在 settings.py）
❌ 没有 Redis 缓存
❌ 图片存本地（应放 OSS）
❌ 搜索用 LIKE（应用 ElasticSearch）
❌ 没有限流和验证码
❌ JWT 没有 refresh token 机制
❌ 文件上传只校验扩展名

功能完整度

❌ 缺少评论 / 评分系统
❌ 缺少推荐算法
❌ 缺少版权保护机制（水印、追踪）
❌ 测试覆盖不充分（只 5 个用例）
❌ 性能测试和安全测试只有方法没有数据

总评

项目作为毕业设计完整度合格——核心闭环跑通，技术栈选型主流，文档结构清晰。但生产环境使用还需要在事务、并发、安全、性能上做大量加固。论文结语也承认了功能扩展空间。

十一、章节结构对照

章节	内容	页码
第 1 章引言	背景意义、国内外现状、研究内容方法	1-2
第 2 章开发技术介绍	Django、MySQL、JWT、Vue、Ant Design	3-4
第 3 章系统分析	可行性、功能需求、非功能需求、用例图	5-9
第 4 章系统设计	架构、模块、数据库（含建表语句）	10-17
第 5 章系统实现	注册登录、充值、设计师认证、画稿交易	18-30
第 6 章系统测试	测试方法、功能测试用例、测试结论	31-34
结语	总结 + 未来展望	35