1. 为什么选"图书零售监测系统"当毕业设计：一个过来人的选题复盘
每年到了毕业设计选题季，计算机专业的同学都会陷入一种循环：打开知网和百度，搜"python毕业设计题目"，翻到第三页开始眼花，最后要么选了个烂大街的"学生管理系统"，要么选了个自己都说不清业务逻辑的"智能推荐系统"。我见过太多人栽在选题这一步——题目要么太大，做到一半发现根本撑不起来，要么太小，答辩时被老师三句话问穿。
图书零售监测系统这个题目，在毕业设计的维度里属于"性价比极高"的那一档。它既不是那种一个人两个月做不完的复杂分布式系统，也不是那种一页PPT就能讲完的玩具项目。它背后有一个真实存在的行业需求：图书零售企业需要搞清楚哪些书卖得好、哪些门店贡献了主要营收、库存周转是否健康、不同品类的销售趋势怎么变化。这些需求落到技术上，就是一套典型的数据采集、存储、处理、可视化的完整链路，恰好能把Python生态里最常用的几个方向都串起来。
我辅导过不少学弟学妹做类似的系统，自己也完整跟过一遍从需求分析到答辩的全过程。这套系统能锻炼的核心能力在于：它需要你设计合理的数据表结构，需要你处理真实场景中的脏数据，需要你写清楚统计查询的逻辑，还需要你把结果用图表直观地展示出来。这些能力不是背八股文能练出来的，而是实打实要动手调出来的。如果你现在正愁毕业设计选什么题，或者已经被导师指定了这个方向但还没头绪，这篇文章就是按我自己的实操路径给你梳理的完整参考。
2. 需求拆解与系统架构：先想清楚要做什么，再动手写代码
2.1 图书零售监测到底在监测什么
在做任何毕设之前，第一件事不是装环境，而是把业务需求搞清楚。图书零售监测系统的核心服务对象是书店运营管理人员，他们要回答的问题无非这么几类：
- 销售大盘：今天/本周/本月全渠道卖了多少册、多少码洋（也就是销售金额），环比上周是涨还是跌。
- 畅销排行：哪些书是真正的爆品，哪些书只是在小范围人群里口碑好但走量一般。
- 库存健康：哪些书库存告急需要补货，哪些书积压严重需要做促销清仓。
- 门店对比：不同门店、不同区域的销售能力差异在哪，是否需要调整配货策略。
- 品类趋势：文学类、社科类、少儿类、教辅类各自的销售走势，谁在增长谁在下滑。
把这些需求翻译成系统功能，就得出一张模块清单：数据采集模块（怎么把销售记录弄进系统）、数据管理模块（图书信息、门店信息、库存信息的基本维护）、统计分析模块（各种维度汇总）、可视化大屏模块（图表展示）、系统管理模块（登录、权限）。
很多同学拿到这个题目后会犯一个毛病：上来就写代码，写到一半发现数据库表设计不合理，又回头改表结构，折腾两三轮之后时间全浪费了。正确的做法是把上面这些业务问题先写成需求清单，逐条对应到功能点，再开始设计数据库。这一步看起来不起眼，但能让你后面的开发效率翻倍。
2.2 技术选型：Flask还是Django，MySQL还是SQLite
技术选型是毕业设计里被问得最多的问题。对于图书零售监测系统，主流的搭配有两种，我分别说下适用场景。
方案一：Flask + SQLite + ECharts
这是我自己建议大多数同学用的组合。Flask足够轻量，对于监测系统这种以查询和展示为主、没有复杂权限模型的场景，写起来非常顺手。SQLite作为文件型数据库，零配置、免安装，把数据库文件拷走就能迁移，在毕业设计演示环节特别省心——不用像MySQL那样在答辩教室还要折腾服务能不能起来。前端可视化用ECharts，它是目前国内做数据图表最成熟的库，对中文文档和示例的支持都非常完善。
方案二：Django + MySQL + ECharts
如果你本身对Django比较熟悉，或者导师要求必须用MySQL，这套组合也没问题。Django自带Admin后台，做图书信息维护页面几乎不用自己写代码。MySQL在数据量上来之后的查询性能确实更好，但代价是需要额外安装配置数据库服务，答辩现场出问题的概率更高。
提示：如果你的毕业设计是面向"药店零售监测""超市零售监测"这类同构题目，完全可以复用下面这套设计与代码逻辑，只把业务字段换掉（例如把ISBN换成药品批准文号，把图书分类换成药品分类）即可。但千万不要原封不动照搬，至少要把系统名称、界面文案、业务语义全面改掉，否则查重和导师关都过不去。我的建议是：除非导师明确指定技术栈，否则优先选Flask + SQLite。原因很朴素——你的时间应该花在把业务逻辑写清楚、把图表做得好看上，而不是花在跟数据库环境搏斗上。
2.3 数据库设计：六张核心表搞定全部业务
图书零售监测系统的数据库设计是整篇论文里占比很大的一块。我按实际开发经验给你梳理一套完整的数据表结构，覆盖最常见的业务需求。
第一张是图书信息表（book）。字段包括：id、isbn（国际标准书号）、book_name（书名）、author（作者）、publisher（出版社）、category（图书分类）、price（定价）、stock（当前库存）、safety_stock（安全库存下限）、create_time。这里有两个容易忽略的细节：ISBN虽然是图书的"身份证号"，但实际业务中可能存在同一本书不同版本共用一个ISBN号的情况，所以最好单独设一个自增主键id，ISBN只做检索条件不做主键；库存字段冗余在图书表里是为了查询方便，但真正的进出库流水应该单独记录在库存变动表里。
第二张是门店信息表（store）。字段：id、store_name（门店名称）、store_code（门店编号）、region（所在区域）、address（地址）、manager（店长姓名）、phone（联系电话）。如果做的是线上线下一体化的图书零售场景，可以增设store_type字段区分线上渠道（如"官网商城""第三方平台旗舰店"）和线下实体门店，后续做渠道对比分析时直接用这个字段分组即可。
第三张是销售记录表（sales_record）。这是全系统数据量最大、也是最重要的一张表。字段：id、order_no（订单号）、book_id（关联图书表）、store_id（关联门店表）、sale_quantity（销售数量）、sale_price（成交单价）、sale_amount（成交金额）、sale_date（销售日期）、sale_time（具体销售时间点）。设计这张表时有几个关键决策需要提前想清楚。要不要冗余store_id和book_id之外的名称字段？我的建议是：为了报表查询效率，可以在流水表里冗余存储book_name和store_name，这叫空间换时间，在很多监测系统里都是常规做法。日期和时间分两个字段存的好处是，做"按日汇总"和"按时段分析"都很方便，不用在SQL里做字符串截取。
第四张是进货记录表（purchase_record）。字段：id、purchase_no（进货单号）、book_id、store_id、quantity（进货数量）、purchase_price（进货单价）、purchase_date（进货日期）。这张表配合销售表和库存表，能算出一本书在某个时间区间内的进货量、销量和库存变化，是库存预警功能的底层数据来源。
第五张是库存变动表（stock_log）。字段：id、book_id、store_id、change_type（变动类型：入库/出库/退货/盘点调整）、change_quantity（变动数量，正负号区分方向）、change_time、operator（操作人）。很多同学做图书监测系统时会把这张表省略掉，只保留图书表里的一个库存数字。这样做的代价是：一旦库存数据不对，你完全没法追溯是哪里出了问题。加了流水日志，所有变动有迹可查，论文里也能多写一个"系统设计考虑到了数据可追溯性"的亮点。
第六张是用户表（user）。字段：id、username、password（记得存加密后的密文，别存明文）、role（角色：管理员/普通运营）、real_name、last_login_time。
这六张表之间的关系不复杂：销售记录和进货记录都关联图书和门店，库存变动记录同样关联两者，用户表独立存在做权限控制。用SQL外键还是不用外键？毕设层面建议在表结构设计图里画上外键关系，但在实际建表时可以不加物理外键，只在代码层做逻辑关联。这样演示删数据时不会被外键约束卡住，论文里还能写一句"考虑到系统性能与扩展性，采用逻辑外键设计"。
2.4 项目目录结构：从第一天就保持整洁
一个干净的项目目录结构，不仅让你自己写代码的时候不迷路，答辩时老师看你的代码仓库也会留下好印象。我常用的结构是这样的：
book_retail_monitor/ ├── app.py # Flask应用入口 ├── config.py # 配置信息（数据库路径、密钥等） ├── requirements.txt # 依赖列表 ├── models/ │ ├── __init__.py │ ├── book.py # 图书模型 │ ├── store.py # 门店模型 │ ├── sale.py # 销售记录模型 │ └── user.py # 用户模型 ├── routes/ │ ├── __init__.py │ ├── dashboard.py # 监测大屏路由 │ ├── book_api.py # 图书管理接口 │ ├── sale_api.py # 销售管理接口 │ └── auth.py # 登录认证接口 ├── utils/ │ ├── __init__.py │ ├── db.py # 数据库连接工具 │ ├── response.py # 统一响应格式 │ └── auth_decorator.py # 登录校验装饰器 ├── static/ │ ├── css/ │ ├── js/ │ └── assets/ ├── templates/ │ ├── base.html │ ├── login.html │ ├── dashboard.html │ └── ... └── data/ └── book_retail.db # SQLite数据库文件这个结构把模型、路由、工具函数分开，每一层各司其职。哪怕你最终的代码量不大，这种分层组织方式也会让代码看起来专业很多。更重要的是，后续要加新功能时——比如从销售记录里做回归分析预测下个月销量——你只需要在routes里加一个文件，在templates里加一个页面，不会动不动就改到主文件。
3. 核心功能模块的实现：从数据录入到可视化大屏
3.1 数据从哪来：三种采集方式的取舍
系统做出来得要有数据演示，这是很多同学在开发中期才意识到的大坑。图书销售数据的来源，根据你的毕设定位有三种选择。
第一种是手动录入 + Excel导入。系统提供表单让运营人员逐条录入销售记录，也提供Excel批量导入功能。这是最稳妥的做法，因为生成测试数据的逻辑完全可控。建议用Python的openpyxl库写一个批量导入函数，支持读取指定格式的Excel表格，逐行校验后写入数据库。
第二种是爬虫抓取。如果你想在论文里体现爬虫技术，可以写一个爬虫抓取公开图书网站的销量排行数据，但这里面有法律和道德风险——抓取公开的排行榜数据用于学习研究问题不大，但要注意遵守目标网站的robots协议，控制请求频率，不要抓取用户隐私数据。如果不是导师特别要求，我不建议在毕设里重点搞爬虫，因为这将花掉你大量调试反爬机制的时间。
第三种是模拟数据生成器。写一个Python脚本，随机生成近半年的销售记录、进货记录数据。这是我个人强烈推荐的方式——用random模块控制图书销量符合"长尾分布"（少数头部书贡献大部分销量），这样生成的折线图和柱状图看起来才真实，答辩演示的效果远比均匀分布的数据好。
我的做法是三种结合：先写模拟数据生成器灌入半年数据，再留一个Excel导入入口作为功能展示，爬虫部分只在论文里作为"后续扩展方向"提及。这样你既不用在爬虫调试上耗费时间，功能点也足够齐全。
以下是模拟数据生成器的核心片段，用来生成符合"头部畅销、长尾平销"规律的销售数据：
import random import sqlite3 from datetime import datetime, timedelta def generate_sales_data(db_path, days=180, max_records_per_day=80): conn = sqlite3.connect(db_path) cursor = conn.cursor() # 获取所有图书和门店 books = cursor.execute("SELECT id FROM book").fetchall() stores = cursor.execute("SELECT id FROM store").fetchall() # 给每本书设置一个"畅销权重"，畅销书被随机选中的概率更高 book_weight = {book[0]: random.random() ** 2 for book in books} total_weight = sum(book_weight.values()) start_date = datetime.now() - timedelta(days=days) for day_offset in range(days): current_date = start_date + timedelta(days=day_offset) daily_records = random.randint(int(max_records_per_day * 0.4), max_records_per_day) for _ in range(daily_records): book_id = weighted_choice(book_weight, total_weight) store_id = random.choice(stores)[0] quantity = 1 if random.random() < 0.3 else random.randint(1, 5) price = cursor.execute( "SELECT price FROM book WHERE id = ?", (book_id,) ).fetchone()[0] sale_time = current_date + timedelta( minutes=random.randint(0, 1439) ) cursor.execute( """INSERT INTO sales_record (order_no, book_id, store_id, sale_quantity, sale_price, sale_amount, sale_date, sale_time) VALUES (?, ?, ?, ?, ?, ?, ?, ?)""", ( f"SO{current_date.strftime('%Y%m%d')}{random.randint(1000, 9999)}", book_id, store_id, quantity, price, round(quantity * price, 2), current_date.strftime("%Y-%m-%d"), sale_time.strftime("%H:%M:%S"), ) ) conn.commit() conn.close()需要注意的是，生成数据时要把quantity * price计算好之后存到sale_amount字段里，不要等着在图表渲染时才去乘，这样SQL查询简单很多，图表加载速度也更快。
3.2 监测大屏：把数据变成一张能"讲故事"的页面
监测大屏是整个系统最能直观体现工作量的部分，也是答辩时老师会盯着看的地方。一个完整的图书零售监测大屏应该包含以下图表：
- 顶部KPI卡片：今日销售额、今日销量、本月销售额、库存预警数量。实现上就是一条SQL聚合查询，把结果渲染成数字卡片，放在页面上部。
- 近30天销售趋势折线图：按天分组SUM(sale_amount)，用ECharts折线图展示，直观看出销售波动情况。
- 图书品类销售占比饼图：按图书分类分组统计销售码洋占比。这张图能做出来，说明你理解了GROUP BY和业务场景的结合。
- 畅销书TOP10排行表格：按销量倒序取前十，配上简单的柱状图或条形图。这个模块虽然逻辑简单，但做好了非常出效果。
- 门店销售对比柱状图：按门店分组对比销售业绩。可以设计成支持切换"按销量"和"按销售额"两种排序维度。
- 分类销售趋势堆叠面积图：展示不同品类在一段时间内的销售变化。这个图做出来，系统的高级感立刻上一个档次。
关于图表实现，两点经验供参考。第一，后端只负责提供JSON格式的聚合数据，前端用JavaScript的fetch调用接口拿数据后传给ECharts实例。前后端分离写的代码比用Jinja2模板直接往页面里塞数据要清晰得多，调试也方便。第二，ECharts的option配置项直接去官网示例里复制再改，不用自己记API。官网的"销售数据折线图"示例改改数据源就是你要的效果。
一个读者容易绕弯的细节是：统计"今日销售额"时用sale_date = CURDATE()还是sale_date = '2025-01-15'这种固定日期，这在SQL里写起来简单，但如果你要演示的是"模拟数据生成到昨天"，那当天页面上就会显示一个大大的零，看起来很尴尬。建议在大屏页面加一个日期范围选择器，默认显示最近30天的汇总，让演示效果始终饱满。
3.3 查询统计：把SQL写对、写漂亮
图书零售监测系统的底层都是SQL查询。写这部分的时候，有几个典型的业务查询值得仔细研究，它们在答辩中被问到的概率极高。
查询1：近30天每日销售额变化
SELECT sale_date, SUM(sale_amount) AS total_amount FROM sales_record WHERE sale_date >= DATE('now', '-30 day') GROUP BY sale_date ORDER BY sale_date;这个查询的关键在于DATE函数对日期的偏移计算。SQLite的语法是DATE('now', '-30 day')，MySQL则是DATE_SUB(CURDATE(), INTERVAL 30 DAY)。如果你在写Flask代码时没有把数据库方言统一，建议在写SQL时就在注释里标注出来，答辩老师可能会追问。
查询2：品类销售占比
SELECT b.category, SUM(s.sale_amount) AS total_amount FROM sales_record s JOIN book b ON s.book_id = b.id GROUP BY b.category ORDER BY total_amount DESC;注意这里为什么用JOIN而不是直接查销售表：因为品类信息存在图书表里，两张表通过book_id关联。如果之前在销售表里冗余了book_name，但没冗余category，那你写这个查询就必须使用JOIN。实际开发中，我习惯在销售记录表里冗余存储book_name高频查询字段，把category这种低频字段留在图书表里。
查询3：库存预警清单
SELECT book_name, publisher, stock, safety_stock FROM book WHERE stock <= safety_stock ORDER BY (safety_stock - stock) DESC;这个查询的价值在于提醒你思考一个业务规则：安全库存阈值是什么？我建议把安全库存做成图书表里的一个普通字段，管理员可以在页面上调整每本书的安全库存值，这样比在代码里写死一个固定值要合理得多。答辩时如果老师问"你怎么定义库存不足"，你就可以把这张表的逻辑完整讲出来。
查询4：门店月度销售排行
SELECT st.store_name, COUNT(*) AS order_count, SUM(s.sale_quantity) AS total_quantity, SUM(s.sale_amount) AS total_amount FROM sales_record s JOIN store st ON s.store_id = st.id WHERE strftime('%Y-%m', s.sale_date) = '2025-06' GROUP BY st.store_name ORDER BY total_amount DESC;这个查询示范了字符串格式化的日期处理方式。strftime函数按%Y-%m格式取年份和月份，是做月度统计最稳妥的写法。
这些SQL写完以后，建议顺手封装成工具函数放在utils/statistics.py里。这样做的好处有三个：代码复用（服务端渲染和API接口共用一套统计函数）、逻辑隔离（业务查询逻辑不散落在各个路由里）、测试方便（可以单独写脚本验证SQL结果是否正确）。
4. 开发过程中实际踩过的坑：完整排查链路复盘
这段内容是我最想分享的。毕业设计看起来是在做一个系统，实际上是在训练你"遇到问题→定位问题→解决问题"的能力。以下三个坑是我在实际开发中踩过的，每个都花了不少时间才定位到根因。
4.1 中文乱码：从页面到终端一路排查
做图书系统绕不开中文——书名、作者、出版社全是中文。我第一次跑通Flask接口时，浏览器里显示的书名全是类似æ··ä¹±的乱码。当时第一反应是数据库有问题，于是去SQLite终端查数据，发现数据本身正常，那就说明问题出在Web响应链路。
排查思路其实很固定：按"数据库→后端响应→浏览器渲染"的顺序层层验证。数据正常排除数据库编码问题；在Flask路由里print返回数据，控制台显示正常，说明Python处理没问题；那问题只能在HTTP响应头里。后来发现Flask的jsonify返回数据时，响应头里的Content-Type是application/json; charset=utf-8，按理说没问题，但就是乱码。
折腾了半小时后偶然发现，问题出在模板渲染层级——我用的HTML模板文件没有声明<meta charset="UTF-8">，浏览器默认按GBK解码了。加上这个meta标签后一切正常。
这个坑让我养成了一个习惯：只要页面显示异常，先按"数据端→服务端→浏览器端"三层排查，每层用console或者终端确认输出内容是否正确，不要一上来就怀疑数据库。排查链路走一遍通常五分钟内能定位问题。
4.2 大屏图表加载慢：数据量不大但页面卡顿
模拟数据生成器跑了一个月的数据后，打开监测大屏发现折线图渲染要等好几秒。一开始以为是数据量太大，但查了一下销售记录表也就几千条，不至于卡成这样。
打开浏览器开发者工具（F12）查看Network面板，发现页面加载时连续发出了十几个异步请求，每个请求都要查一次数据库并做聚合计算。问题不在数据量，在请求次数太多——每个图表组件都单独调用一个统计接口，接口之间还有依赖顺序，浏览器默认并发限制是6个，剩下的请求排队等待，叠加起来就卡了。
解决办法是合并接口。把原来"近30天趋势""品类占比""门店对比"三个独立接口合并成一个/api/dashboard/summary总接口，一次返回全部大屏数据。前端只发起这一个请求，数据到达后统一传给各个ECharts实例。接口合并之后，大屏加载时间从三秒多降到几百毫秒。
这个优化思路在答辩时非常好讲：你从"请求瀑布"的角度分析了性能瓶颈，用"接口聚合减少HTTP往返"的方式做了优化，前后的响应时间数据一摆，老师基本挑不出毛病。
4.3 时间字段的类型坑：字符串日期排序出错
模拟数据生成器里，sale_date字段存的是YYYY-MM-DD格式的字符串，sale_time存的是HH:MM:SS格式的字符串。在SQLite里用ORDER BY sale_date排序时，由于字符串字典序和日期顺序在"YYYY-MM-DD"这种格式下恰好一致，所以查询结果没有出错，这算是一种侥幸。
但如果在MySQL里，或者如果有人把一条记录的日期写成了2025-6-15（月份没有补零），字符串排序就会把2025年6月排到2025年10月后面去。这种问题很难一眼看出来。
建议从一开始就用标准格式：日期统一YYYY-MM-DD，时间统一HH:MM:SS，在生成器脚本里就用strftime格式化好，从不允许手输非标准格式入库。另外在查询日期范围时，不要用字符串拼接的方式比较，比如WHERE sale_date >= '2025-06-01'在格式统一的前提下没问题，但如果允许用户自定义输入日期，务必在Python端先把输入解析成datetime.date对象再格式化。否则用户输入2025-6-1这种格式，查询结果就可能出现遗漏。
4.4 登录会话丢失：Flask的session密钥忘记配置
系统做了管理员登录功能后，本地测试一切正常，但在答辩演示时换了台电脑跑，每次登录成功跳转后立刻又跳回登录页。排查后发现config.py里没有设置SECRET_KEY，Flask的session在默认配置下的签名策略可能导致会话不稳定。
这个坑的典型特征是"本地正常，换环境不行"。根源在于Flask的session使用了SECRET_KEY来签名cookie内容。没有配置时，Flask会随机生成一个密钥，每次重启应用密钥就变，之前签发的session全部失效；更麻烦的是，在部分部署环境下，未配置密钥时的默认行为可能在每次请求时都重建session。
解决方案很简单：在config.py中明确配置一个固定的SECRET_KEY，例如：
import os class Config: SECRET_KEY = os.environ.get("SECRET_KEY", "dev-fixed-secret-key-change-in-production") DATABASE = os.path.join(os.path.dirname(__file__), "data", "book_retail.db")答辩演示前，我建议把这类环境相关配置全部确认一遍：数据库路径是绝对路径还是相对路径、端口号有没有冲突、静态文件路径是否正常。这些看起来的小事，在换了演示机器之后全都可能变成事故。
5. 论文与答辩：怎么把系统讲出深度
5.1 论文结构怎么组织
毕业设计论文的核心逻辑是"提出问题→分析问题→设计解决方案→实现→验证"。对应到图书零售监测系统，可以这样组织：
- 绪论：写图书零售行业的现状，强调数据驱动的精细化运营需求，点出传统人工统计效率低、误差大的痛点。
- 相关技术介绍：介绍Python、Flask框架、SQLite/MySQL、ECharts。这里不用写太深，每个技术写清楚"为什么选它"即可。
- 需求分析：把前面的需求拆解部分整理成文字，配合用例图（可以用Markdown画简单的文本流程图，或者用Visio/ProcessOn画好截图）。重点写清楚功能需求和非功能需求。
- 系统设计：架构设计、数据库设计（尤其要把表关系写清楚）、接口设计。
- 系统实现：每个模块的截图 + 关键代码片段 + 实现说明。每个模块配合实现效果截图，代码不用全部贴，贴核心片段并解释逻辑即可。
- 系统测试：功能测试用例表 + 测试结果 + 性能优化记录（接口合并优化这部分可以写进来）。测试用例表要覆盖核心功能，比如登录失败、销售数据录入成功、排行榜数据正确等。
很多同学的论文写得像流水账：一个模块一段，每段几百字，没有分析没有总结。加分的关键在于把设计思路写进去——比如为什么销售表要冗余图书名称、为什么用逻辑外键、为什么接口要合并——这些都是体现你思考深度的素材。
5.2 答辩高频问题与参考回答
根据我带过的毕设答辩情况，图书零售监测系统最常被问到的问题集中在以下几类，提前准备好组织好语言：
问题一：你的系统与市面上成熟的进销存系统（比如用友、金蝶）有什么区别？
参考思路：不回避差距，而是强调学习目的与侧重点。可以说自己重点实现了零售监测即经营分析这一层，对进销存底层的复杂业务流程（采购审批流、多级库存、财务结算）做了简化；但数据分析与可视化部分是针对图书品类定制的，例如按图书分类、出版社、畅销排行维度做的监测，在通用进销存里不一定有预设。这样回答既诚实又展示了你的取舍逻辑。
问题二：如果数据量达到一百万条、一千万条，你的系统性能瓶颈在哪，怎么优化？
参考思路：分点回答。第一，数据库层面，给sale_date、book_id加索引，按时间做分区表；第二，聚合层，把高频统计结果做成汇总表或缓存（Redis），避免实时大范围扫描；第三，架构层，引入消息队列做异步写入，查询走只读副本。这三点说出来，老师会认为你考虑了扩展性。
问题三：你的模拟数据是怎么生成的，能保证数据合理性吗？
参考思路：讲清楚生成逻辑里的业务约束，比如销量服从长尾分布、节假日销量脉冲、不同品类的季节特征、库存不能为负等。这会体现你对业务场景的真实理解，而不仅仅是会用random函数。
问题四：为什么选择SQLite而不用MySQL？
参考思路：强调毕设场景的单机本地演示、零配置文件型数据库的优势，同时指出SQLite在并发写入和网络访问方面不适合生产环境，以及如果有更高并发需求可平滑迁移到MySQL——这是有依据的，可以再补充一句迁移时需要注意的差异点（如日期函数语法差异），显得你研究过。
5.3 演示环节的实操细节
答辩演示是很多人忽略但差评高发的地方。几点建议直接照做：
- 提前准备一套固定的演示数据，不要现场重新生成数据，因为你无法预知模拟脚本这次跑出来什么样的图表形状。固定数据意味着大屏展示效果完全可控。
- 提前关掉无关的浏览器标签页和终端窗口，尽量保持一个干净的全屏演示状态。
- 演示时先讲业务场景，再说系统功能。很多同学上来就点开大屏说"这是首页"，老师一头雾水，不知道这个页面要解决什么问题。正确的顺序是：纸质表格统计的痛点 → 系统的指标维度 → 大屏演示 → 具体功能逐个演示。
- 准备一张额外的技术亮点页，内容是你在开发中做的优化和踩坑总结，比如接口合并提速数倍、数据库设计时的冗余取舍。老师提问的时候，你可以把这些内容讲出来，主动权就抓在自己手里。
答辩紧张是正常的，但如果你对系统里每一行代码、每一种数据、每一个图表的含义都了然于心，撑过十五分钟没有任何问题。真正会被问倒的，往往是那种代码没自己写过、数据是临时找来的半成品项目。
6. 扩展思路：这套系统还能往哪个方向延伸
毕业设计写完不是终点，如果你还想拿它参加比赛、丰富简历，或者作为后续找工作中的项目经验，有几个方向的扩展性价比很高。
第一个方向是预测分析。在现有数据基础上，用scikit-learn做一个简单的销量预测模块。比如根据历史销售数据和日期特征（是否周末、是否节假日、是否促销日）预测明天的销量。这个功能加进去之后，系统就从"监测"升级成了"监测+预测"，在答辩和简历里的分量完全不同。实现难度并不高，线性回归或随机森林都可以，数据用你模拟生成的那份就能跑出一个基础结果。
第二个方向是用户画像与推荐。在销售记录基础上，围绕读者群体做分析，比如哪些品类的书经常被一起购买（关联规则挖掘），从而为不同门店设计差异化的配货方案。技术点涉及Apriori算法或协同过滤，都是计算机专业学生耳熟能详的东西，拿来作为论文创新点非常合适。
第三个方向是可视化地图。如果门店数据里已经有区域、地址信息，可以用ECharts的地图组件把销售数据按区域做地理分布展示，比如在省市级地图上叠加销售额热力值，直观呈现不同地域的销售差异。这个功能在视觉上冲击力强，实现上只需要把门店表和区域维度整理清楚，地图组件的配置在ECharts官网有现成示例。
我个人的建议是：如果时间和精力有限，优先做第一个方向。销量预测和"监测系统"的业务契合度最高——本来就是天天产生销售数据，顺手做一个明日销量的预测值挂在KPI卡片旁边，系统完成度立刻上升一个级别。而且Python生态里做机器学习本来就是强项，写起来不会太费劲。
最后再分享一个做这类系统的心得：不要等到系统完全写完才写论文。数据库设计定稿后就可以开始写需求分析和系统设计章节；页面做完一个模块，截图存档，对应章节顺手写掉。最后两周应该是用来打磨演示流程和准备答辩问题，而不是在焦虑中补文档。这样走完全程，你会发现毕业设计带来的真实收获远远超过那一个学分。
