二手房交易管理系统数据库设计：从ER图到SQL实现全攻略

简介这份doc文档是围绕“二手房交易管理系统”数据库概论课题设计的完整方案面向软件工程、数据库课程设计及毕业设计学生重点解决二手房交易中数据分散、供需信息滞后、决策缺乏依据等问题。内容从数据库基础概念入手逐步展开关系数据库的表结构设计涵盖房产信息、客户信息、交易记录、市场供需数据等核心表并给出数据集中管理、报表生成与智能决策支持模块的设计思路同时涉及基于Web的系统架构与需求分析章节结构清晰便于直接参考或改造。资源包仅包含1个doc文件大小约895KB属于轻量但成体系的课题设计文档。目前已有334人学习下载可作为数据库概论课程设计、系统分析文档撰写及答辩准备的实用范例。1. 二手房交易管理系统数据库概论课题设计从ER图到课设答辩的完整闭环数据库概论课设向来是计算机相关专业绕不开的一关而“二手房交易管理系统”是这类课设里出现频率最高的题目之一——因为它业务边界清晰、实体关系自然能很好地覆盖数据库概论课程的核心考点概念模型设计ER图、关系模式转换1NF到3NF、完整性约束、SQL编程、事务处理以及并发控制。它的实用价值在于你最终交出去的不能只是一张ER图和几段建表语句而是一个能演示、能答辩、能经得起老师现场查数据的完整系统。这套方案会直接告诉你什么是“能过”的课设——从数据建模到建库脚本再到业务层的增删改查和事务处理。网上关于这个题目的源码包很多但多数是半成品要么只有建表脚本没有业务数据要么ER图和表结构对不上。这篇文章按照一个做了多年数据库项目的从业者视角把从ER模型设计到SQL实现的完整路径拆给你看包含具体的表结构、可运行的建库脚本、典型业务查询的事务写法以及那些让新手翻车的边界坑。无论你是要自己写课设还是手里有源码包但要修改成自己的版本这套逻辑都通用。数千字层层推进每一步都有可直接复制的代码和参数说明按照这套流程做完数据库部分能立于不败之地。2. 概念模型先行二手房交易管理的实体识别与ER图设计房客源三要素是根基2.1 先画清楚核心实体房源、客源、成交记录为什么一个都不能少做任何数据库设计第一步都是回答一个问题我的业务系统里有哪些独立存在且需要保存信息的事物对于一个二手房交易管理系统最核心的实体就是房子、客户、员工经纪人、成交记录。其中房子和客户这两类实体天然具备“信息载体”属性——房子有户型、面积、楼层、朝向、价格、装修、产权性质客户有购房需求、预算范围、带看历史。这个业务的天然优势在于它是强结构化的房地产领域的字段是稳定的不会像推荐系统那样经常要动态加字段。我一个常见做法是把“房客源”拆成三个核心实体再加上员工和合同一共五个基表然后把多对多关系带看记录、收藏记录抽成中间表。这里要解释一下为什么“成交记录”必须单独设计成一个实体而非房源的一个字段。房源表里可以把状态标记为“已成交”但完整的交易信息——成交价、成交时间、中介费比例、买方、卖方——是典型的时变性业务数据把它塞在房源表里会导致大量空字段和重复存储不符合范式要求。成交记录应该独立成表与房源形成一对一或一对多的引用关系这才是规范化设计。ER图的绘制工具选择上用draw.io或者PowerDesigner顺手就用把实体框、属性列表、联系类型1:1、1:N、M:N标清楚。有一个值得强调的细节如果你不先在ER图上画出联系直接跳到建表脚本科目极大概率会漏掉中间表。我见过的成品中带看记录被挂在客户表下面的占了四成这会在后续做关系规范化时翻车。2.2 从ER图到关系模式1NF到3NF的转换过程与字段展开ER图画完之后下一个关键步骤是把实体图和联系图转成关系模式。这一步在课设文档里占的篇幅极大也是老师爱在答辩时抽查的阶段。有经验的工程师会建议你在转换时严格走以下流程把每个实体转换为一个关系模式包含该实体的所有属性把1:N联系在“N”端加入“1”端的主键作为外键把M:N联系单独抽成关系模式主键是两端主键的复合键检查每个关系模式是否满足3NF——即所有非主属性对码完全函数依赖且没有传递依赖。二手房的字段天然适合做这个论证比如房屋面积、朝向和房屋编号是完全依赖而“小区均价”依赖“小区名”“小区名”依赖“房屋编号”它就是一个传递依赖需要拆出“小区”表。类似地“经纪人所属门店”若它在员工表里和员工号存在传递依赖也应该拆分。这里给出一张户型信息的最小关系模式示例表格方便你直接写进课设文档关系模式字段内容主键外键满足的范式房屋信息房源编号、小区编号、户型、面积、楼层、朝向、装修、售价、状态房源编号小区编号3NF小区信息小区编号、小区名称、区域、建筑年代、均价小区编号无3NF客户信息客户编号、姓名、电话、购房预算、需求描述、登记时间客户编号无3NF经纪人工号、姓名、电话、所属门店工号无3NF带看记录带看编号、房源编号、客户编号、工号、带看时间、反馈带看编号房源编号、客户编号、工号3NF成交记录成交编号、房源编号、客户编号、工号、成交价、成交日期、中介费率成交编号房源编号、客户编号、工号3NF上面的表格每一条都可以在课设说明里占据分析篇幅尤其是外键约束的表达和级联更新策略后面建表时你会直接用到它。2.3 关系模式要落成表结构字段类型选择与长度设计的现实约束设计表结构时新手常犯的两个错误是过度设计字段长度和随意选择数据类型。这里给出一套针对这个领域的通用取值参考直接套用即可。房屋面积用 DECIMAL(5,2)处理两位小数价格用 DECIMAL(10,2) 或 BIGINT如果你不希望程序里因为浮点误差翻车用BIGINT存“万元×100”整数也可以容积率、单价这类用DECIMAL(4,2)日期时间字段一律用DATETIME而不是TIMESTAMP这样可以避开2038年问题。你问到为什么要这样选核心是业务场景约束二手房价格动辄数百万精度至少要精确到分FLOAT在这里是不合格的。字符串字段要谨慎区分变长和定长。手机号码 CHAR(11) 和证件号 CHAR(18) 这类长度固定的用CHAR地址 VARCHAR(200)、描述 TEXT这些用变长类型。有一个常见的坑在于VARCHAR在MySQL里的不会保留尾部空格而CHAR会如果你用VARCHAR(20) 存“北京海淀”和“北京海淀 ”会出现两条数据查起来一样但实际不同这会在后续处理数据去重时翻车。另外一个重要决定是否使用自增ID主键。房产交易领域里业务上有自然键房屋编号如“FY20240001”但这里不要直接用自然键作为主键用自增ID做主键、自然编号建立唯一索引。这个选择的理由在于自然键如果后面发现重复或者允许修改会引发连锁更新而代理主键可以让你放心地对业务字段随便改不会破坏引用关系。这套思路同样适用于设计客户编号。3. 从ER到机器能跑的表用SQL DDL在MySQL里建出完整的二手房表结构3.1 最小建库脚本数据库初始化与字符集选择的玄学设计完了逻辑模型现在我们开始落到MySQL。你完全可以把这套代码原样跑一遍它是一套完整的建库方案包含数据库、五张核心表以及所有外键约束。-- 创建数据库指定utf8mb4字符集 CREATE DATABASE IF NOT EXISTS house_trade_db DEFAULT CHARACTER SET utf8mb4 DEFAULT COLLATE utf8mb4_unicode_ci; USE house_trade_db; -- 小区表 CREATE TABLE community ( community_id INT AUTO_INCREMENT PRIMARY KEY, community_name VARCHAR(100) NOT NULL, district VARCHAR(50) NOT NULL COMMENT 所在区域, built_year SMALLINT NULL COMMENT 建筑年代如2008, avg_price DECIMAL(10,2) NULL COMMENT 小区挂牌均价单位元/平米 ) ENGINEInnoDB; -- 房屋信息表 CREATE TABLE house ( house_id INT AUTO_INCREMENT PRIMARY KEY, house_no VARCHAR(30) NOT NULL COMMENT 房屋自然编号如FY20240001, community_id INT NOT NULL, layout VARCHAR(30) COMMENT 户型如3室2厅, area DECIMAL(5,2) COMMENT 建筑面积平米, floor_info VARCHAR(20) COMMENT 楼层信息, orientation VARCHAR(10) COMMENT 朝向如南, decoration VARCHAR(10) COMMENT 装修情况, total_price DECIMAL(10,2) COMMENT 挂牌总价万元, status TINYINT DEFAULT 0 COMMENT 0-在售1-已成交2-下架, created_at DATETIME DEFAULT CURRENT_TIMESTAMP, UNIQUE KEY uk_house_no (house_no), CONSTRAINT fk_house_community FOREIGN KEY (community_id) REFERENCES community(community_id) ) ENGINEInnoDB;这段脚本的核心在于三点库字符集统一为utf8mb4对应楼盘名、户型里的生僻字不会出现乱码主键全部用INT自增代理键外键约束命名带前缀fk_方便后续排查约束冲突时快速定位。唯一索引放在房号house_no这种业务唯一字段上与代理主键不冲突。注意SMALLINT足够存年份不要用INT浪费空间这类细节在课设答辩时提出来会加分。3.2 建客户、经纪人与带看表复合主键与外键级联策略的参数说明继续把业务支撑表完整建出来。这里要处理好带看记录这个M:N关系的中间表设计以及对删除策略的决策。-- 客户表 CREATE TABLE customer ( customer_id INT AUTO_INCREMENT PRIMARY KEY, cust_name VARCHAR(50) NOT NULL COMMENT 客户姓名, phone CHAR(11) NOT NULL, budget_min DECIMAL(10,2) COMMENT 心理预算下限万元, budget_max DECIMAL(10,2) COMMENT 心理预算上限万元, requirement VARCHAR(500) COMMENT 购房需求描述, reg_time DATETIME DEFAULT CURRENT_TIMESTAMP, UNIQUE KEY uk_customer_phone (phone) ) ENGINEInnoDB; -- 经纪人表 CREATE TABLE agent ( agent_id INT AUTO_INCREMENT PRIMARY KEY, agent_name VARCHAR(50) NOT NULL, phone CHAR(11) NOT NULL, store_name VARCHAR(100) COMMENT 所属门店, hire_date DATE ) ENGINEInnoDB; -- 带看记录表M:N关系独立成表 CREATE TABLE visit_record ( visit_id INT AUTO_INCREMENT PRIMARY KEY, house_id INT NOT NULL, customer_id INT NOT NULL, agent_id INT NOT NULL, visit_time DATETIME NOT NULL, feedback VARCHAR(500) COMMENT 客户带看后反馈, CONSTRAINT fk_visit_house FOREIGN KEY (house_id) REFERENCES house(house_id) ON DELETE CASCADE, CONSTRAINT fk_visit_customer FOREIGN KEY (customer_id) REFERENCES customer(customer_id) ON DELETE CASCADE, CONSTRAINT fk_visit_agent FOREIGN KEY (agent_id) REFERENCES agent(agent_id) ON DELETE RESTRICT, KEY idx_visit_time (visit_time) ) ENGINEInnoDB;级联策略的选择需要说明。带看记录是流水型数据当房源或客户被删除时历史带看记录没有保留意义所以用CASCADE级联删除经纪人属于公司人事基础数据删除时如果有带看记录关联应当报错禁止删除RESTRICT否则会出现带看记录找不到经纪人的孤儿数据。客户表用了UNIQUE约束在phone字段上这是业务级约束防止同一客户重复录入。带看时间建立了普通索引这个索引在“查询某时间段带看量”的统计类需求中优势明显若不建索引这类的查询会走全表扫描。3.3 成交记录表设计连接房客源三方把交易快照保存住成交表是整个系统的核心因为它在相对稳定的房客源数据之上记录了一次性事件。数据库概论课设里的一个关键考点是“交易快照”——成交价格不一定等于挂牌价格客户可能有议价中介费也有折扣因此成交表必须保存完整快照数据。-- 成交记录表 CREATE TABLE deal ( deal_id INT AUTO_INCREMENT PRIMARY KEY, house_id INT NOT NULL, customer_id INT NOT NULL, agent_id INT NOT NULL, deal_price DECIMAL(10,2) NOT NULL COMMENT 实际成交价万元, list_price DECIMAL(10,2) NOT NULL COMMENT 成交时的挂牌价万元, commission_rate DECIMAL(3,2) DEFAULT 0.02 COMMENT 中介费率如0.02表示2%, commission_amt DECIMAL(10,2) GENERATED ALWAYS AS (deal_price * commission_rate) STORED, deal_date DATETIME NOT NULL, CONSTRAINT fk_deal_house FOREIGN KEY (house_id) REFERENCES house(house_id), CONSTRAINT fk_deal_customer FOREIGN KEY (customer_id) REFERENCES customer(customer_id), CONSTRAINT fk_deal_agent FOREIGN KEY (agent_id) REFERENCES agent(agent_id), KEY idx_deal_date (deal_date) ) ENGINEInnoDB;上面代码中有一个值得在答辩时展开讲的知识点佣金金额这一列用到了MySQL 8.0的生成列GENERATED ALWAYS AS ... STORED它的好处是佣金金额永远等于成交价乘以费率且计算在数据库内部完成不会出现应用层Java或Python算出错误结果导致账实不符。GENERATED列表达式里的系数用了DECIMAL不会有二进制浮点误差。这里顺带埋了一个谈资如果老师问到“为什么不用触发器”你可以回答生成列的执行时机是在写入行数据时计算比触发器更直接高效且不会像触发器那样产生隐式逻辑层的额外开销。4. 让业务跑起来的增删改查用视图和存储过程把数据库概论的知识点真正用起来4.1 视图设计简化复杂查询给前端一个干净的接口层数据库概论课设要求中明确包含了“数据库编程”和“数据查询”两大考核点。直接用SQL写联表查询是可以的但视图在这种场景下价值非常明显它把复杂的多表JOIN封装成一个虚拟表让应用层只关心“我要房源列表”不关心它背后关联了多少张表。-- 创建房源信息视图房屋小区信息联表展示 CREATE VIEW v_house_info AS SELECT h.house_id, h.house_no, c.community_name, c.district, h.layout, h.area, h.floor_info, h.orientation, h.decoration, h.total_price, h.status, -- 每平米单价 ROUND(h.total_price * 10000 / h.area, 2) AS unit_price FROM house h JOIN community c ON h.community_id c.community_id WHERE h.status 0; -- 只展示在售房源用这个视图让前端支起最核心的房源列表页只查一张v_house_info就能拿到全部展示信息而不用每次写JOIN而且它会自动过滤掉已下架房源。有人问“直接建一个只包含在售状态的理由是什么”这是基于业务约束前端除非在后台管理页否则用户不该看到已成交或下架房源。把这个条件放在视图里而非应用层能防止各个开发人员各写一套过滤条件导致结果不一致。接下来创建带看记录统计视图也许是你会在课设里被问到“聚合查询”时的有力武器-- 经纪人带看统计视图 CREATE VIEW v_agent_visit_stats AS SELECT a.agent_id, a.agent_name, COUNT(v.visit_id) AS visit_count, COUNT(DISTINCT v.customer_id) AS customer_count FROM agent a LEFT JOIN visit_record v ON a.agent_id v.agent_id GROUP BY a.agent_id, a.agent_name;COUNT(DISTINCT customer_id)统计去重后的客户数避免同一客户多次带看被重复计算。LEFT JOIN这里至关重要它保证了没有带看记录的经纪人也会出现在结果里计数为0否则这些经纪人会从统计列表中消失导致“没带看的人不露面”的统计失真。4.2 存储过程实战新增房源的事务完整性保证存储过程是课设又一个加分点。在MySQL中通过事务控制可以演示“原子性”概念新增房源时同时要新增一条小区记录若小区不存在两步操作要么同时成功、要么同时失败。用存储过程实现可以封装事务边界应用层只需调用一个CALL语句且不会因为业务代码层面的失败造成数据残废。DELIMITER $$ CREATE PROCEDURE sp_add_house( IN p_house_no VARCHAR(30), IN p_community_name VARCHAR(100), IN p_district VARCHAR(50), IN p_layout VARCHAR(30), IN p_area DECIMAL(5,2), IN p_total_price DECIMAL(10,2) ) BEGIN DECLARE v_community_id INT; DECLARE EXIT HANDLER FOR SQLEXCEPTION BEGIN ROLLBACK; RESIGNAL; END; START TRANSACTION; -- 查找小区不存在则新建 SELECT community_id INTO v_community_id FROM community WHERE community_name p_community_name LIMIT 1; IF v_community_id IS NULL THEN INSERT INTO community(community_name, district) VALUES (p_community_name, p_district); SET v_community_id LAST_INSERT_ID(); END IF; -- 插入房源记录 INSERT INTO house(house_no, community_id, layout, area, total_price) VALUES (p_house_no, v_community_id, p_layout, p_area, p_total_price); COMMIT; END$$ DELIMITER ;这个存储过程的逻辑要点SQLException处理程序捕获任何SQL异常后回滚并用RESIGNAL把错误传递回客户端这样应用层能感知失败原因不会“静默失败”小区查找和新增之间有一个数据窗口如果两个会话同时传入同名但不同小区可能产生重复记录。这里利用UNIQUE约束兜底即给community_name加唯一索引来防止重复。最后注意分隔符切换DELIMITER $$是MySQL客户端的语法要求是为了让整个存储过程体作为一个整体被提交如果用图形客户端Navicat执行可以忽视它但命令行时必须保留。4.3 事务隔离级别的课设讲解演示并发更新丢失与行锁用数据库概论课设的“并发控制”知识把以下事务代码放进你的课题设计文档能明显提升技术深度。MySQL的InnoDB默认隔离级别是REPEATABLE READ可重复读。在这个级别下两个事务同时改同一行数据时后者会阻塞等待前者提交。这就是行级锁机制。-- 会话A为客户1锁定房源1001 START TRANSACTION; UPDATE house SET status 2 WHERE house_id 1001; -- 此时不提交模拟业务处理过程 -- 会话B另一操作员尝试同样更新 START TRANSACTION; UPDATE house SET status 2 WHERE house_id 1001; -- 此处会等待直到会话A COMMIT或ROLLBACK这种现象要配合程序演示给老师看才直观。启动两个MySQL命令行窗口第一个窗口执行上面的UPDATE不提交第二个窗口执行相同UPDATE你会看到它一直卡住等待锁释放。这个操作在课设答辩现场堪称“玄学级”高光时刻——多数小组只展示增删改查你能现场演示锁等待说明你是真正理解数据库知识并动手验证过的。这里有一个额外的血泪经验如果你在会话A的执行窗口里执行了UPDATE但忘了COMMIT直接把窗口关掉InnoDB会自动回滚事务锁会被释放等锁的会话B才有机会继续。这点如果不敢确认宁可把事务代码晾在一边不做并发演示也不要现场卡住自己下不了台。5. 课设翻车重灾区数据库设计与实现中最常见的5个坑与排查路径5.1 坑一MySQL 8.0的认证插件导致客户端连接报错现象明明在数据库服务器上通过命令行能连接用Navicat或JDBC连却报错“Authentication plugin caching_sha2_password cannot be loaded”。原因MySQL 8.0默认创建用户的认证插件是caching_sha2_password而大多数图形客户端和旧版驱动只实现mysql_native_password。很多同学拿到旧教程直接抄建库语句数据库是8.0的工具是5.7时代的连接自然失败。解决创建用户时显式指定插件或者将已有用户ALTER过去。-- 创建用户时指定插件方式 CREATE USER house_userlocalhost IDENTIFIED WITH mysql_native_password BY your_password; -- 对已存在用户修改 ALTER USER house_userlocalhost IDENTIFIED WITH mysql_native_password BY your_password; FLUSH PRIVILEGES;这个配置在课设文档的“运行环境”章节里写明老师按文档部署时一次成功会给你不少印象分。5.2 坑二外键约束导致删除失败直接DROP掉了重建现象删除小区编号1时提示“Cannot delete or update a parent row: a foreign key constraint fails”于是直接DROP TABLE重建一张数据全没了。原因在2.3节设计里当父表有子表引用时删除受限这是外键默认约束行为RESTRICT/NO ACTION防止产生孤儿数据。部分学生在遇到外键阻塞后选择“删库跑路”这是最原始的处理方式。解决理解业务删除前先处理子表数据——解绑关联、转移房产归属或按设计时的级联策略有意识地执行清空操作。正常顺序是先DELETE子表记录visit_record、deal中的相关行再DELETE父表。如果你的设计是ON DELETE CASCADE那直接删父表会自动删子表但前提是你必须知道哪些表存在级联依赖。5.3 坑三数据库字符集不一致引发中文乱码现象界面程序里输入中文地址和房源描述存入数据库后用SQL查询看到一串“????”。原因LATIN1字符集在接收UTF-8应用层数据时无法存储中文。多数发生在建库语句没有写DEFAULT CHARACTER SET utf8mb4而MySQL服务端默认是latin1的情况下。解决数据库、表、字段三层级联统一。最彻底的方案是建库时就同步规划好如3.1节脚本所示已经建好的库可以修改-- 修改库默认字符集 ALTER DATABASE house_trade_db CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; -- 修改已经建错的表 ALTER TABLE house CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;CONVERT TO会连字段类型一起变更不需要逐列ALTER。如果连接层还乱码再在JDBC地址后面加characterEncodingUTF-8参数。从此彻底告别乱码课设演示时不用临时清屏查数据。5.4 坑四导出SQL脚本时少了一句DataBase语句现象把数据库迁移到另一台电脑导入课设脚本时直接报错“No database selected”。原因导出工具默认不生成CREATE DATABASE语句直接导出表结构。你新建的数据库名如果不和数据里的表一致就会出错。解决导出前手工写上这两行或者导入时先建立同库名数据库。CREATE DATABASE IF NOT EXISTS house_trade_db DEFAULT CHARACTER SET utf8mb4; USE house_trade_db;教师在部署你这个课设时最容易碰到的就是这个问题。脚本最前面带上这两句能让他拿到压缩包后“一步到位”完成部署这种经验是你的加分项。5.5 坑五面积、价格字段用了FLOAT聚合计算结果对不上现象AVG(total_price)算出来的均价是9999.99999999而不是整齐的10000.00。原因FLOAT是浮点类型在二进制下无法精确表示所有十进制小数。多次累加聚合计算时误差累积明显。数据库概论课一般会讲但容易被人忽略实际操作中大量同学直接把Excel里的类型搬进MySQL坏习惯由此生根。解决金额、面积、费率这三个对精度敏感的字段统一用DECIMAL。这也是课设老师最爱抓的一个点一份表结构里出现FLOAT用于价格会被认为“规范意识不到位”。按照2.2节的参数表来选型能在设计文档阶段就避免这个坑。6. 课设加分项实操把索引优化和ER图导出做成可视化文档让答辩无懈可击这部分值得你花一小时单独打磨。当我一次次被学生问“怎么才能让课设分数高一点”时答案出奇地一致——不是代码有多炫而是“文档、代码、演示三者的对应关系清晰解释得通”。这里给你两件事照着做就能把课设成品质量明显提升。第一件事做一次例如用EXPLAIN分析慢查询并在文档中附上前后对比。-- 未加索引时的执行计划 EXPLAIN SELECT * FROM visit_record WHERE visit_time 2024-01-01; -- 添加索引后的执行计划 CREATE INDEX idx_visit_time ON visit_record(visit_time); EXPLAIN SELECT * FROM visit_record WHERE visit_time 2024-01-01;未加索引时你会看到typeALLrows会显示全表行数加索引后type变为rangerows大幅度减少。这个对比数据放在设计文档的“性能分析”章节比任何文字说明都有说服力。第二件事从数据库实时导出ER图。用MySQL Workbench的“Reverse Engineer”功能可以直接从你建好的库里生成ER图保证“文档里的图和实际库结构完全一致”。这是最常被我用来揪出的“文档和代码不一致”的裁分点——不少同学手工画的ER图和实际落地的表结构有两三个字段对不上答辩时老师一对照就尴尬了。最后一章里我个人最坚持的习惯是课设代码提交前做一次全量删库重跑。把数据库DROP掉用你的脚本从零开始完整执行一遍插入测试数据后跑一遍所有业务查询。每次有人问我课设怎么查缺补漏我就让他这么做。你会发现那些“在Navicat里随手点的修改”根本没同步进脚本数据库重建后功能直接崩了。这个习惯是我若干年前第一次做系统课设时用一次翻车换回来的血泪经验现在每走一个项目我都会在交付前完成一轮这样的“零基重建”验证。这个流程你固化成自己的习惯它不只是在保护课设分数也在保护将来你真正交付商业项目时的可靠性。希望帮到你。本文还有配套的精品资源点击获取