简介这是基于Python的Flask框架和MySQL数据库实现的二手物品交易平台毕业设计项目完整源码面向计算机专业学生、毕业设计开发者及Flask入门学习者。项目涵盖用户注册登录、商品发布、检索、收藏与交易管理等典型模块涉及Flask路由与模板渲染、MySQL表结构设计、SQLAlchemy数据操作、表单验证与基础安全防护等知识点可作为课程设计或毕业设计的直接参考模板。压缩包共79个文件约1.75MB以18个Python源码和17个编译后pyc文件为主另含7个HTML页面、7个CSS样式、3个JavaScript脚本、MySQL数据库的frm/ibd文件及项目文档与说明构成一套完整可运行的工程结构。已有2140人学习下载适合希望快速搭建同类型Web系统、理解前后端交互及数据库设计流程的读者。压缩包内附带数据库课程设计使用说明、系统设计PPT及项目介绍文档方便对照部署与答辩汇报。整体代码逻辑清晰、目录规范便于二次开发与学习。1. 能直接跑通买卖闭环的 Flask MySQL 二手交易平台先弄清楚它能干什么很多准备做毕设的读者问我要一套能跑的课程设计源码直接开箱那种。这套基于 Python Flask 框架和 MySQL 数据库实现的二手物品交易平台就是这类项目里比较完整的代表注册登录、商品发布与图片上传、关键字搜索、列表分页、购物车、下单、订单状态更新买家和卖家在同一个站里把交易闭环走完。它不是花哨的前后端分离项目而是用 Flask 默认模板和 MySQL 5.7/8.0 就能运行的传统 Web 应用能真正练到数据库表设计、Session 会话和电商里最基础的库存与订单流转。适合三类人毕业设计需要交付一个能演示的系统、学完 Flask 语法想对标一个完整工程的人、想拿这套底子改造成二手 C2C 小站的开发者。2. 数据库设计五张表怎么拆外键和索引怎么设2.1 从用户到商品再到订单先画出核心实体二手交易平台最核心的动作只有三个用户上架闲置、买家浏览搜索、买卖双方确认后生成订单。围绕这三个动作五张表基本够用users、goods、goods_images、carts、orders。users 管账号goods 管商品主体信息goods_images 单独拆出来是因为一个商品能挂多张图如果图片字段直接以逗号分隔存进 goods 表后期要删除某一张图或做封面图切换的时候处理起来非常难受。carts 是买家加购关系orders 记录每笔订单的快照信息。有人说课程设计没必要拆这么细直接在 goods 表里放一个 images TEXT 字段存 JSON 数组就行。讲道理这样写代码更快但有两个问题第一商品列表页经常只需要首图把整段 JSON 取出来再解析不如按封面图 ID 关联来得直接第二课程的加分点往往就落在“表结构设计合理”上。拆成 goods_images 后封面图用 is_cover 字段标记列表查询时拿主图直接关联逻辑清楚且不用动 JSON。另外一个选型点是表名统一用复数小写字段名用 snake_case。MySQL 在 Linux 下默认区分表名大小写Windows 不区分同一套代码在两台机器上部署时的行为不一致干脆统一小写避免踩坑。主键全部命名为 id外键命名带上被引用表名比如 seller_id、buyer_idSQL 联表时一眼能看出关联关系。这种命名习惯在答辩讲表结构时很好讲老师问到“为什么字段叫 seller_id”就能顺带把外键设计讲清楚。2.2 订单表为什么要冗余商品快照orders 表里有一个容易忽略的设计点把下单时的商品标题、成交价格、商品图片冗余存了一份。为什么要冗余因为商品可能被卖家下架或改价买家查历史订单时如果直接去关联 goods 表得到的结果可能已经变样。订单属于交易凭证金额和描述必须在下单那一刻定格这就是“快照”思路。金额字段用 DECIMAL(10,2) 而不是 FLOATFLOAT 是浮点数算单价和运费时会出 0.10.2 不等于 0.3 的情况虽然订单金额一般只做展示但在答辩时被老师追问精度问题很容易卡住。DECIMAL 在 MySQL 里以十进制形式存储能精确表达金额。外键策略我这样定users 删除时它发布的 goods 应该一并删除所以 goods.seller_id 外键用 ON DELETE CASCADEgoods_images.goods_id 同理用 CASCADEorders 里冗余的字段配合 buyer_id、seller_id 两个外键用 RESTRICT避免卖家被删后订单记录变得不可追溯。这个策略在执行 DELETE 时直接影响报错结果后面避坑章节会细说。2.3 建表 SQL 与参数说明以下是这套平台常用的核心建表脚本MySQL 8.0 环境库统一用 utf8mb4CREATE DATABASE IF NOT EXISTS second_hand DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci; USE second_hand; CREATE TABLE users ( id INT UNSIGNED AUTO_INCREMENT PRIMARY KEY, username VARCHAR(32) NOT NULL UNIQUE, password_hash VARCHAR(255) NOT NULL, nickname VARCHAR(50) DEFAULT , avatar VARCHAR(255) DEFAULT , created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, INDEX idx_username (username) ) ENGINEInnoDB;逻辑说明users 表主键用 INT UNSIGNED AUTO_INCREMENT课程设计规模完全够用username 加 UNIQUE 约束保证账号唯一登录查询时能直接命中索引不用再额外去重。password_hash 字段存的是 Werkzeug 生成的哈希串不是明文这一点很关键源码里如果直接存明文答辩时已经输了一半。avatar 字段存的是头像图片的相对路径不是二进制内容。CREATE TABLE goods ( id INT UNSIGNED AUTO_INCREMENT PRIMARY KEY, seller_id INT UNSIGNED NOT NULL, title VARCHAR(100) NOT NULL, description TEXT, price DECIMAL(10,2) NOT NULL, status TINYINT NOT NULL DEFAULT 0 COMMENT 0-在售 1-已售 2-下架, created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, updated_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, INDEX idx_seller (seller_id), INDEX idx_status_created (status, created_at), CONSTRAINT fk_goods_seller FOREIGN KEY (seller_id) REFERENCES users(id) ON DELETE CASCADE ) ENGINEInnoDB;参数说明price 用 DECIMAL(10,2) 表示最高 99999999.99对二手交易足够status 是 TINYINT三个值对应在售、已售、下架比用字符串省空间。idx_status_created 是组合索引列表页常见查询是“查在售并按发布时间排序”这个索引能同时覆盖 status 等值条件和 created_at 排序比各建一个单列索引更高效。CREATE TABLE goods_images ( id INT UNSIGNED AUTO_INCREMENT PRIMARY KEY, goods_id INT UNSIGNED NOT NULL, image_path VARCHAR(255) NOT NULL, is_cover TINYINT NOT NULL DEFAULT 0 COMMENT 1-封面图, sort_order SMALLINT NOT NULL DEFAULT 0, FOREIGN KEY (goods_id) REFERENCES goods(id) ON DELETE CASCADE ) ENGINEInnoDB; CREATE TABLE carts ( id INT UNSIGNED AUTO_INCREMENT PRIMARY KEY, user_id INT UNSIGNED NOT NULL, goods_id INT UNSIGNED NOT NULL, quantity INT NOT NULL DEFAULT 1, added_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, UNIQUE KEY uk_user_goods (user_id, goods_id), FOREIGN KEY (user_id) REFERENCES users(id) ON DELETE CASCADE, FOREIGN KEY (goods_id) REFERENCES goods(id) ON DELETE CASCADE ) ENGINEInnoDB; CREATE TABLE orders ( id INT UNSIGNED AUTO_INCREMENT PRIMARY KEY, order_no VARCHAR(32) NOT NULL UNIQUE, buyer_id INT UNSIGNED NOT NULL, seller_id INT UNSIGNED NOT NULL, goods_id INT UNSIGNED NOT NULL, goods_title VARCHAR(100) NOT NULL, goods_image VARCHAR(255) NOT NULL DEFAULT , price DECIMAL(10,2) NOT NULL, quantity INT NOT NULL DEFAULT 1, total_amount DECIMAL(10,2) NOT NULL, status TINYINT NOT NULL DEFAULT 0 COMMENT 0-待付款 1-已付款 2-已发货 3-已收货 4-已取消, paid_at DATETIME NULL, created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, INDEX idx_buyer (buyer_id), INDEX idx_seller (seller_id), INDEX idx_order_no (order_no), CONSTRAINT fk_order_buyer FOREIGN KEY (buyer_id) REFERENCES users(id) ON DELETE RESTRICT, CONSTRAINT fk_order_seller FOREIGN KEY (seller_id) REFERENCES users(id) ON DELETE RESTRICT, CONSTRAINT fk_order_goods FOREIGN KEY (goods_id) REFERENCES goods(id) ON DELETE RESTRICT ) ENGINEInnoDB;说明几个参数order_no 用 VARCHAR(32) 存业务订单号生成规则一般取日期时间加随机数不直接用自增 ID 当订单号给用户看UNIQUE 约束在并发下兜底重复插入会直接报错而不是产生脏数据。orders 对 users 和 goods 都是 RESTRICT意思是有关联订单时禁止删除这就是第 5 章会遇到的 1451 外键约束错误来源删除用户或商品前必须先处理掉关联订单属于有意为之不是 bug。还要注意 AUTO_INCREMENT 与 InnoDB 的关系。MySQL 8.0 里 InnoDB 的 AUTO_INCREMENT 计数器在服务重启后不会回退但 MySQL 5.7 某些场景下删除最大行后重启主键可能被复用这在订单表里比较敏感——一个订单编号被复用会引发下游混淆。课程设计不用深究但如果你把订单号作为对外展示的单据号应该用 order_no 而不是 id。源码的订单展示也都走 order_no理由就在这里。2.4 连接串里的编码与心跳参数Flask 连接 MySQL 一般用 PyMySQL 驱动配合 SQLAlchemy源码的 config.py 里集中管理连接参数。有两项要盯住charset 必须写成 utf8mb4否则 emoji 表情或生僻字昵称在写入 users 表时直接报 Incorrect string value另一个是 MySQL 默认的 wait_timeout 是 8 小时Flask 开发模式下数据库连接池长期闲置会被服务端断开表现为页面隔了很久再刷新时报 “MySQL server has gone away”。SQLALCHEMY_DATABASE_URI ( mysqlpymysql://secondhand:your_password127.0.0.1:3306/second_hand ?charsetutf8mb4 ) SQLALCHEMY_POOL_RECYCLE 3600 SQLALCHEMY_POOL_PRE_PING True参数说明SQLALCHEMY_POOL_RECYCLE3600 让连接每小时回收一次低于 MySQL 的 8 小时超时阈值pool_pre_pingTrue 是 SQLAlchemy 1.4 之后推荐的探活方式每次从连接池取连接前先执行一次 SELECT 1连接断了就新建比手工心跳稳定。连接串里的 127.0.0.1:3306 是本机默认端口远程部署时改成服务器地址。业务账号不要直接用 root新建一个 secondhand 用户并只授权 second_hand 库权限边界清晰一些。数据库连接这一块还有一个隐藏点SQLAlchemy 1.4 的 engine 默认在首次连接时才建立连接池启动源码时如果 MySQL 没就绪Flask 不会直接报错而是等你访问第一个查询接口时才爆 Connection refused。这也是我建议先确认 MySQL 服务在跑、建表完成再启动 Flask 的原因。3. Flask 后端蓝图划分、登录会话与商品发布接口3.1 按业务拆蓝图别把路由全堆在一个文件拿到源码后第一个要观察的就是项目目录结构。很多课程设计把所有路由写在 app.py 里三五百行后找接口全靠 CtrlF维护成本很高。这套源码采用蓝图的模块划分方式apps/auth.py、apps/goods.py、apps/carts.py、apps/orders.py 分别放对应的路由。蓝图的好处体现在两个地方一是 URL 前缀隔离比如 goods 蓝图统一挂在 /goods 下商品发布、编辑、列表、详情四个接口的路径函数不需要互相管二是便于在某个蓝图里单独挂钩子函数比如订单模块要校验登录态购物车模块也要校验统一在蓝图里写 before_request 钩子比在每条路由里重复判断省很多代码。from flask import Blueprint goods_bp Blueprint(goods, __name__, url_prefix/goods) goods_bp.route(/) def goods_list(): # 商品列表支持 keyword、page、sort 三个查询参数 pass goods_bp.route(/publish, methods[GET, POST]) def publish(): # 商品发布GET 渲染表单POST 处理提交 pass goods_bp.route(/int:goods_id) def detail(goods_id): # 商品详情从 goods 表取数据同时查出图片列表 pass参数说明Blueprint 构造的第一个参数是蓝图名用于 url_for 生成 URL比如 url_for(goods.detail, goods_id1)url_prefix/goods 决定了该蓝图下所有路由都以 /goods 开头。路由规则里的 int:goods_id 是转换器限定只接收整数传字符串会直接 404比在函数里做类型判断更干净。发布接口写成 GET、POST 共用视图函数内部用 request.method 分流这样可以少写一个用于渲染表单的路由。3.2 登录会话session 与密码哈希用户登录态这块源码几乎一定会用 Flask 自带的 session 实现。它把 session 数据用 secret_key 签名后放在用户浏览器的 Cookie 里对课程设计来说足够安全也省去搭 Redis 的成本。登录成功后往 session 里放 user_id 和 username首页通过 session.get(user_id) 判断登录态。密码不存明文。Werkzeug 提供了 generate_password_hash 与 check_password_hash源码里一般直接调用from werkzeug.security import generate_password_hash, check_password_hash # 注册时生成哈希 password_hash generate_password_hash(123456) # 登录时校验 is_ok check_password_hash(user.password_hash, 123456)逻辑说明generate_password_hash 默认采用 scrypt 或 pbkdf2 算法加盐生成哈希串每次调用结果都不一样数据库里即使被拖库也无法直接反推密码。登录校验时传给 check_password_hash 的第一个参数是数据库里存的哈希第二个是用户输入的明文顺序别写反写反了会一直返回 False。logout 的处理是 session.clear() 或删除对应键再重定向回首页。注意 Flask 的 session 是基于 Cookie 的没有服务端过期任务所以应用必须设置 SECRET_KEY。SECRET_KEY 别用 secret 这种值至少用一句不常见的短语源码的 config.py 里一般会配置改了之后所有老用户的登录态都会失效因为签名对不上了。3.3 商品发布与图片上传文件校验怎么做商品发布表单包含标题、描述、价格、图片。价格在 Flask 端拿到的是字符串存入 MySQL 前需要转成 Decimal后端最好再对范围做一次校验只靠 HTML 的 required 和 typenumber 挡不住接口直接 POST 请求。图片是这套源码最容易翻车的地方很多新手直接把 file.filename 拿去拼接路径被路径穿越搞到头皮发麻。常见的处理流程request.files.get(cover) 拿到 FileStorage 对象先校验扩展名再用 uuid 重命名最后保存到 uploads 目录。secure_filename 能过滤掉路径符号但对中文文件名不友好中文会被直接剥离成空串所以常见做法是放弃原文件名import uuid from pathlib import Path from werkzeug.utils import secure_filename ALLOWED_EXTENSIONS {png, jpg, jpeg, gif, webp} BASE_UPLOAD_DIR static/uploads/goods def save_image(file_storage): # 1. 从原始文件名取扩展名并转小写 original_name file_storage.filename or ext original_name.rsplit(., 1)[-1].lower() if . in original_name else # 2. 扩展名不在白名单直接拒绝不存盘 if ext not in ALLOWED_EXTENSIONS: raise ValueError(不支持的图片格式) # 3. 用 uuid 重新命名避免中文名和路径穿越问题 new_filename f{uuid.uuid4().hex}.{ext} save_dir Path(BASE_UPLOAD_DIR) save_dir.mkdir(parentsTrue, exist_okTrue) save_path save_dir / new_filename file_storage.save(save_path) return f{BASE_UPLOAD_DIR}/{new_filename}参数说明ALLOWED_EXTENSIONS 是扩展名白名单不够严谨但课程设计够用严格一点应该用 Pillow 检查文件头防止把可执行文件改名成 jpg 上传占服务器空间。BASE_UPLOAD_DIR 用相对路径在 Flask DEBUG 模式下没问题因为工作目录就是项目根目录但部署后用 gunicorn 启动时工作目录不一定在项目根需要改成基于file计算的绝对路径第 5 章会展开讲。uuid4().hex 生成 32 位十六进制字符串几乎不会碰撞。最后把相对路径存进 goods_images 表模板那边用 url_for(static, filenameimg_path) 拼接访问。3.4 商品搜索与排序用参数化 SQL 防注入搜索接口承担的是 keyword 和排序。课程设计里最常见的错误是字符串拼接 SQL比如 WHERE title LIKE %{keyword}%。如果用户在 keyword 里输入 ; DROP TABLE goods;--拼接后 SQL 就变成了多条语句数据库可能直接被重置。正确做法是参数绑定from sqlalchemy import text sql text( SELECT * FROM goods WHERE status 0 AND title LIKE :kw ORDER BY CASE :sort WHEN new THEN created_at END DESC, CASE :sort WHEN price_asc THEN price END ASC, CASE :sort WHEN price_desc THEN price END DESC LIMIT :limit OFFSET :offset ) rows db.session.execute( sql, {kw: f%{keyword}%, sort: sort, limit: page_size, offset: (page - 1) * page_size}, )逻辑说明这里用命名参数 :kw、:sort、:limit 传递变量数据库驱动会做转义用户输入永远只被当作字面值不会拼接成新语句。排序用两个 CASE WHEN 表达式实现三种排序共用一个模板避免为每个排序写一条 SQL。LIMIT 和 OFFSET 也都参数化了page 是从 URL 拿到的字符串在 Python 侧必须先 int() 一次否则 MySQL 会做隐式转换遇到怪参数直接报语法错。keyword 为空时 LIKE %% 会匹配所有行业务上可以接受但更规范的做法是空关键字时直接走不带 LIKE 的查询。对课程设计级别的数据量这点性能差异感知不到更多是为了养成好习惯。搜索结果页的分页组件要带上 keyword 参数否则翻页后搜索词丢失这是列表页最容易出现的隐形 bug。4. 前端模板与交易闭环Jinja2 渲染、购物车与订单确认4.1 模板继承与分页列表页渲染的边界这套源码前端用的是 Flask 自带的 Jinja2 模板没有单独写 Vue也没有前后端分离。对课程设计来说这是优点只要懂一点 HTML 就能改页面服务端渲染在答辩演示时不依赖 Node 环境也不用跨域处理。结构上一般会有一个 base.html头部放导航、搜索框和登录态入口正文区域用 block content 由子模板填充。页面上共享的导航和页脚全部收敛到基础模板里改一次全站同步。列表页最需要处理的是分页组件。数据量不大时直接在 SQL 里 LIMIT/OFFSET模板中渲染上一页下一页按钮{% if pagination.has_prev %} a href?page{{ pagination.prev_num }}keyword{{ keyword }}上一页/a {% endif %} span第 {{ pagination.page }} / {{ pagination.pages }} 页/span {% if pagination.has_next %} a href?page{{ pagination.next_num }}keyword{{ keyword }}下一页/a {% endif %}参数说明pagination 对象由后端传入自带 page、pages、has_prev、has_next、prev_num、next_num 属性不用在模板里自己算偏移量。keyword 在分页跳转时要同步携带否则从第 2 页点到第 3 页搜索条件就丢了。商品卡片循环渲染时价格格式化用 %.2f|format(item.price)封面图取 goods_images 里 is_cover1 的那条记录没有封面图时给一张占位图避免 img 标签破图影响页面观感。4.2 购物车接口同一商品重复加购要累加数量购物车在这个平台里的逻辑比较轻一个用户对应一个商品条目同一个商品重复加购时数量累加而不是插入新行。carts 表里已经建了 UNIQUE KEY uk_user_goods(user_id, goods_id)数据库层已经拦住重复数据代码层要做的就是先查再决定插入或更新。def add_to_cart(user_id, goods_id, quantity1): item Carts.query.filter_by(user_iduser_id, goods_idgoods_id).first() if item: # 已存在数量累加但上限保护一下 item.quantity min(item.quantity quantity, 99) else: # 不存在校验商品存在且在售 goods Goods.query.get(goods_id) if goods is None or goods.status ! 0: raise ValueError(商品不存在或已下架) db.session.add(Carts(user_iduser_id, goods_idgoods_id, quantityquantity)) db.session.commit()逻辑说明filter_by 命中联合唯一索引判断是否存在是索引等值查询很快。累加时用 min 做数量上限保护防止恶意把数量加到 999 后订单金额溢出。加购前校验商品状态是必须的否则会出现“购物车里有商品点结算时商品已经下架”的情况这个校验虽然不能完全避免但能把异常提前暴露。加购接口以 POST 暴露给模板表单只提交 goods_id 和 quantity 两个字段。另一个容易忽略的点结算时要重新读取购物车条目并逐个检查商品在售状态而不是信任购物车里的旧数据因为商品可能在用户停留购物车页面期间被卖家下架。这一步要放在事务里做。4.3 下单与订单状态机创建订单和扣减商品状态必须绑定下单是整个平台的业务核心。下单动作本质上做了三件事把购物车条目搬进 orders 表、把对应 goods 的状态改成已售、清空购物车。这三件事必须在一个事务里完成如果先写订单再改商品状态中间进程崩溃就会出现“订单已生成但商品还是待售状态”之后两个买家可能同时买到同一件商品。from sqlalchemy.exc import SQLAlchemyError def create_order_from_cart(user_id, cart_item): try: # 行级锁 在售校验防止并发下超卖 goods Goods.query.with_for_update().filter_by( idcart_item.goods_id, status0 ).first() if goods is None: raise ValueError(商品已下架或不存在) order_no generate_order_no() order Orders( order_noorder_no, buyer_iduser_id, seller_idgoods.seller_id, goods_idgoods.id, goods_titlegoods.title, goods_imagegoods.cover_image, pricegoods.price, quantitycart_item.quantity, total_amountgoods.price * cart_item.quantity, status0, ) goods.status 1 db.session.add(order) db.session.delete(cart_item) db.session.commit() return order_no except SQLAlchemyError: db.session.rollback() raise逻辑说明with_for_update().filter_by(id..., status0) 同时做了行级锁和商品在售校验两个条件都满足才继续这是防止两个买家同时下单买到同一件商品的关键。total_amount 用 goods.price 乘数量在服务端计算不信任前端传过来的金额防止有人改页面绕过。db.session.commit() 把订单插入、商品状态修改、购物车删除三个操作一次性提交任何一步失败都 rollback 回滚三个表不会出现数据不一致。这些边界判断看着多但都是真实业务流程里会发生的。课程设计里最容易被评委追着问的就是“并发下单会不会超卖”和“订单状态能不能乱跳”把事务和状态机这两块讲清楚项目深度马上不一样。4.4 卖家端订单管理状态推进怎么约束订单不能从“待付款”直接跳到“已收货”状态机至少要有明确路径0 待付款 → 1 已付款 → 2 已发货 → 3 已收货任何一步回退都是异常操作。源码里一般用字典定义允许流转ALLOWED_TRANSITIONS { 0: (1, 4), # 待付款可以付款或取消 1: (2,), # 已付款只能发货 2: (3,), # 已发货可以确认收货 }逻辑说明每次更新状态前先判断当前状态在字典里的可流转集合中不在直接返回错误。这比散落的 if 判断更结构化答辩时被问到“订单状态怎么保证不跳步”也能直接答道状态机约束。买家确认收货后流程闭环如果需要扩展后续可以在确认收货后给买卖双方加评价表但基础源码一般不做评价系统。5. 环境配置与常见问题排查从 MySQL 8 认证插件到中文乱码这一章是复现这套源码时的重灾区。很多读者下载源码后第一反应是跑业务代码结果连花两小时香的环境问题把耐心耗光。以下五条几乎覆盖了我在不同机器上复现 FlskMySQL 项目时遇到的绝大多数情况。5.1 MySQL 认证插件报错caching_sha2_password现象按教程装完 MySQL 8.0用安装时设置的 root 密码在命令行能登录但 Flask 项目连接时报 Authentication plugin caching_sha2_password cannot be loaded。原因MySQL 8.0 默认认证插件是 caching_sha2_password而项目里用的 PyMySQL 或较老的 mysqlclient 驱动版本默认支持的是 mysql_native_password两边版本不匹配时驱动加载不了新插件。解决不用纠结版本直接创建专用账号并指定旧插件CREATE USER secondhandlocalhost IDENTIFIED WITH mysql_native_password BY your_password; GRANT ALL PRIVILEGES ON second_hand.* TO secondhandlocalhost; FLUSH PRIVILEGES;参数说明localhost 限定只允许本机连接课程设计跑在本机没问题如果要部署到服务器改成 % 并用防火墙限制端口。FLUSH PRIVILEGES 让账号权限立即生效。这条配置是新手拿到源码后最常卡住的地方项目 README 里往往有提示但赶时间的读者通常直接跑等报错才回头。5.2 中文乱码建库、连接、页面三层都要统一现象插入商品标题带“蓝牙耳机”数据库里显示成问号或者直接报 Incorrect string value: \xE8... for column。原因字符集不一致。MySQL 默认字符集可能是 latin1建库时没指定 utf8mb4或连接串没带 charsetutf8mb4。三层里任何一层不一致都会乱码这不是玄学是编码链路断了。解决建库语句已经写了 DEFAULT CHARACTER SET utf8mb4连接串也带了 charsetutf8mb4。如果你拿到的源码没带按这两处补上。还要检查 MySQL 服务端配置 my.cnf 或 my.ini[client] default-character-setutf8mb4 [mysql] default-character-setutf8mb4 [mysqld] character-set-serverutf8mb4 collation-serverutf8mb4_general_ci验证方式登录 MySQL 后执行 SHOW VARIABLES LIKE character_set%; 看到 server 和 database 都为 utf8mb4 就对了。页面端也要有 缺了的话浏览器按其他编码渲染同样会乱码。5.3 外键约束删除用户或商品时报 1451现象删除一个用户时 MySQL 报 Cannot delete or update a parent row: a foreign key constraint fails于是想当然改成 SET FOREIGN_KEY_CHECKS0 强行删。原因orders 表对 users 的 RESTRICT 约束阻止了删除操作这是设计上要保护交易记录不被连带清空不是配置错误。SET FOREIGN_KEY_CHECKS0 是全局关闭约束对数据完整性影响很大跑完忘改回 1后续插入脏数据都不知道。解决符合业务的删除方式有两种。需要清理测试数据时先删该用户相关的 orders再删 users或者把 orders 的 buyer_id、seller_id 外键改成 ON DELETE SET NULL同时允许字段为 NULL。商品删除同理先删 goods_images 和其下订单再删 goods。课程设计演示时没有真实订单数据直接删用户后商品会级联删除但 orders 表空着不受影响一旦有测试订单就会撞上 1451。提示SET FOREIGN_KEY_CHECKS 只在当前会话生效断开重连后自动恢复为默认值真遇到问题时别用这个绕过。真遇到了别用 FOREIGN_KEY_CHECKS0 糊弄按业务顺序删。这个习惯在带生产的项目里能救命。5.4 图片上传路径DEBUG 下能显示部署后全 404现象本地 flask run 图片一切正常换 gunicorn 启动后上传的图片打不开。原因上传路径是相对路径 static/uploadsgunicorn 启动时工作目录不在项目根目录保存和访问都错位了。DEBUG 模式下 Flask 会自动从当前目录找 static生产模式由配置指定。解决把上传目录改成基于项目根目录的绝对路径在 config.py 里用 pathlib 计算BASE_DIR Path(__file__).resolve().parent UPLOAD_FOLDER BASE_DIR / static / uploads / goods逻辑说明file是当前文件绝对路径resolve().parent 取所在目录这样不管进程从哪里启动路径都指向项目根下的 static/uploads/goods。模板渲染图片时依旧用 url_for(static, filenameuploads/goods/xxx.jpg)只要 UPLOAD_FOLDER 和 static 指向同一块物理路径就能访问到。部署时如果用了 Nginx 托管 /static则不需要 Flask 来处理静态文件但本地复现时用默认方式最省事。5.5 端口占用与启动失败flask run 起不来现象执行 flask run 后终端报 Address already in use或者改了代码但页面行为没变。原因5000 端口被上一轮调试进程占用或者没开 DEBUG 没有热加载。Windows 下最常见的是 Python 进程没杀干净尤其是 IDE 里运行过的残留进程。解决先查谁占了端口# Windows netstat -ano | findstr :5000 # Linux lsof -i:5000拿到 PID 后终止进程不想杀进程就直接换端口flask run --host 0.0.0.0 --port 5001端口空闲但启动报错看日志是不是缺少依赖把常见依赖直接补上pip install flask flask-sqlalchemy pymysql注意这个命令默认装最新 Flask 3.xFlask 2.x 的项目在 Flask 3 底下有几个不兼容点典型的是 session 的 JSON 序列化和部分扩展的兼容层有差异通常不影响课程设计。如果启动后页面 500回看源码 requirements.txt 里锁的版本把它对齐到同一版本再跑。6. 部署与验证用 Gunicorn 上线后如何快速自查6.1 生产环境启动命令与反向代理配置本地跑通后如果要把项目部署到服务器上给老师远程演示不建议继续用 flask run。它自带的是 Werkzeug 开发服务器单进程性能不够且控制台会输出一堆调试信息。常见做法是用 Gunicorn 当 WSGI 服务进程外面再套一层 Nginx 反向代理。pip install gunicorn gunicorn -w 4 -b 127.0.0.1:8000 app:create_app()参数说明-w 4 表示启动 4 个 worker 进程课程设计规模下完全够用-b 指定绑定本机 8000 端口不直接绑 0.0.0.0让 Nginx 在前面转发。app:create_app() 是应用工厂写法如果项目入口是 app Flask(name)就写 app:app。Nginx 里核心配置就三行静态文件 location 指向项目 static 目录动态请求 proxy_pass 到 8000。不想装 Nginx 的话直接 gunicorn -b 0.0.0.0:8000 也能跑只是图片加载完全走 Flask慢一些。注意gunicorn 只支持 Linux/macOSWindows 上演示直接用 flask run 即可不用强上 gunicorn。6.2 上线后 30 秒快速自查清单部署完成不要急着关终端。我做这类项目部署的验核习惯是固定走一遍完整流程注册一个新账号、发布一个带图片的商品、搜索这个商品、加购、下单、确认收货。一遍流程走完数据库里查订单记录SELECT order_no, status, total_amount, created_at FROM orders ORDER BY id DESC LIMIT 5; SELECT title, status FROM goods ORDER BY id DESC LIMIT 5;两条 SQL 能确认下单事务是否完整orders 表有记录、goods.status 变成 1。如果 orders 有记录但 goods.status 还是 0说明下单逻辑没走事务或事务提交异常立刻回看 4.3 的 commit 位置。图片是否 404 用 curl 验证curl -I http://your-server/static/uploads/goods/图片文件名返回 200 说明路径没问题返回 404 则检查 UPLOAD_FOLDER 和 Nginx 的 alias 是否对上了。关于 Flask 与 FastAPI 的选型顺带说一句课程设计和大多数企业内部小工具Flask 的生态和心智负担都更友好FastAPI 自带 OpenAPI 文档和异步支持适合未来要拆微服务或接口要被第三方调用的场景。这套二手交易平台如果要改造最值得动的部分是把商品搜索换成全文检索而不是急着换框架。我最后说一下每次复现这类 FlaskMySQL 源码的习惯拿到工程先读 requirements.txt再读 config.py最后看 app.py 入口。依赖版本对齐后用 MySQL 跑一遍建表脚本然后才启动 Flask。从那以后我每换一台机器部署这套项目都强制先查 MySQL 认证插件和字符集再谈业务代码——这两步没踩稳后面一切报错都会指向错误的方向。希望帮到你。本文还有配套的精品资源点击获取