尧图网页设计 
简介超市管理信息系统课程设计报告PDF完整覆盖从系统调查、系统规划、系统分析到系统设计、调试与测试的九大环节适合高校信息管理、计算机相关专业学生作为课程设计或毕业设计的写作参考。资源为单份PDF文档约1.67MB内含业务流程图、数据流程分析、数据字典、层次结构设计、数据存储设计、输入输出设计等关键章节附录还包含心得体会与致谢便于对照模仿整体写作框架。目前已吸引69人学习浏览是一份结构严谨、过程完整的超市进销存管理系统设计范例可帮助读者快速理解结构化开发方法在小型管理信息系统中的实际应用节省从零搭建报告框架的时间。1. 先想清楚再动手为什么超市管理信息系统课程设计总在答辩现场翻车超市管理信息系统是管理信息系统课程设计里最经典的题目之一看起来业务简单实际做起来却很容易在答辩现场翻车系统启动报外键错误、库存扣成负数、昨天的营业额和今天对不上。问题不在功能多寡而在于你有没有把业务规则翻译成正确的表结构、事务和报表口径并用测试证据链证明系统真的成立。这篇笔记按“为什么这么设计 → 具体怎么实现 → 坑在哪里”的顺序把一套可复现的超市管理信息系统课程设计完整走一遍。适合正在准备课设、需要在一到两周内同时交付系统、报告和答辩演示的人。2. 数据库设计是一场倒推从报表需求反推 ER 图和建表 SQL很多同学做课设的习惯是先打开 IDE 写界面再按界面上出现的输入框去建表。这种做法最容易埋雷等做到报表统计那一步会发现缺字段、缺关联表只能回头改表结构和代码。正确的顺序是倒推。先想清楚这个系统将来要回答哪些问题再决定建什么表、每个表存什么字段。你不需要把需求写得像商业软件那么全但核心业务闭环必须完整。2.1 从“每天要回答的问题”开始设计数据表动笔画 ER 图之前先准备四句话这四句话基本决定了数据库的骨架每次结账小票上要打印什么至少需要商品名、单价、数量、合计、时间、收银员。每天关店后要能回答什么当天卖了多少单、营业额多少、客单价多少。盘点库存时要能回答什么某商品还有多少件、低于安全库存的 SKU 有哪些。供应商提出某商品不再供货系统怎么处理物理删除还是逻辑下架。从这四句话倒推实体和字段就比凭空画 ER 图可靠得多。小票需要 sale_order 和 sale_item 两张表营业额报表需要把 create_time、total_amount 落在订单表上库存预警需要 stock 表里同时存在 qty 和 safe_qty。字段不是越全越好而是让每个字段都能回答一个具体的业务问题。ER 图中的关系也按同样思路一个供应商供多种商品是“一对多”一个订单包含多种商品是“一对多”里的“订单到订单明细”。真正容易画错的是订单明细和商品之间的关系订单明细应该存商品快照信息而不是仅仅存一个外键。如果商品价格将来改了历史订单上的金额不应该跟着变所以 sale_item 里要有独立的 price 字段。2.2 六张核心表的建表 SQL字段、约束和存储引擎按上面的思路一套完整的课程设计最少需要六张核心表供应商表、商品表、库存表、销售订单表、销售明细表、会员表。下面这组建表 SQL 可以直接拿来改也可以作为报告“数据字典”章节的底稿。CREATE DATABASE IF NOT EXISTS supermarket_db DEFAULT CHARACTER SET utf8mb4 DEFAULT COLLATE utf8mb4_general_ci; USE supermarket_db; -- 供应商 CREATE TABLE supplier ( supplier_id INT PRIMARY KEY AUTO_INCREMENT, supplier_name VARCHAR(60) NOT NULL, contact_phone VARCHAR(20), address VARCHAR(120) ) ENGINEInnoDB; -- 商品 CREATE TABLE product ( product_id INT PRIMARY KEY AUTO_INCREMENT, product_name VARCHAR(60) NOT NULL, barcode VARCHAR(32) UNIQUE, category VARCHAR(30), sale_price DECIMAL(10,2) NOT NULL, supplier_id INT, status TINYINT NOT NULL DEFAULT 1 COMMENT 1-正常0-下架, create_time DATETIME DEFAULT CURRENT_TIMESTAMP, CONSTRAINT fk_product_supplier FOREIGN KEY (supplier_id) REFERENCES supplier (supplier_id) ) ENGINEInnoDB; -- 库存 CREATE TABLE stock ( product_id INT PRIMARY KEY, qty INT NOT NULL DEFAULT 0, safe_qty INT NOT NULL DEFAULT 10, CONSTRAINT fk_stock_product FOREIGN KEY (product_id) REFERENCES product (product_id) ) ENGINEInnoDB; -- 会员 CREATE TABLE member_info ( member_id INT PRIMARY KEY AUTO_INCREMENT, member_no VARCHAR(20) UNIQUE NOT NULL, member_name VARCHAR(30) NOT NULL, phone VARCHAR(20), balance DECIMAL(10,2) DEFAULT 0 ) ENGINEInnoDB; -- 销售订单 CREATE TABLE sale_order ( order_id INT PRIMARY KEY AUTO_INCREMENT, order_no VARCHAR(32) UNIQUE NOT NULL, member_id INT, total_amount DECIMAL(10,2) NOT NULL DEFAULT 0, pay_method VARCHAR(10) DEFAULT cash, order_status TINYINT NOT NULL DEFAULT 0 COMMENT 0-正常1-作废, operator VARCHAR(30), create_time DATETIME DEFAULT CURRENT_TIMESTAMP, CONSTRAINT fk_order_member FOREIGN KEY (member_id) REFERENCES member_info (member_id) ) ENGINEInnoDB; -- 销售明细 CREATE TABLE sale_item ( item_id INT PRIMARY KEY AUTO_INCREMENT, order_id INT NOT NULL, product_id INT NOT NULL, product_name VARCHAR(60), price DECIMAL(10,2) NOT NULL, qty INT NOT NULL, amount DECIMAL(10,2) NOT NULL, CONSTRAINT fk_item_order FOREIGN KEY (order_id) REFERENCES sale_order (order_id), CONSTRAINT fk_item_product FOREIGN KEY (product_id) REFERENCES product (product_id) ) ENGINEInnoDB;字段和约束的选择不是随手写的有几个关键点要解释给答辩老师听。金额全部用 DECIMAL(10,2) 而不是 DOUBLE是因为浮点数存货币会产生 0.10.2 不等于 0.3 的精度问题sale_item 里冗余了 product_name 和 price是为了保存下单时刻的商品快照避免商品改名或调价后历史单据变得不可读所有表都用 InnoDB 引擎是为了让后面的销售事务可以回滚MyISAM 不支持事务一旦库存扣了而订单没写成数据就凉了。外键在这个设计里是有意保留的。课程设计的作业场景里数据量很小外键带来的写入开销可以忽略但它在“删除商品被销售明细引用时”能拦住你避免出现孤儿数据。这个特性会引出第 5 章里的避坑问题不能硬删有销售记录的商品。2.3 第三范式与冗余字段的取舍理论分和实践分要同时拿数据库设计这一章答辩老师最喜欢问的问题是你的设计符合第几范式如果 sale_order 表里存了 total_amount而它可以通过 sale_item 求和得到这不是冗余吗这个问题回答得好是加分项回答不好会被认为理论基础不扎实。常见做法是承认这是冗余然后解释取舍逻辑每次生成报表都去 SUM 全部明细在订单量变大时会把数据库拖垮在订单表上直接保存汇总金额报表只需要查一行。这个冗余字段不是程序随便算出来写进去的而是由事务保证一致性的。类似的取舍也出现在库存表上。stock 表只存当前库存数量不存每次入库和出库的流水。课设阶段这样简化是合理的因为库存流水是另一个业务模块做进来会让工作量翻倍。但报告里最好能写一句系统目前只记录当前库存入库和出库流水作为后续扩展方向。主动交代边界比答辩时被老师问出来体面得多。3. 用 JDBC MySQL 跑通最小可用系统连接、事务扣库存和报表 SQL数据库设计完毕接下来就是把最少但完整的业务流程跑起来。界面形态看你选的课设方向Java Swing、JavaFX 或纯控制台都可以这里不贴界面代码重点讲三个最容易让系统“能用”和“不能用”的业务层环节连接配置、结账事务、报表查询。3.1 JDBC 连接配置驱动版本、连接串参数和连接关闭用一个DB工具类集中管理连接是最省事的做法。配置里最容易踩坑的有三个地方驱动类版本、URL 里的时间参数、连接关闭。import java.sql.Connection; import java.sql.DriverManager; import java.sql.SQLException; public class DB { // MySQL 8.x 的连接串 private static final String URL jdbc:mysql://127.0.0.1:3306/supermarket_db ?useUnicodetruecharacterEncodingutf8 useSSLfalse serverTimezoneAsia/Shanghai allowPublicKeyRetrievaltrue; private static final String USER root; private static final String PASSWORD 你的密码; public static Connection getConn() throws SQLException { return DriverManager.getConnection(URL, USER, PASSWORD); } }这段代码要解释清楚两个参数。characterEncodingutf8 管的是 Java 程序向 MySQL 写入中文时的编码转换调错就会出现第 5 章里说的中文乱码。serverTimezoneAsia/Shanghai 是 MySQL 8 的要求不指定的话如果 MySQL 服务端的时区和本机不一致会在连接时直接报时间字段异常。关于驱动类不同 MySQL 版本写法不同。MySQL 5.1 之前的驱动类名是com.mysql.jdbc.Driver从 MySQL 8 开始改成com.mysql.cj.jdbc.Driver而且 JDBC 4 以上版本会自动加载驱动大多数课程设计里手动写Class.forName(...)属于多余操作。真正容易出问题的是 pom.xml 里引的驱动版本和代码不匹配新代码配旧驱动报ClassNotFoundException的概率极高。连接关闭这件事十个同学里有一半会忘。每次getConn()都会向数据库申请一个连接用完了不关数据库连接池或服务端的最大连接数很快被打满系统运行十几分钟就报连接超时。解决办法就是服务层代码里养成在finally块中关闭连接的习惯最推荐用 try-with-resources 写法。public boolean login(String username, String password) { String sql SELECT COUNT(*) FROM staff WHERE login_name ? AND password ?; try (Connection conn DB.getConn(); PreparedStatement ps conn.prepareStatement(sql)) { ps.setString(1, username); ps.setString(2, password); try (ResultSet rs ps.executeQuery()) { rs.next(); return rs.getInt(1) 0; } } catch (SQLException e) { throw new RuntimeException(登录校验失败, e); } }注意这个登录查询里的两个细节SQL 使用?占位符而不是字符串拼接查询结果是 COUNT(*)不是直接把用户记录查出来比对。这两个细节在报告里可以专门讲参数化查询防止 SQL 注入COUNT 查询避免把密码等敏感字段暴露在结果集中。3.2 收银结账事务用行锁避免库存扣成负数收银结账是超市管理信息系统最核心的业务也是答辩老师很可能要求现场演示的环节。这个操作涉及两步扣库存、写订单明细。如果不用事务包裹会出现“库存已经扣了但订单明细写入失败”这种一半成功一半失败的情况。下面是结账逻辑的骨架重点看事务和锁是怎么用的。public boolean checkout(int orderId, ListCartItem cartItems) { Connection conn null; try { conn DB.getConn(); conn.setAutoCommit(false); // 关闭自动提交事务从这里开始 for (CartItem item : cartItems) { // 1. 锁定库存行防止两个收银台并发读到同一份旧库存 String lockSql SELECT qty FROM stock WHERE product_id ? FOR UPDATE; try (PreparedStatement ps conn.prepareStatement(lockSql)) { ps.setInt(1, item.getProductId()); try (ResultSet rs ps.executeQuery()) { if (!rs.next()) { throw new RuntimeException(商品不存在); } if (rs.getInt(qty) item.getQty()) { throw new RuntimeException(库存不足 item.getProductName()); } } } // 2. 扣减库存 String updateSql UPDATE stock SET qty qty - ? WHERE product_id ?; try (PreparedStatement ps conn.prepareStatement(updateSql)) { ps.setInt(1, item.getQty()); ps.setInt(2, item.getProductId()); ps.executeUpdate(); } // 3. 写入销售明细 String insertSql INSERT INTO sale_item(order_id, product_id, product_name, price, qty, amount) VALUES (?,?,?,?,?,?); try (PreparedStatement ps conn.prepareStatement(insertSql)) { ps.setInt(1, orderId); ps.setInt(2, item.getProductId()); ps.setString(3, item.getProductName()); ps.setBigDecimal(4, item.getPrice()); ps.setInt(5, item.getQty()); ps.setBigDecimal(6, item.getPrice().multiply(BigDecimal.valueOf(item.getQty()))); ps.executeUpdate(); } } conn.commit(); // 全部成功才提交 return true; } catch (Exception e) { if (conn ! null) { try { conn.rollback(); // 任何一个环节失败全部回滚 } catch (SQLException ex) { e.addSuppressed(ex); } } // 实际项目里这里应该把异常抛给界面层做提示 return false; } finally { if (conn ! null) { try { conn.close(); // 释放连接否则行锁会一直持有 } catch (SQLException e) { // 关闭失败通常不影响业务但不建议吞掉日志 } } } }三处代码对应三个必须能讲清楚的原理。第一setAutoCommit(false)是事务的开关不关自动提交每一条 SQL 执行完就不可回滚扣库存和写明细之间断电数据就找不回来。第二SELECT ... FOR UPDATE是悲观锁的写法它把这行库存记录锁住其他事务要修改这行时会等待锁释放课程设计阶段并发压力不大用悲观锁最直观代码逻辑也最好解释。第三conn.close()不只是归还连接也是释放锁的关键操作连接不关行锁会被一直占着其他窗口的结账操作会卡住这是非常经典的“界面无响应”原因。这里还有一个容易在答辩时被追问的点为什么不直接用一条带条件的 UPDATE 来扣库存比如UPDATE stock SET qty qty - ? WHERE product_id ? AND qty ?。这种写法也叫乐观扣减一条 SQL 就能完成判断和扣减性能更好。课程设计里选择先 SELECT 再 UPDATE是为了演示“检查库存不足”的界面提示代码阅读上更直观。报告里能主动提一句“生产环境更推荐条件 UPDATE”反而显得你有工程眼界。3.3 当日营业额和库存预警SQL 口径先定死代码只是执行者报表是管理信息系统区别于普通增删改查系统的标志。不需要做华丽图表能回答两个问题就够了今天卖了多少钱、哪些商品快卖完了。先看当日营业额查询。这里的口径必须严谨统计哪些订单是否包含作废订单时间范围怎么界定。SELECT COUNT(*) AS order_count, SUM(total_amount) AS sale_amount, ROUND(SUM(total_amount) / COUNT(*), 2) AS avg_order_amount FROM sale_order WHERE order_status 0 AND create_time 2026-01-05 00:00:00 AND create_time 2026-01-06 00:00:00;这段 SQL 的关键在时间条件。很多同学会写WHERE DATE(create_time) 2026-01-05功能上没错但一旦这张表的行数上万DATE()函数会让索引失效全表扫描。正确写法是让查询条件落在索引列上用左闭右开区间 2026-01-05 00:00:00 AND 2026-01-06 00:00:00把“当天”完整包进去。在代码里这个日期参数一般通过?传入不要把字符串拼进 SQL。库存预警查询则要用到 JOIN目标是把商品名称和库存数量对起来看。SELECT p.product_name, st.qty, st.safe_qty FROM stock st JOIN product p ON p.product_id st.product_id WHERE st.qty st.safe_qty ORDER BY st.qty - st.safe_qty ASC;这个查询的边界条件很清楚qty 小于安全库存的才显示。答辩时如果老师问“安全库存怎么定的”你可以回答这是商品补货的阈值目前由管理员维护将来可以按销量动态计算。把 SQL 里每个字段都对应到一句业务解释比背概念有用得多。4. 课程设计报告如何写得像一份工程交付结构、截图和测试用例的配合系统做完了报告写得好不好直接决定答辩时老师愿不愿意放你一马。课程设计报告不是毕业论文不要求深刻的学术洞见但要求逻辑自洽、证据可追溯。评判老师一般没有时间通读全文他会挑几个关键位置翻需求分析里的业务规则、数据库设计里的数据字典、系统测试里的用例表。这三部分写扎实了其余章节可以正常发挥。4.1 报告目录怎么定评审第一眼在看什么一份标准的课程设计报告目录通常包含需求分析、系统设计、数据库设计、系统实现、系统测试、总结体会、参考文献和附录。不要觉得这个结构老套它已经经受了多年答辩考验每一章对应评审老师一个关注点。报告章节内容重点评审老师的提问点需求分析角色划分、功能模块说明、业务流程描述你的系统边界在哪里为什么这样做系统设计系统架构图、模块划分、技术选型界面和业务逻辑有没有分层数据库设计ER 图、数据字典、建库 SQL表和实体是否对应外键是否合理系统实现核心界面截图、关键代码片段核心业务流程能不能跑通系统测试测试环境、测试用例表、结果截图你测没测过边界和异常情况总结体会完成的工作、遇到的问题、解决方案你在这个课题里真正动手做了多少用户最容易写空的是“总结体会”。常见写法是“通过本次课程设计我学会了……”这种套话。更有说服力的写法是把一个具体的踩坑经历写进去写“我在实现库存扣减时发现并发会让库存变负数最后用事务和行锁解决了”比十句空话都有用而且这条经验可以自然衔接第 5 章的避坑清单。4.2 测试用例表是答辩的“后悔药”预期和实测必须成对出现答辩演示翻车后老师通常会问“你测试过这个场景吗”这时你在测试用例表里有这一条就能把局面救回来。测试用例表不需要多覆盖正常流程和关键异常流程即可五到八条足够。下面是一张可以直接改用的测试用例表模板用例编号操作步骤预期结果实测结果是否通过TC-01未输入账号直接点击登录提示“账号不能为空”焦点停在账号输入框同预期通过TC-02输入正确账号密码登录进入主界面状态栏显示当前收银员同预期通过TC-03商品 A 库存 10 件购物车加 12 件后结算提示“库存不足”不生成订单库存不变同预期通过TC-04正常结算一件商品库存减少销售明细生成销售额统计变化同预期通过TC-05查询 2026-01-05 的营业额显示对应日期的订单数和合计金额同预期通过写完表格后再配上两张关键截图库存不足时的提示弹窗以及结账成功后数据库里 sale_order 和 sale_item 的实际记录。注意截图要对应起来不能报告里写“库存不变”截图上却是负数。4.3 截图与代码的对应关系防止“两张皮”报告中贴代码和贴截图的通病是各说各话代码里写的逻辑和截图上看到的状态对不上。最常见的情况是报告里的建表 SQL 写了DECIMAL(10,2)但界面上显示合计金额时截图的数字却带有很长的小数尾数老师一看就知道代码和文档不是同一套。预防办法是交付前花十分钟做一次“对应检查”每个核心界面截图都在数据库里找到它对应的数据每段贴出来的核心代码都用一行注释说明它产生了截图中哪一部分结果。比如结账类的截图旁边配一段话“本次演示为商品 A 结算 3 件库存从 10 更新为 7对应 sale_item 表中新增一条 amount单价的记录。”这种把界面、代码、数据三者对齐的做法答辩时会让老师觉得你的报告工程质量很高。5. 避坑清单超市系统最常见的 5 个翻车现场这一章列出的问题基本是我在课程设计代码里反复看到的高频坑。每一条按“现象 → 原因 → 解决”的路径排查答辩前对照自查一遍能挡掉八成现场故障。5.1 中文乱码连接串没指定 utf8或库表字符集不统一现象商品名称、会员姓名里只要有中文存入数据库就变成问号?或者显示成乱码。原因Java 程序、MySQL 连接、数据库表三者的字符集不一致。最常见的是建库时没指定字符集MySQL 默认落到了 latin1或者连接串里少了 characterEncodingutf8。解决把三层统一成 utf8mb4。建库语句用DEFAULT CHARACTER SET utf8mb4连接串加characterEncodingutf8如果表已经建好了执行ALTER TABLE product CONVERT TO CHARACTER SET utf8mb4;。做这三步之后再重新插入中文测试别在乱码数据上直接改先清掉脏数据。5.2 并发结账把库存扣成负数事务开了锁却没加现象两个收银窗口同时结算“最后一件商品”两张销售单都成功了库存变成负数。原因代码里虽然用了事务但只是先 SELECT 查库存再 UPDATE 扣库存。两个事务同时读到库存为 1都判断“够卖”各自执行扣减最终变成 -1。关键缺失是查询和扣减之间没有做任何并发控制。解决在查询库存的 SQL 后面加FOR UPDATE让第一个事务锁定这行记录第二个事务只能等锁释放。如果不想用显式锁也可以用条件更新UPDATE stock SET qty qty - ? WHERE product_id ? AND qty ?受影响行数为 0 就表示库存不足。课设代码选择前者逻辑更直观答辩时也更好讲。5.3 营业额出现 0.30000000000000004浮点数不能直接存金额现象结算两件 0.1 元的商品界面显示合计为 0.30000000000000004而不是 0.30。原因Java 的 float/double 和 MySQL 的 FLOAT/DOUBLE 类型都采用二进制浮点存储0.1 在二进制里是无限循环小数计算时必然产生精度误差。这不是 bug是数值表示方式导致的现象。解决数据库字段统一用DECIMAL(10,2)Java 代码里用BigDecimal做金额计算不要用 double 接收数据库返回的值。注意 BigDecimal 构造时用字符串new BigDecimal(0.1)才对直接new BigDecimal(0.1)会把浮点误差带进来等于白改。5.4 删除商品时报外键失败有销售记录的商品不能硬删现象管理系统里想删掉某个商品系统弹窗提示 “Cannot delete or update a parent row”删除失败。原因该商品的 product_id 已经被 sale_item 表引用外键约束不允许删掉父表记录。从业务上说这也是对的历史销售明细里应该保留这个商品的名称和价格硬删会让历史报表失去意义。解决不要把删除做成物理删除。正确做法是逻辑删除在 product 表里加一个 status 字段默认 1 表示正常点击“删除”时把它置为 0查询商品列表时统一加过滤条件WHERE status 1。报告里把这个设计写成“商品的逻辑删除机制”反而能体现你理解了外键约束的价值。5.5 日结报表少了凌晨的订单日期比较的边界没算清现象报表统计的是最近 24 小时但凌晨 00:05 的订单没有被统计进当天数据里。原因查询条件写成了WHERE create_time 2026-01-05或者BETWEEN 2026-01-05 00:00:00 AND 2026-01-05 23:59:59。前者把 datetime 列和日期字符串直接比较MySQL 会做隐式转换00:05 的订单匹配不上后者漏掉了 23:59:59 到次日 00:00:00 之间的那 1 秒。解决日期区间统一用左闭右开写法 2026-01-05 00:00:00 AND 2026-01-06 00:00:00把判断条件写到索引列上既完整又高效。在程序里如果要做“当天”报表用?传入当天零点另一个参数用DATE_ADD(当天, INTERVAL 1 DAY)。6. 答辩前一夜按这套流程走一遍复位脚本、预演失败路径、备份系统离验收只剩一天时不要再写新功能了把时间花在“让演示稳定”上。我的习惯是准备一个 demo 复位脚本核心只有两句清空销售数据把库存重置成演示起点。-- demo_reset.sql演示前执行恢复干净数据 DELETE FROM sale_item; DELETE FROM sale_order; UPDATE stock SET qty 50;这样做的原因是答辩现场最怕的不是代码不会跑而是演示到一半数据乱了上午试了几次结账库存成了零散数字报表跟实际演示流程对不上。复位脚本一执行所有验证数据都在掌握中系统像刚装好一样干净。演示顺序也要预演我建议固定为登录 → 商品管理 → 收银结账 → 查看库存变化 → 查询当日报表 → 数据库端验证数据。这个顺序是层层递进的先证明系统能进再证明能管接着证明关键业务能跑最后用报表和数据库记录证明数据落库正确。另外值得花十分钟的是“预演一次失败路径”。比如故意让某件商品超出库存数量去结算让系统弹出“库存不足”再去数据库里确认没有生成脏数据。这个演示的答辩价值比你预想的高它直接验证了业务规则和事务回滚老师会认为你的系统考虑了异常场景。这也是我吃过亏之后留下的习惯宁可自己在答辩前翻一次车也不要把翻车留给现场。备份层面上把数据库导出一份 SQL 文件、把项目代码打一个压缩包放在桌面是再基本不过的动作。更实用的一点是答辩前一晚永远不要改功能、不要调边界参数要改就改演示数据。全新代码最后一晚最容易引入新 bug这是很多人的血泪经验。把数据复位、把失败路径预演一遍、把备份留好这套动作做完系统的行为就在掌控之中了不靠玄学。希望这篇笔记能帮你把课程设计做成一件确定的事。本文还有配套的精品资源点击获取 超市管理信息系统课程设计：从数据库设计到事务与库存避坑全指南
简介超市管理信息系统课程设计报告PDF完整覆盖从系统调查、系统规划、系统分析到系统设计、调试与测试的九大环节适合高校信息管理、计算机相关专业学生作为课程设计或毕业设计的写作参考。资源为单份PDF文档约1.67MB内含业务流程图、数据流程分析、数据字典、层次结构设计、数据存储设计、输入输出设计等关键章节附录还包含心得体会与致谢便于对照模仿整体写作框架。目前已吸引69人学习浏览是一份结构严谨、过程完整的超市进销存管理系统设计范例可帮助读者快速理解结构化开发方法在小型管理信息系统中的实际应用节省从零搭建报告框架的时间。1. 先想清楚再动手为什么超市管理信息系统课程设计总在答辩现场翻车超市管理信息系统是管理信息系统课程设计里最经典的题目之一看起来业务简单实际做起来却很容易在答辩现场翻车系统启动报外键错误、库存扣成负数、昨天的营业额和今天对不上。问题不在功能多寡而在于你有没有把业务规则翻译成正确的表结构、事务和报表口径并用测试证据链证明系统真的成立。这篇笔记按“为什么这么设计 → 具体怎么实现 → 坑在哪里”的顺序把一套可复现的超市管理信息系统课程设计完整走一遍。适合正在准备课设、需要在一到两周内同时交付系统、报告和答辩演示的人。2. 数据库设计是一场倒推从报表需求反推 ER 图和建表 SQL很多同学做课设的习惯是先打开 IDE 写界面再按界面上出现的输入框去建表。这种做法最容易埋雷等做到报表统计那一步会发现缺字段、缺关联表只能回头改表结构和代码。正确的顺序是倒推。先想清楚这个系统将来要回答哪些问题再决定建什么表、每个表存什么字段。你不需要把需求写得像商业软件那么全但核心业务闭环必须完整。2.1 从“每天要回答的问题”开始设计数据表动笔画 ER 图之前先准备四句话这四句话基本决定了数据库的骨架每次结账小票上要打印什么至少需要商品名、单价、数量、合计、时间、收银员。每天关店后要能回答什么当天卖了多少单、营业额多少、客单价多少。盘点库存时要能回答什么某商品还有多少件、低于安全库存的 SKU 有哪些。供应商提出某商品不再供货系统怎么处理物理删除还是逻辑下架。从这四句话倒推实体和字段就比凭空画 ER 图可靠得多。小票需要 sale_order 和 sale_item 两张表营业额报表需要把 create_time、total_amount 落在订单表上库存预警需要 stock 表里同时存在 qty 和 safe_qty。字段不是越全越好而是让每个字段都能回答一个具体的业务问题。ER 图中的关系也按同样思路一个供应商供多种商品是“一对多”一个订单包含多种商品是“一对多”里的“订单到订单明细”。真正容易画错的是订单明细和商品之间的关系订单明细应该存商品快照信息而不是仅仅存一个外键。如果商品价格将来改了历史订单上的金额不应该跟着变所以 sale_item 里要有独立的 price 字段。2.2 六张核心表的建表 SQL字段、约束和存储引擎按上面的思路一套完整的课程设计最少需要六张核心表供应商表、商品表、库存表、销售订单表、销售明细表、会员表。下面这组建表 SQL 可以直接拿来改也可以作为报告“数据字典”章节的底稿。CREATE DATABASE IF NOT EXISTS supermarket_db DEFAULT CHARACTER SET utf8mb4 DEFAULT COLLATE utf8mb4_general_ci; USE supermarket_db; -- 供应商 CREATE TABLE supplier ( supplier_id INT PRIMARY KEY AUTO_INCREMENT, supplier_name VARCHAR(60) NOT NULL, contact_phone VARCHAR(20), address VARCHAR(120) ) ENGINEInnoDB; -- 商品 CREATE TABLE product ( product_id INT PRIMARY KEY AUTO_INCREMENT, product_name VARCHAR(60) NOT NULL, barcode VARCHAR(32) UNIQUE, category VARCHAR(30), sale_price DECIMAL(10,2) NOT NULL, supplier_id INT, status TINYINT NOT NULL DEFAULT 1 COMMENT 1-正常0-下架, create_time DATETIME DEFAULT CURRENT_TIMESTAMP, CONSTRAINT fk_product_supplier FOREIGN KEY (supplier_id) REFERENCES supplier (supplier_id) ) ENGINEInnoDB; -- 库存 CREATE TABLE stock ( product_id INT PRIMARY KEY, qty INT NOT NULL DEFAULT 0, safe_qty INT NOT NULL DEFAULT 10, CONSTRAINT fk_stock_product FOREIGN KEY (product_id) REFERENCES product (product_id) ) ENGINEInnoDB; -- 会员 CREATE TABLE member_info ( member_id INT PRIMARY KEY AUTO_INCREMENT, member_no VARCHAR(20) UNIQUE NOT NULL, member_name VARCHAR(30) NOT NULL, phone VARCHAR(20), balance DECIMAL(10,2) DEFAULT 0 ) ENGINEInnoDB; -- 销售订单 CREATE TABLE sale_order ( order_id INT PRIMARY KEY AUTO_INCREMENT, order_no VARCHAR(32) UNIQUE NOT NULL, member_id INT, total_amount DECIMAL(10,2) NOT NULL DEFAULT 0, pay_method VARCHAR(10) DEFAULT cash, order_status TINYINT NOT NULL DEFAULT 0 COMMENT 0-正常1-作废, operator VARCHAR(30), create_time DATETIME DEFAULT CURRENT_TIMESTAMP, CONSTRAINT fk_order_member FOREIGN KEY (member_id) REFERENCES member_info (member_id) ) ENGINEInnoDB; -- 销售明细 CREATE TABLE sale_item ( item_id INT PRIMARY KEY AUTO_INCREMENT, order_id INT NOT NULL, product_id INT NOT NULL, product_name VARCHAR(60), price DECIMAL(10,2) NOT NULL, qty INT NOT NULL, amount DECIMAL(10,2) NOT NULL, CONSTRAINT fk_item_order FOREIGN KEY (order_id) REFERENCES sale_order (order_id), CONSTRAINT fk_item_product FOREIGN KEY (product_id) REFERENCES product (product_id) ) ENGINEInnoDB;字段和约束的选择不是随手写的有几个关键点要解释给答辩老师听。金额全部用 DECIMAL(10,2) 而不是 DOUBLE是因为浮点数存货币会产生 0.10.2 不等于 0.3 的精度问题sale_item 里冗余了 product_name 和 price是为了保存下单时刻的商品快照避免商品改名或调价后历史单据变得不可读所有表都用 InnoDB 引擎是为了让后面的销售事务可以回滚MyISAM 不支持事务一旦库存扣了而订单没写成数据就凉了。外键在这个设计里是有意保留的。课程设计的作业场景里数据量很小外键带来的写入开销可以忽略但它在“删除商品被销售明细引用时”能拦住你避免出现孤儿数据。这个特性会引出第 5 章里的避坑问题不能硬删有销售记录的商品。2.3 第三范式与冗余字段的取舍理论分和实践分要同时拿数据库设计这一章答辩老师最喜欢问的问题是你的设计符合第几范式如果 sale_order 表里存了 total_amount而它可以通过 sale_item 求和得到这不是冗余吗这个问题回答得好是加分项回答不好会被认为理论基础不扎实。常见做法是承认这是冗余然后解释取舍逻辑每次生成报表都去 SUM 全部明细在订单量变大时会把数据库拖垮在订单表上直接保存汇总金额报表只需要查一行。这个冗余字段不是程序随便算出来写进去的而是由事务保证一致性的。类似的取舍也出现在库存表上。stock 表只存当前库存数量不存每次入库和出库的流水。课设阶段这样简化是合理的因为库存流水是另一个业务模块做进来会让工作量翻倍。但报告里最好能写一句系统目前只记录当前库存入库和出库流水作为后续扩展方向。主动交代边界比答辩时被老师问出来体面得多。3. 用 JDBC MySQL 跑通最小可用系统连接、事务扣库存和报表 SQL数据库设计完毕接下来就是把最少但完整的业务流程跑起来。界面形态看你选的课设方向Java Swing、JavaFX 或纯控制台都可以这里不贴界面代码重点讲三个最容易让系统“能用”和“不能用”的业务层环节连接配置、结账事务、报表查询。3.1 JDBC 连接配置驱动版本、连接串参数和连接关闭用一个DB工具类集中管理连接是最省事的做法。配置里最容易踩坑的有三个地方驱动类版本、URL 里的时间参数、连接关闭。import java.sql.Connection; import java.sql.DriverManager; import java.sql.SQLException; public class DB { // MySQL 8.x 的连接串 private static final String URL jdbc:mysql://127.0.0.1:3306/supermarket_db ?useUnicodetruecharacterEncodingutf8 useSSLfalse serverTimezoneAsia/Shanghai allowPublicKeyRetrievaltrue; private static final String USER root; private static final String PASSWORD 你的密码; public static Connection getConn() throws SQLException { return DriverManager.getConnection(URL, USER, PASSWORD); } }这段代码要解释清楚两个参数。characterEncodingutf8 管的是 Java 程序向 MySQL 写入中文时的编码转换调错就会出现第 5 章里说的中文乱码。serverTimezoneAsia/Shanghai 是 MySQL 8 的要求不指定的话如果 MySQL 服务端的时区和本机不一致会在连接时直接报时间字段异常。关于驱动类不同 MySQL 版本写法不同。MySQL 5.1 之前的驱动类名是com.mysql.jdbc.Driver从 MySQL 8 开始改成com.mysql.cj.jdbc.Driver而且 JDBC 4 以上版本会自动加载驱动大多数课程设计里手动写Class.forName(...)属于多余操作。真正容易出问题的是 pom.xml 里引的驱动版本和代码不匹配新代码配旧驱动报ClassNotFoundException的概率极高。连接关闭这件事十个同学里有一半会忘。每次getConn()都会向数据库申请一个连接用完了不关数据库连接池或服务端的最大连接数很快被打满系统运行十几分钟就报连接超时。解决办法就是服务层代码里养成在finally块中关闭连接的习惯最推荐用 try-with-resources 写法。public boolean login(String username, String password) { String sql SELECT COUNT(*) FROM staff WHERE login_name ? AND password ?; try (Connection conn DB.getConn(); PreparedStatement ps conn.prepareStatement(sql)) { ps.setString(1, username); ps.setString(2, password); try (ResultSet rs ps.executeQuery()) { rs.next(); return rs.getInt(1) 0; } } catch (SQLException e) { throw new RuntimeException(登录校验失败, e); } }注意这个登录查询里的两个细节SQL 使用?占位符而不是字符串拼接查询结果是 COUNT(*)不是直接把用户记录查出来比对。这两个细节在报告里可以专门讲参数化查询防止 SQL 注入COUNT 查询避免把密码等敏感字段暴露在结果集中。3.2 收银结账事务用行锁避免库存扣成负数收银结账是超市管理信息系统最核心的业务也是答辩老师很可能要求现场演示的环节。这个操作涉及两步扣库存、写订单明细。如果不用事务包裹会出现“库存已经扣了但订单明细写入失败”这种一半成功一半失败的情况。下面是结账逻辑的骨架重点看事务和锁是怎么用的。public boolean checkout(int orderId, ListCartItem cartItems) { Connection conn null; try { conn DB.getConn(); conn.setAutoCommit(false); // 关闭自动提交事务从这里开始 for (CartItem item : cartItems) { // 1. 锁定库存行防止两个收银台并发读到同一份旧库存 String lockSql SELECT qty FROM stock WHERE product_id ? FOR UPDATE; try (PreparedStatement ps conn.prepareStatement(lockSql)) { ps.setInt(1, item.getProductId()); try (ResultSet rs ps.executeQuery()) { if (!rs.next()) { throw new RuntimeException(商品不存在); } if (rs.getInt(qty) item.getQty()) { throw new RuntimeException(库存不足 item.getProductName()); } } } // 2. 扣减库存 String updateSql UPDATE stock SET qty qty - ? WHERE product_id ?; try (PreparedStatement ps conn.prepareStatement(updateSql)) { ps.setInt(1, item.getQty()); ps.setInt(2, item.getProductId()); ps.executeUpdate(); } // 3. 写入销售明细 String insertSql INSERT INTO sale_item(order_id, product_id, product_name, price, qty, amount) VALUES (?,?,?,?,?,?); try (PreparedStatement ps conn.prepareStatement(insertSql)) { ps.setInt(1, orderId); ps.setInt(2, item.getProductId()); ps.setString(3, item.getProductName()); ps.setBigDecimal(4, item.getPrice()); ps.setInt(5, item.getQty()); ps.setBigDecimal(6, item.getPrice().multiply(BigDecimal.valueOf(item.getQty()))); ps.executeUpdate(); } } conn.commit(); // 全部成功才提交 return true; } catch (Exception e) { if (conn ! null) { try { conn.rollback(); // 任何一个环节失败全部回滚 } catch (SQLException ex) { e.addSuppressed(ex); } } // 实际项目里这里应该把异常抛给界面层做提示 return false; } finally { if (conn ! null) { try { conn.close(); // 释放连接否则行锁会一直持有 } catch (SQLException e) { // 关闭失败通常不影响业务但不建议吞掉日志 } } } }三处代码对应三个必须能讲清楚的原理。第一setAutoCommit(false)是事务的开关不关自动提交每一条 SQL 执行完就不可回滚扣库存和写明细之间断电数据就找不回来。第二SELECT ... FOR UPDATE是悲观锁的写法它把这行库存记录锁住其他事务要修改这行时会等待锁释放课程设计阶段并发压力不大用悲观锁最直观代码逻辑也最好解释。第三conn.close()不只是归还连接也是释放锁的关键操作连接不关行锁会被一直占着其他窗口的结账操作会卡住这是非常经典的“界面无响应”原因。这里还有一个容易在答辩时被追问的点为什么不直接用一条带条件的 UPDATE 来扣库存比如UPDATE stock SET qty qty - ? WHERE product_id ? AND qty ?。这种写法也叫乐观扣减一条 SQL 就能完成判断和扣减性能更好。课程设计里选择先 SELECT 再 UPDATE是为了演示“检查库存不足”的界面提示代码阅读上更直观。报告里能主动提一句“生产环境更推荐条件 UPDATE”反而显得你有工程眼界。3.3 当日营业额和库存预警SQL 口径先定死代码只是执行者报表是管理信息系统区别于普通增删改查系统的标志。不需要做华丽图表能回答两个问题就够了今天卖了多少钱、哪些商品快卖完了。先看当日营业额查询。这里的口径必须严谨统计哪些订单是否包含作废订单时间范围怎么界定。SELECT COUNT(*) AS order_count, SUM(total_amount) AS sale_amount, ROUND(SUM(total_amount) / COUNT(*), 2) AS avg_order_amount FROM sale_order WHERE order_status 0 AND create_time 2026-01-05 00:00:00 AND create_time 2026-01-06 00:00:00;这段 SQL 的关键在时间条件。很多同学会写WHERE DATE(create_time) 2026-01-05功能上没错但一旦这张表的行数上万DATE()函数会让索引失效全表扫描。正确写法是让查询条件落在索引列上用左闭右开区间 2026-01-05 00:00:00 AND 2026-01-06 00:00:00把“当天”完整包进去。在代码里这个日期参数一般通过?传入不要把字符串拼进 SQL。库存预警查询则要用到 JOIN目标是把商品名称和库存数量对起来看。SELECT p.product_name, st.qty, st.safe_qty FROM stock st JOIN product p ON p.product_id st.product_id WHERE st.qty st.safe_qty ORDER BY st.qty - st.safe_qty ASC;这个查询的边界条件很清楚qty 小于安全库存的才显示。答辩时如果老师问“安全库存怎么定的”你可以回答这是商品补货的阈值目前由管理员维护将来可以按销量动态计算。把 SQL 里每个字段都对应到一句业务解释比背概念有用得多。4. 课程设计报告如何写得像一份工程交付结构、截图和测试用例的配合系统做完了报告写得好不好直接决定答辩时老师愿不愿意放你一马。课程设计报告不是毕业论文不要求深刻的学术洞见但要求逻辑自洽、证据可追溯。评判老师一般没有时间通读全文他会挑几个关键位置翻需求分析里的业务规则、数据库设计里的数据字典、系统测试里的用例表。这三部分写扎实了其余章节可以正常发挥。4.1 报告目录怎么定评审第一眼在看什么一份标准的课程设计报告目录通常包含需求分析、系统设计、数据库设计、系统实现、系统测试、总结体会、参考文献和附录。不要觉得这个结构老套它已经经受了多年答辩考验每一章对应评审老师一个关注点。报告章节内容重点评审老师的提问点需求分析角色划分、功能模块说明、业务流程描述你的系统边界在哪里为什么这样做系统设计系统架构图、模块划分、技术选型界面和业务逻辑有没有分层数据库设计ER 图、数据字典、建库 SQL表和实体是否对应外键是否合理系统实现核心界面截图、关键代码片段核心业务流程能不能跑通系统测试测试环境、测试用例表、结果截图你测没测过边界和异常情况总结体会完成的工作、遇到的问题、解决方案你在这个课题里真正动手做了多少用户最容易写空的是“总结体会”。常见写法是“通过本次课程设计我学会了……”这种套话。更有说服力的写法是把一个具体的踩坑经历写进去写“我在实现库存扣减时发现并发会让库存变负数最后用事务和行锁解决了”比十句空话都有用而且这条经验可以自然衔接第 5 章的避坑清单。4.2 测试用例表是答辩的“后悔药”预期和实测必须成对出现答辩演示翻车后老师通常会问“你测试过这个场景吗”这时你在测试用例表里有这一条就能把局面救回来。测试用例表不需要多覆盖正常流程和关键异常流程即可五到八条足够。下面是一张可以直接改用的测试用例表模板用例编号操作步骤预期结果实测结果是否通过TC-01未输入账号直接点击登录提示“账号不能为空”焦点停在账号输入框同预期通过TC-02输入正确账号密码登录进入主界面状态栏显示当前收银员同预期通过TC-03商品 A 库存 10 件购物车加 12 件后结算提示“库存不足”不生成订单库存不变同预期通过TC-04正常结算一件商品库存减少销售明细生成销售额统计变化同预期通过TC-05查询 2026-01-05 的营业额显示对应日期的订单数和合计金额同预期通过写完表格后再配上两张关键截图库存不足时的提示弹窗以及结账成功后数据库里 sale_order 和 sale_item 的实际记录。注意截图要对应起来不能报告里写“库存不变”截图上却是负数。4.3 截图与代码的对应关系防止“两张皮”报告中贴代码和贴截图的通病是各说各话代码里写的逻辑和截图上看到的状态对不上。最常见的情况是报告里的建表 SQL 写了DECIMAL(10,2)但界面上显示合计金额时截图的数字却带有很长的小数尾数老师一看就知道代码和文档不是同一套。预防办法是交付前花十分钟做一次“对应检查”每个核心界面截图都在数据库里找到它对应的数据每段贴出来的核心代码都用一行注释说明它产生了截图中哪一部分结果。比如结账类的截图旁边配一段话“本次演示为商品 A 结算 3 件库存从 10 更新为 7对应 sale_item 表中新增一条 amount单价的记录。”这种把界面、代码、数据三者对齐的做法答辩时会让老师觉得你的报告工程质量很高。5. 避坑清单超市系统最常见的 5 个翻车现场这一章列出的问题基本是我在课程设计代码里反复看到的高频坑。每一条按“现象 → 原因 → 解决”的路径排查答辩前对照自查一遍能挡掉八成现场故障。5.1 中文乱码连接串没指定 utf8或库表字符集不统一现象商品名称、会员姓名里只要有中文存入数据库就变成问号?或者显示成乱码。原因Java 程序、MySQL 连接、数据库表三者的字符集不一致。最常见的是建库时没指定字符集MySQL 默认落到了 latin1或者连接串里少了 characterEncodingutf8。解决把三层统一成 utf8mb4。建库语句用DEFAULT CHARACTER SET utf8mb4连接串加characterEncodingutf8如果表已经建好了执行ALTER TABLE product CONVERT TO CHARACTER SET utf8mb4;。做这三步之后再重新插入中文测试别在乱码数据上直接改先清掉脏数据。5.2 并发结账把库存扣成负数事务开了锁却没加现象两个收银窗口同时结算“最后一件商品”两张销售单都成功了库存变成负数。原因代码里虽然用了事务但只是先 SELECT 查库存再 UPDATE 扣库存。两个事务同时读到库存为 1都判断“够卖”各自执行扣减最终变成 -1。关键缺失是查询和扣减之间没有做任何并发控制。解决在查询库存的 SQL 后面加FOR UPDATE让第一个事务锁定这行记录第二个事务只能等锁释放。如果不想用显式锁也可以用条件更新UPDATE stock SET qty qty - ? WHERE product_id ? AND qty ?受影响行数为 0 就表示库存不足。课设代码选择前者逻辑更直观答辩时也更好讲。5.3 营业额出现 0.30000000000000004浮点数不能直接存金额现象结算两件 0.1 元的商品界面显示合计为 0.30000000000000004而不是 0.30。原因Java 的 float/double 和 MySQL 的 FLOAT/DOUBLE 类型都采用二进制浮点存储0.1 在二进制里是无限循环小数计算时必然产生精度误差。这不是 bug是数值表示方式导致的现象。解决数据库字段统一用DECIMAL(10,2)Java 代码里用BigDecimal做金额计算不要用 double 接收数据库返回的值。注意 BigDecimal 构造时用字符串new BigDecimal(0.1)才对直接new BigDecimal(0.1)会把浮点误差带进来等于白改。5.4 删除商品时报外键失败有销售记录的商品不能硬删现象管理系统里想删掉某个商品系统弹窗提示 “Cannot delete or update a parent row”删除失败。原因该商品的 product_id 已经被 sale_item 表引用外键约束不允许删掉父表记录。从业务上说这也是对的历史销售明细里应该保留这个商品的名称和价格硬删会让历史报表失去意义。解决不要把删除做成物理删除。正确做法是逻辑删除在 product 表里加一个 status 字段默认 1 表示正常点击“删除”时把它置为 0查询商品列表时统一加过滤条件WHERE status 1。报告里把这个设计写成“商品的逻辑删除机制”反而能体现你理解了外键约束的价值。5.5 日结报表少了凌晨的订单日期比较的边界没算清现象报表统计的是最近 24 小时但凌晨 00:05 的订单没有被统计进当天数据里。原因查询条件写成了WHERE create_time 2026-01-05或者BETWEEN 2026-01-05 00:00:00 AND 2026-01-05 23:59:59。前者把 datetime 列和日期字符串直接比较MySQL 会做隐式转换00:05 的订单匹配不上后者漏掉了 23:59:59 到次日 00:00:00 之间的那 1 秒。解决日期区间统一用左闭右开写法 2026-01-05 00:00:00 AND 2026-01-06 00:00:00把判断条件写到索引列上既完整又高效。在程序里如果要做“当天”报表用?传入当天零点另一个参数用DATE_ADD(当天, INTERVAL 1 DAY)。6. 答辩前一夜按这套流程走一遍复位脚本、预演失败路径、备份系统离验收只剩一天时不要再写新功能了把时间花在“让演示稳定”上。我的习惯是准备一个 demo 复位脚本核心只有两句清空销售数据把库存重置成演示起点。-- demo_reset.sql演示前执行恢复干净数据 DELETE FROM sale_item; DELETE FROM sale_order; UPDATE stock SET qty 50;这样做的原因是答辩现场最怕的不是代码不会跑而是演示到一半数据乱了上午试了几次结账库存成了零散数字报表跟实际演示流程对不上。复位脚本一执行所有验证数据都在掌握中系统像刚装好一样干净。演示顺序也要预演我建议固定为登录 → 商品管理 → 收银结账 → 查看库存变化 → 查询当日报表 → 数据库端验证数据。这个顺序是层层递进的先证明系统能进再证明能管接着证明关键业务能跑最后用报表和数据库记录证明数据落库正确。另外值得花十分钟的是“预演一次失败路径”。比如故意让某件商品超出库存数量去结算让系统弹出“库存不足”再去数据库里确认没有生成脏数据。这个演示的答辩价值比你预想的高它直接验证了业务规则和事务回滚老师会认为你的系统考虑了异常场景。这也是我吃过亏之后留下的习惯宁可自己在答辩前翻一次车也不要把翻车留给现场。备份层面上把数据库导出一份 SQL 文件、把项目代码打一个压缩包放在桌面是再基本不过的动作。更实用的一点是答辩前一晚永远不要改功能、不要调边界参数要改就改演示数据。全新代码最后一晚最容易引入新 bug这是很多人的血泪经验。把数据复位、把失败路径预演一遍、把备份留好这套动作做完系统的行为就在掌控之中了不靠玄学。希望这篇笔记能帮你把课程设计做成一件确定的事。本文还有配套的精品资源点击获取