企业官网建设流程全解析

1. 项目概述与技术选型理由

每年这时候，后台总有一堆人问毕业设计选什么题目。我的建议一直很直接——如果你不想在答辩台上被老师的连环追问击穿，就老老实实选一个"技术栈成熟、业务逻辑清晰、能讲清楚也能改进"的题目。酒类购物系统就是这一类里非常典型的选择。

先说清楚这个项目是什么。它是一个基于 Flask 搭建的 B2C 电商购物系统，核心服务对象是酒类商品。用户端包含注册登录、商品浏览、分类筛选、购物车、下单结算、订单管理；管理端包含商品上架下架、库存管理、订单状态流转、用户管理、基础的数据统计。技术层面使用 Flask 作为 Web 框架，SQLAlchemy 操作关系型数据库，Jinja2 模板渲染页面，前端搭配 Bootstrap 类的 UI 框架保证页面颜值。如果你手里拿到的是我整理的这份源码，运行起来就能看到完整的管理后台和数据交互逻辑，不是那种"只有一个登录页"的水货。

为什么用 Flask 而不是 Spring Boot 或者 Django？核心原因有三个。第一，Python 的上手成本低，如果你之前一直在写课程设计级别的代码，Flask 的学习曲线友好到不像话，一个最简应用三行代码就能跑起来。第二，Flask 本身极简，它不会像 Django 那样把模型、后台、模板、ORM 全部塞给你，而是让你根据自己的需要"插装"，这就意味着你在答辩时能对每一个模块说出"为什么这样设计"，而不是背一堆框架自动生成的代码。第三，对于酒类购物这种规模的系统，Flask 的 SQLAlchemy 集成、蓝图模块划分、Session 和 Cookie 会话管理已经绰绰有余，完全不需要引入重型框架。

这个项目适合什么人？两类人最适合。一类是计算机相关专业、毕设题目跟 Web 开发沾边、想用一份完整且能讲明白的源码过审的学生；另一类是刚学完 Python 基础、想通过一个全栈项目把 Flask、数据库、前端串起来的人。如果你属于这两类中的任意一类，往下读就行，我会把从源码结构到部署上线的关键环节全部拆开讲，包括我在实际跑项目时踩过的坑。

2. 系统整体设计与数据库建模

2.1 模块划分与蓝图机制

拿到源码以后，别急着运行，先看目录结构。一个设计良好的 Flask 项目，目录结构本身就是一份文档。我整理的这份源码采用了基于 Blueprint（蓝图）的模块化结构，跟那种所有路由都堆在app.py里的"教学式写法"有本质区别。

flask_wine_shop/ ├── app/ │ ├── __init__.py # 应用工厂 + 扩展初始化 │ ├── models.py # 数据库模型 │ ├── admin/ # 后台管理蓝图 │ │ ├── __init__.py │ │ ├── views.py # 后台路由 │ │ └── templates/ # 后台模板 │ ├── user/ # 前台用户蓝图 │ │ ├── __init__.py │ │ ├── views.py # 前台路由 │ │ └── templates/ # 前台模板 │ └── static/ # 静态资源 ├── config.py # 配置文件 ├── run.py # 启动入口 └── requirements.txt

可能有人会问，用一个app.py写完所有东西不也能跑？当然能跑，但有两个问题绕不过去。第一，可维护性差。前台路由、后台路由、用户认证、商品逻辑全部混在一个文件里，一旦出了 bug，定位问题的成本翻倍。第二，答辩经不住问。老师大概率会问"你的项目是怎么组织代码的"，你如果说"全写在一个文件里"，印象分会直接打折。而用了蓝图，你可以清晰地回答：前台和后台通过蓝图解耦，业务模块按照"用户端"和"管理端"划分，每个蓝图有独立的模板目录，扩展新功能时不需要动已有代码。

2.2 数据库表结构与关系设计

酒类购物系统的核心数据模型，我按照电商领域最常见的七张表来设计。七张表分别是用户表、商品表、分类表、购物车表、订单表、订单明细表和收货地址表。每张表的字段设计都有讲究，不是随便加的。

用户表字段重点看三个：username唯一索引、password_hash存加密后的密码、is_admin布尔值区分管理员和普通用户。密码绝对不允许明文存储，这是最基本的底线。我在源码里用的 Werkzeug 自带的generate_password_hash和check_password_hash，加盐哈希，虽然没有bcrypt那么强，但对毕设系统来说足够安全，而且省去额外安装依赖。

商品表我特意加了stock字段做库存管理，加sales_volume字段做推荐排序依据。为什么要加销售数字段？因为购物系统除了"能买"之外，还要考虑"怎么让用户更容易买到想买的酒"。有了销售量和分类，首页就可以做热门推荐和分类导航，这一个字段能让你的答辩多讲两分钟。

订单相关表的设计是这套系统的核心难点，也是我建议你在答辩时重点武装的地方。订单表和订单明细表用一对多关系关联，订单表存订单编号、用户 ID、总金额、状态、下单时间；订单明细表存商品 ID、商品名称快照、单价快照、数量、小计。这里有一个非常关键的细节：明细表里必须存商品名称和单价的快照，而不是通过外键去实时关联商品表。因为商品信息可能被修改或删除，如果订单明细只存了商品 ID，历史订单的数据就会错乱。这个细节你在讲数据库设计时主动提出来，老师会觉得你真的踩过坑、想过问题。

用户表与地址表是一对多关系，一个用户可以维护多个收货地址，下单时选一个。这样设计的好处是，用户不需要每次下单都重新填地址，而且查历史订单时能准确还原当时的收货信息。

2.3 数据模型与 Flask-SQLAlchemy 的结合

在代码层面，我用 Flask-SQLAlchemy 来定义模型。这里直接看我整理的核心建模方式。

from datetime import datetime from flask_sqlalchemy import SQLAlchemy from werkzeug.security import generate_password_hash, check_password_hash db = SQLAlchemy() class User(db.Model): __tablename__ = 'users' id = db.Column(db.Integer, primary_key=True) username = db.Column(db.String(64), unique=True, nullable=False, index=True) password_hash = db.Column(db.String(128), nullable=False) is_admin = db.Column(db.Boolean, default=False) created_at = db.Column(db.DateTime, default=datetime.now) # 关联字段 addresses = db.relationship('Address', backref='user', lazy=True) carts = db.relationship('Cart', backref='user', lazy=True) orders = db.relationship('Order', backref='user', lazy=True) def set_password(self, password): self.password_hash = generate_password_hash(password) def check_password(self, password): return check_password_hash(self.password_hash, password) def __repr__(self): return f'<User {self.username}>'

关于lazy=True这个参数，我想多说一句。很多人写 SQLAlchemy 的relationship时不指定lazy，默认是lazy='select'，也就是用到的时候才查询。这在数据量小的时候没有任何问题，但如果你在循环中访问用户的所有订单，会产生 N+1 查询问题。毕设系统数据量也就几百条，其实影响不大，但如果你在答辩时主动说出"我用懒加载避免了一次性加载不必要的数据"，这就是加分项。

建表之前先想清楚表与表之间的关系，建表之后不要频繁改动字段，否则后续代码里的查询逻辑全要跟着改。这是我在开发中反复踩坑总结出来的教训。

3. 核心功能实现与关键细节拆解

3.1 用户认证与会话管理

用户模块是整个系统的基础入口，没有用户体系，购物车和订单就无从谈起。Flask 生态里做登录认证主要有三种方案：手写 Session、用 Flask-Login 扩展、用 Flask-JWT。

如果你是纯新手，我建议用 Flask-Login。原因不是它比别的高端，而是它把会话管理做得足够简单：登录后把用户 ID 写进用户会话，请求进来时自动从会话中恢复用户对象，登出时清理会话。这套流程在毕设答辩中能讲清楚，而且它在源码里实现得很规整。

from flask_login import LoginManager, login_user, logout_user, login_required, current_user from app.models import User login_manager = LoginManager() login_manager.login_view = 'user.login' # 未登录时跳转到登录页 @login_manager.user_loader def load_user(user_id): return User.query.get(int(user_id))

这里有三个容易被忽视的点。第一个，login_view必须设置，否则未登录用户访问受保护路由时，Flask-Login 会直接抛 401 错误而不是跳转到登录页。第二个，user_loader回调必须返回User对象或None，返回None会被 Flask-Login 判定为会话失效。第三个，记住current_user是一个上下文变量，在模板里可以直接用{% if current_user.is_authenticated %}判断用户是否登录，不需要把用户对象手动塞给每个视图函数。

注册功能的坑还不在逻辑本身，而在于表单校验。我见过太多人注册时只验证"用户名非空"和"两次密码一致"，但完全没校验用户名是否已存在。这样连唯一索引都挡不住数据库层的报错，用户体验极差。源码里我用了一个User.query.filter_by(username=...).first()的预检查，注册前先把用户名查一遍。

3.2 商品展示与多条件搜索

商品列表页是用户进入系统后看到的第一个核心页面，它的体验直接决定系统第一印象。我在这里做了三件事：分类导航、关键词搜索、排序筛选。

分类导航实现简单，就是通过 URL 路由参数把category_id传给视图函数，模型查询时加一个filter_by条件。但这里有个设计上的取舍：是否要做多级分类？比如"白酒"下面再分"酱香型""浓香型"？我最终选择了单级分类，因为酒类商品的属性是"品牌 + 香型 + 度数"，不适合用目录树去套。如果你想把系统做得更完整，可以在商品表加degree和flavor_type字段，用 SQLAlchemy 的filter组合查询，这在数据库设计上就是横向扩展的一个例子，论文里可以写。

搜索这一块，关键在于like查询的性能问题。Product.query.filter(Product.name.like(f'%{keyword}%'))在数据量小的时候没问题，但如果在百万级商品的真实验收环境里这么做，会导致全表扫描。毕设不涉及大数据量，但你可以通过以下方式提前规避：在商品表的name字段上建索引，配合ILIKE（PostgreSQL 下）或者改用full-text search。答辩时被问到性能优化，你至少能说出两种以上的思路。

排序更简单，支持按价格升序、价格降序、销量降序、上架时间新到旧，四个参数用一个order_by动态拼接就行。

sort_mapping = { 'price_asc': Product.price.asc(), 'price_desc': Product.price.desc(), 'sales_desc': Product.sales_volume.desc(), 'new': Product.created_at.desc(), } sort_by = request.args.get('sort', 'new') products = Product.query.filter_by(category_id=category_id, status=True) \ .order_by(sort_mapping.get(sort_by, Product.created_at.desc()))

这行代码背后有一个细微的坑：sort_mapping.get()的默认值要兜底，因为用户完全可以在 URL 里手动传入一个不存在的排序参数。如果你直接拿用户输入去做order_by，会导致 SQLAlchemy 报错。这种参数校验的细节，代码里一定要考虑到。

3.3 购物车的两种实现方案

购物车是整个系统中业务逻辑最复杂的地方。可能有读者会想，购物车不就是把商品 ID 和数量存起来吗？是，但存哪里，有讲究。

方案一是用 Session 存购物车数据，也就是说购物车不落数据库，用户关掉浏览器再打开购物车就没了。方案二是用数据库表存购物车，登录用户随时可以恢复购物车内容。我在源码里默认用的是方案二，即数据库存储，因为毕设要展示的能力是"从数据库到界面的完整链路"，而且方案二在答辩时更有东西可讲。

购物车表的核心字段是user_id、product_id、quantity。这里有两个容易出 bug 的地方需要注意。

第一个是"重复添加同一商品"。用户第一次把"茅台飞天 53 度"加入购物车后，第二次再点击加入时，不应该新增一条记录，而应该把已有的那条记录的数量加一。如果每次点击都插入新记录，购物车会变得一团糟。实现逻辑是：先查Cart.query.filter_by(user_id=..., product_id=...).first()，有则更新quantity，无则新建记录。

第二个是"数量合法性校验"。库存只有 10 瓶，用户硬要塞 100 瓶，你必须在加入购物车时拦下来。这个校验前置和后置都要做，加入购物车时拦一次，提交订单时再拦一次。为什么前置校验还不够？因为从加入购物车到提交订单，中间可能有几分钟甚至几小时，这期间商品可能被其他人买走了，所以要留一个后置检查。

@bp.route('/add_cart/<int:product_id>', methods=['POST']) @login_required def add_cart(product_id): product = Product.query.get_or_404(product_id) quantity = int(request.form.get('quantity', 1)) if quantity < 1: flash('购买数量不能小于1', 'danger') return redirect(request.referrer or url_for('user.product_detail', product_id=product_id)) if quantity > product.stock: flash(f'库存不足，当前库存仅剩 {product.stock} 件', 'warning') return redirect(request.referrer or url_for('user.product_detail', product_id=product_id)) cart_item = Cart.query.filter_by(user_id=current_user.id, product_id=product.id).first() if cart_item: cart_item.quantity += quantity else: cart_item = Cart(user_id=current_user.id, product_id=product.id, quantity=quantity) db.session.add(cart_item) db.session.commit() flash('商品已成功加入购物车', 'success') return redirect(request.referrer or url_for('user.product_detail', product_id=product_id))

顺便说一句request.referrer的妙用。加入购物车后返回哪个页面？最简单的写法是写一个固定的redirect(url_for(...))，但这样用户体验不自然。用request.referrer可以做到"从哪个页面来的就回哪个页面去"，真实电商系统里也是这么做的。当然要注意referrer可能是None，所以必须给一个兜底跳转。

3.4 订单流转与状态机设计

订单是整个购物系统里最核心的数据实体，它的状态流转直接体现业务逻辑的完整度。我设计的订单状态有以下这些：待付款（PENDING）、待发货（PAID）、已发货（SHIPPED）、已完成（COMPLETED）、已取消（CANCELLED）。

为什么要用状态机来约束订单状态？因为订单状态不能被自由跳转，比如"已发货"的订单不能直接变成"待发货"，"已完成"的订单不能取消。你可以把这套逻辑当成一个防呆设计。实现方式不复杂，核心就是定义一个允许的状态迁移表。

ORDER_STATUS_MACHINE = { 'PENDING': {'PAID', 'CANCELLED'}, # 待付款可变为待发货或取消 'PAID': {'SHIPPED', 'CANCELLED'}, # 已付款可发货，极少数情况可退款取消 'SHIPPED': {'COMPLETED'}, # 已发货只能等收货完成 'COMPLETED': set(), # 终态 'CANCELLED': set(), # 终态 } def can_transition(current_status, target_status): return target_status in ORDER_STATUS_MACHINE.get(current_status, set())

在源码中，每次状态变更都调用can_transition做校验，校验通过再更新数据库。这套设计在论文的"系统设计"章节里值得精讲，老师很吃这一套。另外，每笔订单必须有独立的订单编号，不要用自增主键当订单号。我用的是时间戳加随机数的方式生成订单号：datetime.now().strftime('%Y%m%d%H%M%S') + random.randint(1000, 9999).__str__()。

下单的完整链路是这样的：先读取购物车中当前用户的所有记录，逐条校验库存；然后计算总价（单价乘数量取和，保留两位小数）；创建订单主记录，状态设为待付款；逐条创建订单明细，注意存商品名称和单价快照；清空购物车；跳转到支付页面。有一个很容易被忽略的点：事务控制。创建订单主记录、创建订单明细、清空购物车这三步必须放在同一个数据库事务里，要么全部成功，要么全部回滚。SQLAlchemy 的事务默认开启，但如果你在中间某一步忘记了db.session.commit()，会出现数据不一致的诡异问题。

try: # 创建订单主记录 order = Order(order_no=order_no, user_id=current_user.id, total_amount=total, status='PENDING', address_id=address_id) db.session.add(order) db.session.flush() # 先刷新以获取 order.id # 创建订单明细 for item in cart_items: product = Product.query.get(item.product_id) # 这里做库存的后置校验 if product.stock < item.quantity: raise ValueError(f'{product.name} 库存不足') detail = OrderDetail(order_id=order.id, product_id=product.id, product_name=product.name, price=product.price, quantity=item.quantity) db.session.add(detail) product.stock -= item.quantity # 扣减库存 product.sales_volume += item.quantity # 增加销量 # 清空购物车 Cart.query.filter_by(user_id=current_user.id).delete() db.session.commit() except Exception as e: db.session.rollback() flash(f'下单失败：{str(e)}', 'danger') return redirect(url_for('user.cart'))

这里我用了db.session.flush()，它的作用是先把 Order 对象写入数据库并生成自增 ID，这样接下来创建 OrderDetail 时才能拿到order.id作为外键。如果不flush，order.id还是None，外键插入直接报错。这个细节值得在源码注释里加一行，否则后面接手的同学很容易卡住。

3.5 支付模块的实现在线支付还是模拟支付？

这是每个毕设项目绕不开的问题。我的建议非常明确：做一个模拟支付页面，不要真接支付宝或微信支付。原因有三条。第一，真实支付需要商户号、密钥、回调接口，一系列资质审核和备案流程，你在毕设周期内很难走完。第二，即使你接上了沙箱环境，答辩时网不好或沙箱抽风，演示直接翻车。第三，模拟支付本身已经能覆盖系统的主流程，它只少了一个"真实扣款"的环节，但订单状态流转、支付回调逻辑、库存扣减这些核心能力全部都在。

模拟支付的实现很简单：下单后跳到一个确认支付页面，展示订单号和金额，点击"确认支付"后把订单状态从PENDING改成PAID。然后系统进入待发货状态，管理员后台可以点击发货，把状态改为SHIPPED，用户端确认收货后变成COMPLETED。

3.6 管理后台核心功能

管理后台是酒类购物系统的另一个半壁江山。没有后台的系统，撑死了算一个"演示页面集合"。管理后台的核心功能是这些：商品管理、订单管理、用户管理、数据统计。

商品管理这部分，核心是图片上传。项目里默认支持本地文件上传到app/static/uploads/，文件名我用时间戳重命名，防止中文文件名和用户上传的恶意文件名影响服务器安全。这里必须注意：对上传文件做类型检查，只允许.jpg、.png、.jpeg、.gif这几类格式，否则一个 PHP 文件传上去就直接拿到服务器权限了。虽然在毕设环境里威胁不大，但安全规范要养成。

订单管理部分，核心是状态流转操作。后台需要能查看所有订单，按状态下单的是：批量发货、订单详情查看。酒类作为特殊商品，后台还需要一个"商品上下架"操作，下架后前台不再展示该商品。

数据统计部分，我放了一个简单的可视化面板，展示总用户数、总订单数、总销售额、热销商品 Top5、每日订单趋势。这部分用纯 SQL 聚合就能实现，不需要额外引入 ECharts 之外的重型可视化库。SELECT DATE(created_at) as day, COUNT(*) FROM orders GROUP BY day这类查询就是常见思路。

4. 数据库访问优化与缓存设计心得

前文聊的主要是业务功能怎么拆、状态怎么流转，本节想跳出来聊一个更底层的点：数据访问。很多毕设系统能跑，但经不住问。你写代码的时候可能自己是唯一的用户，不觉得慢，可答辩现场老师让你点几下页面，然后随口问一句"你觉得这个系统的查询性能怎么样"，很多人就愣在台上了。

其实酒类购物这种体量的系统，数据库只要设计正常，性能根本不构成威胁。但"不构成威胁"不等于"没有优化空间"。至少有三层优化可以做：SQL 层面、缓存层面、索引层面。

SQL 层面的优化，核心经验就一条：避免循环查询。很多人写一个商品列表，会在模板里对每件商品做一次"查销量""查评分"的子查询，页面一打开就执行几十条 SQL 语句。解决办法也很简单：写一条 JOIN 查询直接一次拿回全部数据。商品表关联订单明细表去统计销量，用db.session.query(Product, func.sum(OrderDetail.quantity))...group_by(Product.id)，一次完成。

缓存层面，这是个加分项。Flask 里可以引入Flask-Caching扩展，对首页的热门商品列表、分类商品列表做 60 秒的缓存。为什么是 60 秒而不是更久？因为商品库存和价格需要一定的实时性，缓存太久会导致用户看到过期的库存状态。缓存策略在毕设级别用简单的SimpleCache或者RedisCache就够，不引入额外依赖最好。

索引层面，给products.category_id、orders.user_id、orders.status、order_details.order_id都建上索引。道理很简单：这些字段是查询和联查的高频字段，建了索引，SQLAlchemy 生成的 SQL 在执行计划里能走 Index Seek，性能提升非常明显。唯一要注意的是不要给每个字段都建索引，因为索引本身也占空间、拖慢写入速度。遵循"高频查询字段建索引"这个原则就够了。

5. 部署上线与常见问题排查

5.1 本地运行准备

拿到源码后怎么跑起来？按下面这个顺序操作，能避开 90% 的坑。

推荐用 Python 3.10 及以上版本，创建虚拟环境，然后安装依赖。我整理了一份requirements.txt，核心依赖版本如下：Flask==3.0.x、Flask-SQLAlchemy==3.1.x、Flask-Login==0.6.x、Flask-WTF==1.2.x、Jinja2==3.1.x、Pillow、Werkzeug。

安装命令是pip install -r requirements.txt。如果网络慢，加-i https://pypi.tuna.tsinghua.edu.cn/simple镜像源。

数据库这块，默认配置用的 SQLite，零配置开箱即用。如果你想用 MySQL，只需改config.py里的连接字符串：

SQLALCHEMY_DATABASE_URI = 'mysql+pymysql://root:password@127.0.0.1:3306/wine_shop?charset=utf8mb4'

建议首次运行前先在 MySQL 里创建好数据库wine_shop，否则应用连接时会报未知数据库错误。然后再跑db.create_all()建表，或者直接导入我提供的wine_shop.sql初始数据文件。

初始化数据这件事很值得强调：尽量不要从空数据库开始演示，因为空数据库的商品列表、订单数据、统计图表全是一片空白，演示效果差不说，老师还会觉得你连"造数据"的意识都没有。我给的源码里预置了约 20 款酒类商品，包含品类、价格、库存、图片路径、销量数据，足够撑起一场流畅的答辩演示。

5.2 生产环境部署：Gunicorn + Nginx

毕业设计虽然一般不会真的部署到公网，但如果你想把项目放到自己的云服务器上，或者要在论文里写"系统部署"章节，那了解一下下面的方案完全有必要。Flask 自带的app.run()是开发服务器，单线程，性能极差，不能满足生产需求。

生产部署的标准组合是 Gunicorn + Nginx。Gunicorn 是一个 Python WSGI HTTP 服务器，它能提供多进程能力，比 Flask 自带服务器靠谱得多。启动命令是：

gunicorn -w 4 -b 127.0.0.1:8000 run:app

-w 4意思是启动 4 个 worker 进程。这个数字不是越大越好，如果服务器只有 2 核 CPU，开 4 个 worker 就已经到上限了，再多反而会因为进程切换消耗 CPU。一个粗略的经验值：worker 数等于 CPU 核心数加 1。

Nginx 在这里的作用是反向代理和静态文件服务。把 Flask 应用跑在本地 8000 端口，Nginx 监听 80 端口，把外部请求转发到 8000。同时，app/static/目录下的静态文件由 Nginx 直接托管，不经过 Python 处理，减轻应用压力。部署配置大致是这样：

server { listen 80; server_name your_domain.com; location /static { alias /path/to/flask_wine_shop/app/static; } location / { proxy_pass http://127.0.0.1:8000; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; } }

5.3 踩坑实录与排查速查表

我在调试这套系统的过程中，整理过一份排错速查表，这里直接分享出来，每一个问题都是我亲自踩过、实测过的坑。

第三行那个"现象"是我故意写进去的。有不少人会把"购物车数据刷新后还在"当成 Session 问题来看，其实在数据库方案下就应该持久存在。就这个点，我在群里帮人排查过不止三次。

5.4 答辩前必须做的三件事

第一件事，把每个页面的 URL 和功能过一遍，重点演示三个链路：注册登录→购物车→下单支付→确认收货；后台登录→商品管理→订单发货；数据统计页面。这三个链路能完整走通，系统的主要能力就展示完毕了。另外准备一个"取消订单"的操作演示，因为老师有时候会临时提出想看看"异常链路"。

第二件事，把项目运行的步骤写成文档，放在项目根目录的README.md里。分步写明：创建虚拟环境、安装依赖、初始化数据库、启动应用、默认账号密码。这样做对你的启示是，老师如果拷走源码自己运行，能一步不差地跑起来，他心里对你的评价会明显上升。我见过太多人源码没有 README，运行步骤全靠口头讲，最后结果分被扣掉一大截。

第三件事，把数据库设计说明书整理成一份表格，包含每张表的字段名、类型、约束、用途说明。这份表格既是论文附录的好素材，也是回答"你这个表为什么这样设计"这类问题的底稿。

5.5 一个容易被问到的加分问题：为什么选 SQLite 做默认库

答辩时老师看到 SQLite 很可能会问一句："生产环境能用 SQLite 吗？"正确回答思路是：SQLite 适合开发环境和数据量小的场景，零配置、文件型数据库、便于部署和测试；生产环境如果数据量大、并发高，会切换成 MySQL/PostgreSQL。因为 SQLAlchemy 的 ORM 层把数据库差异做了抽象，切换数据库只需改一行连接串。这样回答，既坦诚又展示了你对技术选型的完整思考。

6. 从毕设到实战的一些自检心得

做完这套酒类购物系统，再回头看整个开发过程，我对几个点的体会特别深。

第一个是，功能"跑通"和"上线可用"之间有很长一段路要走。你本地跑通了所有流程，只能叫"功能实现"。当你思考"如何能扛住真实场景下的使用"时，才会开始关注 SQL 性能、缓存策略、数据库索引、部署配置这些更深的问题。毕设的价值不只是让你做一个能交差的东西，而是让你在做的过程中体验一次从设计、编码、调试到文档输出的完整链路。

第二个是，写代码之前先在纸上画一遍数据流转。很多人直接上手写路由函数，写一半发现缺字段、少表、关系不完整，然后推倒重来。我在这套系统开发中最大的效率提升，来自提前画好订单数据在用户、购物车、订单、订单明细、商品库存之间的流转路径，所有编码工作都是照着这个路径来推进的。

第三个是调试要善用日志。Flask 默认的app.logger就能满足大部分调试需求，有些同学一遇到问题就在代码里乱打print，然后满屏输出不知道从哪看起。建议在config.py里配置好日志级别和输出格式，至少在视图函数里留几行app.logger.info，这样部署到服务器上出了问题还能通过日志定位。

这套源码我已经按上述的模块设计、表结构、核心逻辑和部署方案整理打包好了，运行环境、初始数据和 README 都放在里面。如果你在跑源码的过程中遇到问题，对照上面那十行的速查表基本都能解决。剩下的，就靠你自己把每一行代码读到能讲明白的程度，答辩就不会是负担，反而会变成一次展示你真实代码能力的机会。