Python Flask电商比价可视化系统：从数据库设计到实现全解析

毕业设计季又开始热闹了，几乎每年这时候都会有一批同学被同一个题目卡住——"电商比价系统"。说实话，这题目看着不大，但真要把它做成一个"能演示、能答辩、能截图放简历"的完整项目，涉及的东西远比想象中多：要采集数据、要建商品表、要比价算法、要可视化，还要保证整个系统运行流畅、逻辑闭环。今天要分享的这套"基于Python + Flask电商比价可视化分析系统(源码+数据库+文档)"，就是我实际帮人做过、也反复改造过的一套方案。它适合数据库课程设计、Python全栈实训、毕业设计，也适合想给自己简历凑一个完整项目的初学者。如果你正好在纠结"比价平台到底怎么搭"，这篇文章可以帮你少走很多弯路。

我在拿到类似的题目时，第一步从来都不是打开IDE写代码，而是先把思路理顺。很多同学交上来的系统看着功能齐全，一演示就露馅：要么数据是写死的，要么只连了一张表，要么图表压根不更新。真正能扛住老师追问的比价系统，至少要回答清楚三个问题——价格从哪来、怎么比、结果怎么呈现。这篇文章就围绕这三条线，把整个系统的技术选型、数据库设计、核心功能实现，以及我踩坑最多的地方一次讲透。

1. 别急着写代码：先想清楚比价系统到底是在做什么

1.1 电商比价系统的本质需求拆解

电商比价系统，表面上是一个"搜索商品、展示不同平台价格"的网站，但落到开发层面，它的核心链路其实很清晰：数据采集层——把商品信息和价格拿到手；数据存储层——设计合理的表结构把数据存进去；业务处理层——实现查询、排序、筛选、价格对比等逻辑；展示层——用可视化图表把分析结果呈现给用户。

如果把"比价系统"当成一个数据库课程设计来交，那么数据库建模和SQL设计就是绝对的主线。如果你是想往Python全栈方向走，那Flask接口开发、模板渲染、前后端交互就是重点。每个同学的目标不一样，系统设计的侧重点也应该不一样。我最怕的就是一上来就抄一个"大而全"的购物网站代码，最后页面上几十个板块，数据库十几张表，但每一块都讲不清楚，答辩时被老师一句"这个外键为什么这么设计"问得哑口无言。

所以我在设计这套系统时，刻意做了"范围内收敛"：不做用户注册登录的花哨功能（顶多留一张user表），不接第三方支付，不搞购物车，所有功能都围绕"商品—平台—价格—趋势"这四件事打转。这样既能把核心业务做透，又不会把自己拖入无底洞。

1.2 功能范围与模块划分

真正动手前，我习惯先画一张功能清单，把系统切成几个清晰的模块。这套系统的功能可以划分为四个模块：

• 数据管理模块：负责商品信息的维护，包括商品名称、分类、品牌、图片链接、商品链接等基础字段。这个模块一般做成后台管理页面，提供商品的新增、编辑、删除和批量导入功能。
• 价格数据模块：维护同一商品在不同平台的售价、促销价、上下架状态。比价系统的生命力就在这张价格表里，它是价格对比和历史趋势分析的直接数据来源。
• 比价与查询模块：用户输入商品关键词，系统从数据库检索商品，并按照"同一商品在不同平台的价格对比"的方式展示结果，支持按价格排序、按平台筛选。
• 可视化分析模块：将价格对比结果转化为折线图、柱状图、雷达图，还可以做成大屏展示形式，直观反映价格波动趋势、平台价格分布和优惠力度对比。

这里要特别提醒一点：功能切块的时候，最好让每个模块都能独立演示。答辩时如果有突发状况，比如管理员页面挂了，你至少还能进普通用户页面把比价图表展示一遍。这个"最小可演示闭环"思路，是我多次答辩现场总结出来的保命策略。

2. 为什么是Python + Flask：这套技术栈到底赢在哪

2.1 Flask对比Django和Spring Boot，我为什么选它

"电商系统"这三个字一出来，很多人的第一反应是Spring Boot，第二反应是Django。但实际在课程设计和毕设场景里，Flask反而是一个被低估的选择。我来说说我的理由。

做一个简单的技术对比：

Flask最打动我的一点是"从零到一"的路径特别短。你可以先用一个app.py把路由建起来，跑通了再加数据库，再引SQLAlchemy，再上ECharts。每一步都是增量式的，对于要赶论文、赶进度的同学来说，这种"边写边学边交付"的模式非常舒服。Django的问题在于它太"完整"了，很多功能你还没搞明白原理，框架就替你做了，答辩时很容易被"那你讲讲Django内置的Admin是怎么自动生成的"这种问题卡住。

至于Spring Boot，不是说它不好，而是如果你没有Java基础，在毕设周期里去补Spring的IOC、AOP、MyBatis映射，成本实在太高。而Python本身的语法简单，加上Flask的路由和视图函数非常直白，哪怕是第一次接触Web开发的同学，看完一小节示例代码就能把第一个页面跑起来，这种"快速正反馈"对坚持做完项目是有重要作用的。

2.2 数据可视化组件：ECharts和pandas的黄金组合

比价分析要好看，图表环节是重中之重。我的首选是ECharts，原因有两点：一是对国内开发者极其友好，中文文档完善，示例丰富，几乎你能想到的图表类型都有现成demo；二是它纯前端渲染，后台只需要提供一个JSON数据接口，这对Flask来说几乎没有压力。

后端配一杯pandas，数据处理会舒服很多。比如你查询某商品在所有平台的历史价格，SQL查出来的结果可能是几十行原始记录，直接用ECharts渲染会有点麻烦，但用pandas透视一下，把"日期"变成索引、把"平台"变成列，一行代码就能生成前端要的二维结构。然后再用df.to_dict(orient='records')转成列表字典，直接丢到接口里，前端拿过来就能用，中间省掉大量手工拼JSON的操作。

还有一个很实用的点：pandas还能做数据清洗。爬虫采集或手工导入的数据里常常有"价格带人民币符号"、"数字存成了字符串"、"存在空值"这类脏数据，用pandas统一处理会比写循环快很多，也少掉很多坑。我在这个项目里就写了一个数据清洗函数，专门处理价格字段的归一化，后面还会提到。

3. 数据库设计：比价系统的灵魂其实在表结构里

3.1 核心表结构：商品表、平台表、价格记录表

无论你接不接ORM，数据库都是这套系统的地基。我正式开发前一定会先把表结构设计稿画好，画到字段级别，才允许自己写代码。这里我给出一套经过实际检验的表设计方案，大家可以直接拿去改造。

第一张是商品表（product），核心字段如下：

• id：主键，自增
• name：商品名称，比如"iPhone 15 Pro 128G 原色钛金属"
• category：商品分类，方便漏斗式筛选
• brand：品牌
• product_url：商品详情页链接
• cover_url：商品主图链接
• created_at：记录创建时间

第二张是平台表（platform），也就是比价的基本维度：

• id
• platform_name：平台名称，比如"京东"、"天猫"、"拼多多"
• platform_url：平台官网地址
• logo_url：平台图标，前端展示用

第三张是价格记录表（price_record），这是整个系统里数据量最大、也是最有分析价值的表：

• id
• product_id：外键，关联商品表
• platform_id：外键，关联平台表
• price：售价，decimal(10,2)
• original_price：原价/划线价，用来算折扣力度
• discount：折扣率，比如0.85代表85折，可以在插入数据时通过原价和售价计算
• stock_status：库存状态，有货/无货
• crawl_time / record_date：价格快照时间，历史趋势分析全靠这个字段

如果你还想做用户功能，可以再加一张user表和一张收藏表，但我的建议是先把上面这三张表的逻辑打通，再考虑外围功能。很多同学一上来就建了七八张表，最后光是写插入数据的逻辑就累到崩溃。

3.2 为什么要用外键，以及什么时候可以不用

数据库课设要拿高分，外键和索引是绕不开的话题。从数据完整性角度，price_record表的product_id和platform_id都应该设置外键约束，确保不会出现"价格记录指向一个不存在的商品"这种脏数据。

但是，在实际演示系统里，我倾向于把外键和ORM关系声明配合使用，而不是完全依赖数据库级的外键约束。原因是：当你用SQLAlchemy的db.relationship定义好关系后，查询时可以直接用product.price_records这样的方式取数据，非常方便。而数据库级外键如果建得太死，做批量删除或数据导入的时候反而会频繁报错，比如"Cannot delete or update a parent row: a foreign key constraint fails"。对演示项目来说，这种报错毫无收益，只会增加紧张感。

我推荐的折中方案是：表设计文档里完整画出外键关系，代码中用ORM层面的relationship来表达关联，但SQL脚本里的外键约束可以按需保留——建议保留，因为数据库课设需要展示规范化程度。如果担心删除时报错，可以设置ondelete='CASCADE'，这样删除商品时会自动删除其价格记录，逻辑更顺，也让答辩时的演示更流畅。

3.3 数据从哪来：采集、模拟与手工导入的平衡

比价系统永远绕不开"数据从哪弄"的问题。很多同学第一反应是去爬京东、爬淘宝，但这里有两个现实问题：一是高频爬虫容易被封，二是电商平台的页面结构经常变，今天能跑的选择器，明天就可能失效。

我在这套系统里做了三种数据来源并存的设计。第一种是模拟数据生成器，写一个Python脚本，用商品名列表、平台列表、价格区间、日期范围自动生成几百条价格记录，覆盖近30天甚至近半年的历史趋势。这种方式非常适合开发阶段测试图表效果，你不需要等爬虫慢慢跑，随时都有数据可用。第二种是外部公开数据导入，比如从一些提供开放数据集的平台下载CSV，清洗后导入MySQL。第三种才是真正写爬虫去采集特定商品的价格快照，但只采集少量、低频、合法允许的数据，同时设置好User-Agent和请求间隔，避免给目标服务器造成负担。

实际使用中，我强烈建议开发阶段以模拟数据为主，等所有功能都调通了，再写一个crawler.py按需采集真实数据。这样既保证演示时数据丰富，又不会把自己卡在爬虫调试的无底洞里。很多同学做这类项目最后烂尾，都是因为一开始就去折腾爬虫，结果真实数据没搞定，系统也没搭出来。

4. 核心功能落地：从数据库到可视化大屏的完整链路

4.1 Flask项目结构与蓝图的规划

一个"可以用"的Flask项目，项目结构一定不能太乱。我常用的结构是这样：

code复制flask_bijia/
├── app.py                 # Flask入口文件
├── config.py              # 配置数据库连接、密钥等
├── requirements.txt       # 依赖包列表
├── models/
│   ├── __init__.py
│   ├── product.py         # 商品模型
│   ├── platform.py        # 平台模型
│   └── price_record.py    # 价格记录模型
├── routes/
│   ├── __init__.py
│   ├── product_routes.py  # 商品相关接口
│   ├── analyze_routes.py  # 比价分析接口
│   └── user_routes.py     # 用户相关接口（可选）
├── static/
│   ├── css/
│   ├── js/
│   └── images/
├── templates/
│   ├── index.html         # 首页
│   ├── product_list.html  # 商品列表页
│   ├── compare.html       # 比价详情页
│   └── dashboard.html     # 可视化大屏页
├── scripts/
│   ├── init_db.py         # 初始化数据库脚本
│   ├── generate_data.py   # 模拟数据生成器
│   └── crawler.py         # 数据采集脚本
└── docs/
    ├── 需求文档.md
    ├── 数据库设计文档.md
    └── 操作手册.md

这个结构对于课程设计和毕业设计来说，足够清晰，又不至于过度工程化。Blueprints（蓝图）的好处是让路由函数按业务域拆分，不把所有接口堆在一个app.py里。如果项目比较小，你可以先不拆蓝图，但养成用蓝图的习惯会让你在后面加模块时省下大量时间。

4.2 数据库接入：SQLAlchemy还是原生SQL

这其实是个"答辩友好度"和"开发效率"的权衡问题。如果你希望代码看起来更有工程感，选SQLAlchemy。它让你用Python类的方式定义表结构，迁移和查询都更灵活。如果你希望代码更透明、更容易在论文里贴出"可见的SQL语句"支撑你的数据库设计章节，那你用原生SQL配合pymysql，每一条增删改查都能明明白白展示出来。

我的做法是两者结合：ORM用来做常规CRUD，复杂的统计查询直接用db.session.execute(text(...))写原生SQL。以"查询某商品最近30天在各平台的每日均价"为例，原生SQL比ORM组合更直观：

sql复制SELECT date(record_date) AS day, platform_name, AVG(price) AS avg_price
FROM price_record pr
JOIN platform pf ON pr.platform_id = pf.id
WHERE pr.product_id = 1
  AND record_date >= DATE_SUB(CURDATE(), INTERVAL 30 DAY)
GROUP BY day, platform_name
ORDER BY day;

把这条SQL放到Flask的查询接口里，返回前端一个二维数组，用ECharts画三根折线（三个平台的价格趋势），效果非常直观，答辩时也很有说服力。

4.3 开发第一个比价接口：以价格对比接口为例

真正的核心不是"能返回JSON"，而是"接口设计得能不能直接支撑前端展示"。我设计比价接口时会这样规划：

• GET /api/products?keyword=手机：根据关键词模糊搜索商品列表，返回商品ID、名称、最低价、均价、平台数。
• GET /api/compare?product_id=1：返回该商品在所有平台的当前价格、折扣率、库存状态，按价格升序排列。
• GET /api/trend?product_id=1&days=30：返回该商品近期在各平台的价格历史趋势数据。
• GET /api/dashboard/summary：返回可视化大屏所需的统计数据，比如今日采集商品总数、参与平台数、平均折扣率、价格波动Top10商品等。

以第二个接口为例，实际的Flask视图函数思路是：先从price_record表查出每个平台最新一条价格记录，再关联商品表和平台表。

python复制@app.route('/api/compare')
def compare():
    product_id = request.args.get('product_id', type=int)
    if not product_id:
        return jsonify(code=400, msg='缺少商品ID参数'), 400

    sql = '''
        SELECT p.name AS product_name,
               pf.platform_name,
               pr.price,
               pr.original_price,
               pr.discount,
               pr.stock_status,
               pr.record_date
        FROM price_record pr
        JOIN product p ON pr.product_id = p.id
        JOIN platform pf ON pr.platform_id = pf.id
        WHERE pr.product_id = %s
          AND pr.record_date = (
              SELECT MAX(record_date)
              FROM price_record
              WHERE product_id = %s AND platform_id = pr.platform_id
          )
        ORDER BY pr.price ASC
    '''
    data = db.session.execute(text(sql), (product_id, product_id)).fetchall()
    result = [dict(row) for row in data]
    return jsonify(code=0, msg='success', data=result)

这段代码的关键点在于用了子查询筛出每个平台上"最新"的一条记录。很多新手会直接查所有记录再在Python里过滤，结果随数据量增大，接口越来越慢，答辩时等待时间会长到尴尬。能用一条SQL解决的问题，尽量别拿到业务代码里用循环处理，这是我反复强调的一个原则。

4.4 可视化页面：ECharts和Flask模板的结合

可视化页面的实现方式有两种：一种是用Flask的模板渲染，把图表参数作为模板变量传过去，适合简单场景；另一种是前后端分离，Flask只提供JSON接口，前端用AJAX拉数据渲染图表。我更推荐第二种，因为课程设计和毕设答辩时，你可以在浏览器地址栏直接输入接口地址展示JSON数据，证明"后台逻辑是真的"，再切到可视化页面展示"前端是真的在调接口"，演示效果很加分。

在compare.html页面里，用ECharts的基本写法是这样的：

javascript复制fetch('/api/compare?product_id=1')
  .then(response => response.json())
  .then(data => {
    const platforms = data.data.map(item => item.platform_name);
    const prices = data.data.map(item => item.price);
    const chart = echarts.init(document.getElementById('barChart'));
    chart.setOption({
      title: { text: '各平台当前价格对比' },
      tooltip: {},
      xAxis: { type: 'category', data: platforms },
      yAxis: { type: 'value', name: '价格（元）' },
      series: [{
        name: '售价',
        type: 'bar',
        data: prices,
        itemStyle: { color: '#3b82f6' }
      }]
    });
  });

用fetch从后端拿JSON再渲染，逻辑清晰，也方便你调试。如果你嫌手写JS麻烦，ECharts官方示例里几乎有现成的图表配置，复制过来改改数据源就行，这也是我开发时效率最高的一种方式。

大屏展示的话，可以用ECharts的多个图表实例拼一个HTML页面，顶部放统计数字卡片，中间放价格趋势折线图，两侧放平台价格分布饼图和折扣力度排名柱状图。注意大屏页面不要做太复杂的交互，尽量一打开就能看到完整信息，这样演示时放在投影上效果最好。

4.5 数据库脚本与初始化流程

配套的数据库脚本是整个项目"可复现"的关键。我建议把init_db.py做成一个可重复执行的脚本，逻辑是：先连接MySQL，创建数据库（如果不存在），然后导入表结构SQL，最后导入模拟数据。这样别人拿到你的源码后，只要安装了Python和MySQL，敲一条命令就能把环境跑起来。

python复制# init_db.py
# -*- coding: utf-8 -*-
import pymysql
from sqlalchemy import create_engine, text

db_config = {
    'host': 'localhost',
    'user': 'root',
    'password': '123456',
    'charset': 'utf8mb4'
}
database_name = 'bijia_db'

# 1. 创建数据库
conn = pymysql.connect(**db_config)
cursor = conn.cursor()
cursor.execute(f"CREATE DATABASE IF NOT EXISTS {database_name} DEFAULT CHARACTER SET utf8mb4")
conn.commit()
cursor.close()
conn.close()

# 2. 执行表结构脚本
engine = create_engine(f"mysql+pymysql://root:123456@localhost:3306/{database_name}?charset=utf8mb4")
with engine.begin() as conn:
    with open('scripts/schema.sql', 'r', encoding='utf-8') as f:
        conn.execute(text(f.read()))

print("数据库初始化完成")

特别需要提醒的是：创建数据库的时候一定要指定DEFAULT CHARACTER SET utf8mb4。如果建表时没有设置字符集，后续插入中文商品名时非常容易遇到"Unknown character"或者"?????"乱码问题。这一点我在下面"常见问题"里还会专门展开。

4.6 项目文档到底怎么写不踩雷

一个比价系统要"交付完整"，文档的重要性不亚于代码。我一般会准备三份文档：需求文档、数据库设计文档、操作手册。

需求文档重点写清项目背景、用户角色、功能模块和系统流程图。数据库设计文档要包含ER图、每张表的字段说明、表间关系说明，还有外键约束和索引设计。操作手册则是写给答辩老师和后续维护者看的，写清楚怎么配置环境、怎么初始化数据库、怎么启动项目、有哪些关键接口和测试数据。

写文档时有一个小技巧：每个接口都配上请求示例和返回示例，哪怕只是两三行JSON，也能让阅读者快速理解系统的工作方式。在答辩时，很多老师不会真的花时间看代码，他们更愿意翻文档了解你的设计思路。文档写得规范，第一印象分就会高很多。

5. 常见问题与排查技巧：这些坑我基本都踩过

5.1 数据库连接失败的几大原因

数据库连接报错的概率在我辅导的项目里非常高，最常见的报错信息是Can't connect to MySQL server或Access denied for user。前者通常是MySQL服务没启动、或者端口不是默认的3306，后者要么是密码错误，要么是远程连接权限没开。最简单的排查方法：先在命令行里用mysql -u root -p试一下，看能不能连上，能连上再检查代码里的host、port、user、password是否对应。

还有一个非常隐蔽的问题是Flask应用里数据库URI写成了localhost，而MySQL监听的是127.0.0.1，某些系统环境下两者解析不一致会导致连接超时。解决思路是统一使用127.0.0.1，别在配置文件里一会儿localhost一会儿127.0.0.1。

5.2 中文乱码问题

中文乱码在Flask + MySQL项目里太经典了。归纳起来主要有三个层面的原因：

• 数据库层面：表或字段不是utf8mb4编码。
• 连接层面：数据库连接串没有带charset=utf8mb4参数。
• 页面层面：HTML没有声明<meta charset="utf-8">，或者响应头Content-Type没有指定charset。

我之前遇到过一次奇怪的情况：数据库中存储的中文是正常的，接口返回JSON时也正常，但浏览器页面就是乱码。最后发现是模板文件本身保存成了GBK编码，HTML里声明的却是utf-8。解决方式是把所有模板和Python源文件统一用UTF-8保存，并且别在Windows记事本默认编码下编辑文件。这里的核心经验是：凡是涉及中文的项目，把"统一编码"当成一条铁律，数据库用utf8mb4，代码文件存UTF-8，连接串带charset=utf8mb4，HTML声明utf-8，四个点做到，乱码基本不会出现。

5.3 ECharts图表不显示的排查思路

ECharts图表空白不显示，这也是高频问题。我自己总结了一套排查顺序：

1. 控制台报不报错？如果报Cannot read properties of undefined，通常是因为JSON数据结构跟前端预期对不上，比如前端访问data.data，而接口返回的字段名不是这个。
2. 容器高度是否为0？ECharts图表的父容器必须有明确高度，div的height设置为0或未设置时，图表会静默失败，页面上看起来就是一片空白。
3. 数据是否为空数组？检查接口返回的数据条数，如果数据库里没有对应商品的价格记录，图表自然没有内容。
4. 是否重复初始化了同一个DOM节点？重复echarts.init会报There is a chart instance already initialized on the dom，最好先echarts.dispose再重新init，或者复用同一个实例。

我见过一个同学花了一晚上调试"为什么柱状图不出来"，最后发现只是外层的CSS里设置了一个display: none，初始化的时候容器是隐藏的，图表生成时宽度高度全是0。这个坑很隐蔽，把初始化时机放到DOM完全显示之后就能解决。

5.4 Flask启动端口与模板路径问题

Flask默认跑在5000端口，如果你电脑上已经有一个服务占用了这个端口，启动时就报Address already in use。解决方法是换端口：

bash复制python app.py --port=5001

或者在代码里写：

python复制if __name__ == '__main__':
    app.run(host='0.0.0.0', port=5001, debug=True)

模板路径问题是另一个常见坑。记得一定把HTML文件放在templates目录下，静态文件（CSS/JS/图片）放在static目录下，不要自己拼绝对路径。Flask的render_template('compare.html')会自动去templates目录找文件，如果你把模板放在templates/pages/这样的子目录下，调用时就要写render_template('pages/compare.html')。很多同学把模板文件放错层级后一直报TemplateNotFound，其实就是路径没对上。

5.5 数据量不大但查询很慢？

很多比价系统Demo的数据量根本不大，几千条记录而已，但查询却会慢到令人发指，每次接口请求都要两三秒。问题十有八九出在查询写法上——不是没用索引，就是查询时写了类似WHERE product_name LIKE '%手机%'这样的模糊匹配，而字段上又没有建索引。

针对比价场景，我会在price_record表的product_id、platform_id、record_date三个字段上建联合索引：

sql复制CREATE INDEX idx_product_time ON price_record(product_id, record_date);

这个索引对"查询某商品在时间范围内的价格"这个高频操作非常有效。另外，如果查询确实需要模糊搜索商品名，可以给product.name加上普通索引，虽然LIKE '%xx%'用不上常规索引优化（左前缀模糊会让索引失效），但在数据量不大的情况下，有索引总比没索引好，而且可以显示出你的索引设计意识。

6. 源码、数据库和文档怎么组合交付才有价值

6.1 拿到源码后如何快速跑起来

如果你是拿到这套源码的学习者，第一件事不是立刻去看业务代码，而是先确认环境。该装的东西有：Python 3.8以上版本，MySQL 5.7以上或8.0，以及pip依赖包。有一个常用命令可以快速安装依赖：

bash复制pip install -r requirements.txt

requirements.txt 里建议把版本号锁定，比如Flask==3.0.0、SQLAlchemy==2.0.25、pymysql==1.1.0、pandas==2.2.0，避免之后版本升级导致不兼容。然后是修改config.py里的数据库账号密码，再执行python scripts/init_db.py初始化数据库，最后在项目根目录运行：

bash复制python app.py

浏览器打开http://127.0.0.1:5000就能看到首页。如果首页是空白，优先看控制台日志，是不是数据库没连上、端口被占、模板找不到，排查顺序可以参照前面5.4节的内容。

6.2 源码阅读的建议顺序

拿到别人的源码后，我一般建议按"入口—配置—模型—路由—模板—脚本"的顺序读。先看app.py知道项目从哪启动，再看config.py知道数据库怎么连的，然后看models了解表结构对应关系，接着看routes了解有哪些接口，最后看templates了解前端怎么渲染。不要一开始就闷头读某个Python文件，那样很容易陷入细节，半天看不出项目全貌。

很多同学担心"源码用了SQLAlchemy我不熟怎么办"，其实不必慌。你只要抓住几个规律：模型类对应数据库表，视图函数对应请求接口，模板对应页面展示，三者之间通过"查询数据—返回—渲染"这条线串起来。把这条主链路打通，剩下的细节都可以按需查阅。

6.3 基于这个项目还可以怎么扩展

如果时间充裕，想让这个比价系统在简历或答辩里更有亮点，有几个低成本的扩展方向：

• 加一个价格预警功能：用户设置目标价格，系统定期（或每次数据更新时）检查价格记录，一旦跌破目标线就发站内信或邮件提醒。这就牵扯到定时任务、后台队列，很能体现工程能力。
• 加一个平台价格分布地图：按商品分类统计各平台的价格平均值，用热力图或者地图展示价格差异，视觉冲击力很强。
• 加一个历史价格区间筛选器：用户设定价格区间，系统从历史记录里找出"什么时候买到过这个价"，实现更精细的比价。
• 把模拟数据生成器改成可配置化：支持自定义商品列表、平台列表、价格浮动规则和时间范围，方便你快速演示不同场景。

每加一个功能，都是在给答辩加分。但前提是核心链路已经稳定，不要在基础没打牢的时候盲目堆功能。

7. 最后再分享一点我个人的实际体会

比价系统这类项目，做一遍的收获真的比想象中大。它不像纯算法题那样抽象，也不像纯前端页面那样单薄，它逼着你同时去处理数据格式、数据库约束、接口约定、页面渲染和部署环境这些小而杂的问题。以前我总觉得"写代码"是最费时间的环节，做得多了才发现，真正决定项目成败的其实是代码之外的那些事——表结构设计得好不好、接口返回格式是否稳定、文档有没有把环境交代清楚。

我现在每接到一个类似的项目，都会先花半天把数据库脚本和文档框架搭好，再开始写路由和页面。这个习惯救了我很多次。因为如果数据库设计从一开始就是乱的，后面改表字段、改查询逻辑、改前端数据结构的成本会成倍放大。反过来，当表结构和接口约定都稳了，后面的开发基本就是"填空"，把一个个视图函数填满、把一个个图表配置调好，系统自然就完整了。

这套方案的源码、数据库脚本和文档我一直保持着同步更新，如果你正在做类似的课程设计或毕业设计，可以直接拿这个作为起点，在上面做自己的二次开发。别把它当"作业答案"抄一遍就交，最好能自己动手把数据库表建一遍、把比价接口写一遍、再给可视化页面调一个不一样的配色。等你真正跑通了第一版，你会发现自己对Python、Flask、MySQL和可视化这几个关键词的理解，已经不像刚开始时那么虚了。