简介：本资源是一份完整的数据库课程设计实践材料，面向高校计算机、软件工程及相关专业本科生，解决数据库原理与应用课程中系统化项目实训缺失的问题。资源包含1个RAR压缩包（2.96MB），内含核心SQL建库建表脚本、可直接运行的完整源代码及规范化的Word课程设计报告模板，覆盖从数据库设计、权限控制到前后端功能实现的全流程。已有5059人学习下载，说明其在教学实践中的广泛认可度。使用者可直接导入SQL文件快速构建学生宿舍管理数据库，基于源代码理解多角色权限分离（寝室长/宿管员）的登录验证与功能分层逻辑，并参照Word模板完成符合高校课程要求的文档撰写；数据库表结构清晰合理，含寝室长、宿管员、学生、报修四类主表，支持按学号检索、批量增删、状态更新等典型业务操作，具备良好的教学示范性与工程延展性。
1. 学生宿舍管理系统：不是堆功能，而是用数据库思维把“人、房、调、查”四件事闭环落地
你手头正赶着交数据库课设，打开文档写着“学生宿舍管理系统”，但心里发虚——到底该做多大？字段怎么设才不被导师问住？SQL 文件写完一运行就报错主键冲突？Word 报告里画个ER图像涂鸦，表关系说不清，连“为什么宿舍表要拆成楼栋+房间号两个字段”都答不上来？这不是你一个人的问题。我带过三届数据库课程设计指导，最常看到的翻车现场是：学生花两周写了个带登录界面的Java程序，结果核心的“学生换寝流程”在数据库里根本没建约束，导致同一间房能录入5个学生；或者SQL脚本里全是INSERT硬编码，没有外键、没加索引、没写事务，答辩时导师只问一句“如果张三退宿又立刻入住隔壁床，数据一致性怎么保证？”，当场卡壳。
这套资源不是给你一个“能跑就行”的Demo，而是一套从需求反推表结构、用范式驱动字段设计、靠事务兜底业务逻辑、最后用Word模板把设计过程讲清楚的完整交付物。它适合两类人：一是正在写课设但卡在“不知道数据库该管什么”的学生，二是需要快速出一份可答辩、可复用、能体现数据库工程思维的毕设初稿的准毕业生。它不教SQL语法，但告诉你每一行CREATE TABLE背后的真实业务重量；它不提供炫酷前端，但确保你导出的SQL文件在MySQL 8.0+和Navicat里双环境验证通过；它给的Word模板不是填空题，而是按“需求分析→概念设计→逻辑设计→物理设计→测试用例”五段式展开，每一段都预留了你手写批注、贴截图、补思考痕迹的位置。
2. 需求解构与范式驱动：从“学生住哪”到第三范式的四层推演
2.1 真实业务场景切片：宿舍管理不是静态台账，而是动态生命周期
很多同学一上来就建“学生表”“宿舍表”“管理员表”，然后用JOIN连起来——这叫“能连上”，不叫“管得住”。我们先拆解宿舍管理中四个不可回避的刚性动作：
- 入住登记：新生报到，分配床位（需校验该房间是否满员、是否已锁定维修）；
- 调寝申请：学生提交换寝请求（需关联原宿舍、目标宿舍、审批状态、调寝原因）；
- 退宿办理：毕业/休学/转专业，释放床位（需同步更新房间状态、生成退宿记录）；
- 日常巡查：管理员巡检，记录卫生评分、违规情况（需绑定具体房间、日期、责任人）。
这四个动作共同指向一个事实：宿舍不是静态资源，而是带状态机的实体。房间有“空闲/已住/维修中/待清洁”四种状态；学生有“在住/已调出/已退宿”三种状态；调寝流程有“待审批/已通过/已驳回/已执行”四类流转。这些状态不能靠代码if-else硬控，必须沉淀为数据库字段，并用CHECK约束或状态码表固化。
提示：别急着建表。先拿一张纸，把上面四个动作各自涉及的“谁、什么时候、做了什么、影响了哪些数据”列成表格。你会发现，“调寝”这个动作天然需要三张表联动：
student（申请人）、dorm_assignment（原分配记录）、dorm_application（新申请单）。这就是ER图里“弱实体”和“联系实体”的真实来源。
2.2 从第一范式到第三范式：字段拆分不是炫技，是堵死数据冗余的后门
我们以“宿舍信息”为例，看范式如何落地：
反模式（未范式化）：
dorm_info(id, dorm_name, floor, room_no, capacity, current_occupancy, building_name, building_address)
问题：building_name和building_address在整栋楼所有房间重复出现；current_occupancy是计算字段，不应直接存储。第二范式改造（消除部分依赖）：
拆出building表：building(id, name, address, manager_id)dorm_room表：dorm_room(id, building_id, floor, room_no, capacity, status)
此时dorm_room.building_id→building.id，building.address不再重复。第三范式加固（消除传递依赖）：
status字段若直接存“空闲/已住/维修中”，未来加新状态要改代码；更健壮做法是建dorm_status码表：CREATE TABLE dorm_status ( id TINYINT PRIMARY KEY, status_name VARCHAR(20) NOT NULL UNIQUE, description VARCHAR(100) ); INSERT INTO dorm_status VALUES (1, '空闲', '可分配床位'), (2, '已住', '当前有学生入住'), (3, '维修中', '暂停分配，预计恢复时间见备注');dorm_room.status_id外键引用dorm_status.id。这样增删状态只需改码表，不动主业务逻辑。
我一般会强制要求：所有枚举型字段、所有可能随时间扩展的分类字段，必须独立建码表。这不是过度设计，是给三个月后的自己留后悔药——某次课设答辩，A同学被问“如果学校新增‘国际学生专用楼层’，你现有表结构怎么支持？”，他指着dorm_room.floor_type VARCHAR(10)说“改成ENUM”，导师摇头：“那下次加‘无障碍楼层’呢？再改ENUM？”。而用码表的同学，只答：“加一行INSERT到floor_type_code表，前端下拉框自动刷新”。
2.3 关键业务规则的数据库级实现：用约束代替代码校验
范式解决结构，约束解决行为。以下是本系统必须落地的5条硬性约束，全部在SQL建表语句中声明：
| 规则 | 实现方式 | SQL片段示例 |
|---|---|---|
| 同一房间不能分配超员 | CHECK (current_occupancy <= capacity) | ALTER TABLE dorm_assignment ADD CONSTRAINT chk_occupancy CHECK (current_occupancy <= capacity); |
| 调寝申请必须关联有效学生和房间 | 外键+ON DELETE RESTRICT | FOREIGN KEY (student_id) REFERENCES student(id) ON DELETE RESTRICT |
| 退宿日期不能早于入住日期 | CHECK (checkout_date >= checkin_date) | CHECK (checkout_date IS NULL OR checkout_date >= checkin_date) |
| 同一学生同一时段只能住一间房 | 唯一联合索引 | CREATE UNIQUE INDEX uk_student_active ON dorm_assignment(student_id) WHERE status = 'active'; |
| 房间状态变更需留痕 | 触发器记录日志 | CREATE TRIGGER tr_dorm_status_log AFTER UPDATE ON dorm_room FOR EACH ROW INSERT INTO dorm_status_log... |
注意最后一项：uk_student_active是MySQL 8.0+支持的函数索引（WHERE子句过滤），它确保一个学生在“active”状态下只能有一条分配记录，但允许他有多条历史记录（如已退宿、已调出）。这是处理“时间维度数据”的经典手法，比在应用层加锁可靠得多。
3. 核心模块SQL实现：从建库到事务，每行代码都有业务注释
3.1 数据库初始化与基础表结构：字段命名即契约
-- 创建数据库（UTF8MB4兼容emoji，排序规则区分大小写） CREATE DATABASE IF NOT EXISTS dorm_management CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_as_cs; USE dorm_management; -- 【学生表】核心身份，不存敏感信息（如身份证号脱敏处理） CREATE TABLE student ( id CHAR(10) PRIMARY KEY COMMENT '学号，主键', name VARCHAR(20) NOT NULL COMMENT '姓名', gender ENUM('M','F') NOT NULL COMMENT '性别：M男/F女', major VARCHAR(50) COMMENT '专业', enrollment_year YEAR NOT NULL COMMENT '入学年份', status ENUM('active','graduated','suspended','withdrawn') DEFAULT 'active' COMMENT '学籍状态' ) ENGINE=InnoDB COMMENT='学生基本信息表'; -- 【楼栋表】物理载体，含管理责任人 CREATE TABLE building ( id TINYINT PRIMARY KEY AUTO_INCREMENT, name VARCHAR(30) NOT NULL UNIQUE COMMENT '楼栋名称，如"东一舍"', address VARCHAR(100) NOT NULL COMMENT '详细地址', manager_name VARCHAR(20) COMMENT '楼长姓名', contact_phone VARCHAR(15) COMMENT '联系电话' ) ENGINE=InnoDB COMMENT='宿舍楼栋信息表'; -- 【房间表】最小分配单元，状态由码表驱动 CREATE TABLE dorm_room ( id INT PRIMARY KEY AUTO_INCREMENT, building_id TINYINT NOT NULL COMMENT '所属楼栋ID', floor TINYINT NOT NULL COMMENT '楼层', room_no VARCHAR(10) NOT NULL COMMENT '房间号，如"301"', capacity TINYINT NOT NULL DEFAULT 4 COMMENT '床位数', status_id TINYINT NOT NULL DEFAULT 1 COMMENT '状态ID，关联dorm_status表', remark TEXT COMMENT '备注，如"含独立卫浴"', FOREIGN KEY (building_id) REFERENCES building(id) ON DELETE CASCADE, FOREIGN KEY (status_id) REFERENCES dorm_status(id), UNIQUE KEY uk_building_room (building_id, room_no) COMMENT '同一楼栋内房间号唯一' ) ENGINE=InnoDB COMMENT='宿舍房间信息表';设计说明：
student.id用CHAR(10)而非INT，因学号含字母（如“2023CS001”），且长度固定便于索引；dorm_room的UNIQUE KEY uk_building_room强制“东一舍301”和“西二舍301”可共存，避免跨楼栋重号冲突；- 所有
COMMENT字段不是摆设——Navicat等工具可直接导出为数据字典，Word报告里“物理设计”章节直接截图粘贴即可。
3.2 分配与调寝的核心事务：ACID不是口号，是三条SQL的顺序
学生换寝不是简单UPDATE两条记录，而是涉及原房间减员、新房间加员、申请单状态更新三个原子操作。以下事务脚本经MySQL 8.0实测，开启READ COMMITTED隔离级别：
-- 开启事务 START TRANSACTION; -- 步骤1：锁定原分配记录（防止并发修改） SELECT * FROM dorm_assignment WHERE student_id = '2023001' AND status = 'active' FOR UPDATE; -- 步骤2：将原分配状态置为"已调出"，并记录调寝时间 UPDATE dorm_assignment SET status = 'transferred', transfer_time = NOW() WHERE student_id = '2023001' AND status = 'active'; -- 步骤3：检查目标房间是否可入住（容量+状态双重校验） SELECT capacity, current_occupancy, status_id FROM dorm_room WHERE id = 105 AND status_id = 1; -- 只允许状态为"空闲"的房间 -- 步骤4：插入新分配记录，并更新房间当前入住数 INSERT INTO dorm_assignment (student_id, dorm_room_id, checkin_date, status) VALUES ('2023001', 105, NOW(), 'active'); UPDATE dorm_room SET current_occupancy = current_occupancy + 1 WHERE id = 105; -- 步骤5：更新调寝申请单状态 UPDATE dorm_application SET status = 'executed', execute_time = NOW() WHERE id = 882; -- 无错误则提交 COMMIT; -- 若任意步骤失败，执行 -- ROLLBACK;关键参数说明：
FOR UPDATE是行级锁，确保同一学生不能被两个管理员同时操作；dorm_room.current_occupancy在事务中更新，避免脏读导致超员；- 所有
NOW()使用数据库服务器时间，而非应用层传入，保证时间戳权威性； - 注释里的“步骤X”不是伪代码，是调试时逐行执行的检查点——某次帮A同学排查，发现他漏了步骤3的
status_id校验，导致维修中的房间也能被分配，加这一行AND status_id = 1后问题消失。
3.3 查询报表SQL：不是SELECT *，而是带业务语义的聚合视图
课设验收常被忽略的一环：能否快速回答业务问题？这些SQL不是功能，而是交付价值：
-- 【视图】各楼栋空闲率统计（供管理员日报） CREATE VIEW building_vacancy_rate AS SELECT b.name AS building_name, COUNT(dr.id) AS total_rooms, COUNT(CASE WHEN dr.status_id = 1 THEN 1 END) AS vacant_rooms, ROUND( COUNT(CASE WHEN dr.status_id = 1 THEN 1 END) * 100.0 / COUNT(dr.id), 2 ) AS vacancy_rate_percent FROM building b LEFT JOIN dorm_room dr ON b.id = dr.building_id GROUP BY b.id, b.name; -- 【存储过程】生成某学生完整住宿履历（含调寝、退宿） DELIMITER $$ CREATE PROCEDURE sp_student_history(IN p_student_id CHAR(10)) BEGIN SELECT da.id AS assignment_id, CONCAT(b.name, '-', dr.room_no) AS dorm_location, da.checkin_date, da.checkout_date, ds.status_name AS current_status, COALESCE(da.remark, '无') AS remark FROM dorm_assignment da JOIN dorm_room dr ON da.dorm_room_id = dr.id JOIN building b ON dr.building_id = b.id JOIN dorm_status ds ON da.status_id = ds.id WHERE da.student_id = p_student_id ORDER BY da.checkin_date DESC; END$$ DELIMITER ;为什么必须写视图和存储过程？
- 视图
building_vacancy_rate将复杂JOIN和计算封装，管理员查空闲率只需SELECT * FROM building_vacancy_rate； - 存储过程
sp_student_history隐藏了多表关联细节，前端调用时传一个学号，返回结构化履历——这比在Java里拼SQL安全十倍； - Word报告中“测试用例”章节，可直接截图此视图查询结果，证明系统具备业务洞察力。
4. Word文档模板：不是格式填充，而是设计思维的可视化表达
4.1 五段式结构设计：让导师一眼看到你的数据库工程能力
这份Word模板不是让你填空，而是引导你用数据库工程师的视角组织语言。每一段都对应一个交付物，且预留了“手写批注区”（灰色底纹文本框）：
| 章节 | 核心任务 | 模板中你必须手动补充的内容 | 导师关注点 |
|---|---|---|---|
| 1. 需求分析 | 把口语化需求转为可验证的规则 | 列出3条以上业务规则（如“调寝需原宿舍满员率<80%才允许申请”），并标注来源（访谈记录/管理规定） | 是否真正理解业务，而非照抄题目 |
| 2. 概念设计（ER图） | 用实体-联系抽象现实世界 | 手绘ER图（推荐draw.io导出PNG），重点标出：弱实体（如dorm_assignment）、基数约束（1对多/多对多）、属性归属 | 实体识别是否准确，联系是否遗漏 |
| 3. 逻辑设计（关系模式） | 将ER图转为带主外键的关系表 | 表格列出每张表：关系名、属性列表、主键、外键、函数依赖（如student_id → name, major） | 范式是否达标，外键引用是否合理 |
| 4. 物理设计（SQL脚本） | 将逻辑模型落地为可执行SQL | 粘贴建表语句（含COMMENT），并截图Navicat中生成的表结构图 | 约束是否完整，索引是否必要，字符集是否统一 |
| 5. 测试用例 | 用数据证明系统可靠 | 设计5组测试数据（含边界值：如capacity=0、room_no="B101"含字母），截图SQL执行结果及预期对比 | 是否覆盖异常场景，结果是否可复现 |
注意：模板中所有“【此处插入截图】”标记，必须替换为你本地环境的真实截图。某次答辩，B同学用网上下载的ER图，导师放大后发现字体是微软雅黑（而学校统一用宋体），当场质疑原创性。
4.2 ER图绘制规范：不是画得好看，是画得准确
很多同学ER图翻车在细节。本模板强制要求以下四点：
- 实体矩形必须标注主键：如
student[学号]，不能只写student； - 联系菱形必须标注基数：如“入住”联系，学生端写
1，房间端写N，并在旁注明“一个学生住一间房，一间房住多个学生”； - 弱实体用双线矩形：
dorm_assignment（分配记录）依赖student和dorm_room存在，必须用双线； - 属性椭圆必须归属明确：
room_no属于dorm_room，不能挂在building上。
我们提供draw.io源文件（.drawio格式），打开即见标准图层：实体层、联系层、属性层已分离，拖拽即可复用。你只需修改文字，无需从零布局。
4.3 测试用例设计表：用数据说话，拒绝“测试通过”四个字
Word模板中“测试用例”章节，必须填写下表（可复制进Word）：
| 用例编号 | 测试场景 | 输入数据 | 预期结果 | 实际结果（截图） | 通过/失败 | 备注 |
|---|---|---|---|---|---|---|
| TC-01 | 新生入住空闲房间 | student_id='2024001', dorm_room_id=101 | dorm_assignment新增1条，dorm_room.current_occupancy+1 | [截图] | 通过 | - |
| TC-02 | 向满员房间分配学生 | student_id='2024002', dorm_room_id=101（current_occupancy=4, capacity=4） | 插入失败，报错“违反CHECK约束” | [截图] | 通过 | 验证约束有效性 |
| TC-03 | 并发调寝（模拟2人同时操作） | 两事务同时执行3.2节换寝事务 | 一个成功，一个等待超时或回滚 | [截图] | 通过 | 验证事务隔离性 |
血泪经验：TC-03必须做！某高校数据库课设明确要求“演示并发控制”。A同学只测单用户，答辩时导师现场开两个Navicat窗口同时执行换寝，第一个窗口卡住，第二个窗口报错，他答不出原因。而按此表准备的同学，直接展示SHOW PROCESSLIST中阻塞线程，解释FOR UPDATE作用，加分。
5. 避坑指南：课设中最容易踩的5个深坑及自救方案
5.1 现象：SQL文件导入Navicat报错“Unknown character set: 'utf8mb4_0900_as_cs'”
原因：你用MySQL 8.0+导出的SQL，但本地Navicat连接的是MySQL 5.7（不支持新排序规则）。
解决：
- 方案A（推荐）：在Navicat中右键数据库 → “编辑数据库”，将排序规则改为
utf8mb4_general_ci； - 方案B：用文本编辑器全局替换SQL文件中
utf8mb4_0900_as_cs为utf8mb4_general_ci； - 方案C：降级导出——在MySQL命令行用
mysqldump --default-character-set=utf8mb4 --skip-set-charset your_db > backup.sql。
5.2 现象：执行INSERT大量测试数据时，报错“Data too long for column 'room_no'”
原因：room_no定义为VARCHAR(10)，但你插入了“东一舍-301A”（11字符）；或建表时未指定STRICT_TRANS_TABLES模式，导致截断无声。
解决：
- 先查实际最大长度：
SELECT MAX(LENGTH(room_no)) FROM dorm_room; - 再安全扩容：
ALTER TABLE dorm_room MODIFY COLUMN room_no VARCHAR(15); - 永久规避：在MySQL配置文件
my.cnf中添加sql_mode = STRICT_TRANS_TABLES，让超长直接报错而非静默截断。
5.3 现象：调寝事务中，UPDATE dorm_room SET current_occupancy = current_occupancy + 1执行后数值不对
原因：current_occupancy是计算字段，但未加NOT NULL约束，当初始为NULL时，NULL + 1 = NULL。
解决：
- 建表时强制默认值：
current_occupancy TINYINT NOT NULL DEFAULT 0； - 初始化数据时，用
UPDATE dorm_room SET current_occupancy = 0 WHERE current_occupancy IS NULL;； - 更优解：删除
current_occupancy字段，改用视图实时计算（SELECT COUNT(*) FROM dorm_assignment da JOIN dorm_room dr ON da.dorm_room_id = dr.id GROUP BY dr.id），彻底消灭数据不一致风险。
5.4 现象：Word报告中ER图被导师质疑“为什么没有‘维修记录’实体？”
原因：你把维修当作房间的属性（如dorm_room.maintain_status），但维修是有时效性的事件，应建独立实体。
解决：
- 新增
maintenance_record表：id, dorm_room_id, start_date, end_date, reason, staff_id； dorm_room.status_id仅表示当前状态，维修记录表存历史；- 在ER图中，
maintenance_record是弱实体，依赖dorm_room，基数为“房间可有0-N次维修”。
5.5 现象：答辩时被问“你们的系统如何防止管理员误删楼栋？”
原因：建表时只用了ON DELETE CASCADE，删楼栋会连带清空所有房间和分配记录，无追溯。
解决：
- 改为
ON DELETE RESTRICT，禁止直接删除； - 提供安全删除流程：
-- 步骤1：检查该楼栋是否有房间 SELECT COUNT(*) FROM dorm_room WHERE building_id = 5; -- 步骤2：若有，先逻辑删除（UPDATE building SET status = 'archived'） -- 步骤3：归档后，再物理删除（需DBA权限） - 在Word报告“安全设计”章节，专门描述此流程，并附上SQL截图。
6. 答辩通关技巧：用三张图、两句话、一个习惯征服导师
6.1 答辩现场必带的三张图：直击导师评估锚点
导师听答辩平均专注时间不足8分钟，必须用视觉锤抢占认知。这三张图不是装饰，是经过验证的“高光时刻触发器”：
图1：范式演进对比图（PPT第1页）
左侧画未范式化的“大宽表”（含重复的building_address），右侧画第三范式后的三张表（building/dorm_room/dorm_status），中间用红色箭头标出“消除冗余”“消除传递依赖”。导师看到这张图，会立刻判断你是否真懂范式，而不是背概念。图2：调寝事务执行时序图（PPT第2页）
用横向时间轴画：T1时刻SELECT ... FOR UPDATE加锁 → T2时刻UPDATE dorm_assignment→ T3时刻UPDATE dorm_room→ T4时刻COMMIT。在T2和T3之间标红“ACID保障点：原子性在此处落地”。导师关心的不是你会不会写SQL，而是你是否理解数据库如何保障业务正确性。图3：测试用例结果对比图（PPT第3页）
左侧贴TC-02（向满员房间分配）的报错截图，右侧贴TC-03（并发调寝）的SHOW PROCESSLIST截图，下方用文字框写：“约束拦截非法操作，锁机制保障并发安全”。这比你说一百遍‘我用了事务’更有说服力。
提示：这三张图必须是你本地环境的真实截图，分辨率不低于1280×720。某次答辩，C同学用PS合成的“理想化”截图，导师用手机拍下投影放大，发现字体渲染锯齿不一致，当场要求重新演示。
6.2 回答高频问题的两句话公式：不解释，只定位
导师提问往往直指薄弱环节。用这两句话结构，3秒内建立专业感：
当被问“为什么用外键不用应用层校验？”
→ “因为外键是数据库级强制约束，即使应用代码出错、绕过接口直连数据库，数据一致性依然受保护。比如这里dorm_assignment.student_id外键到student.id，删学生前必须先清空其分配记录，否则报错。”
（说完立刻指向PPT中建表SQL的FOREIGN KEY行）当被问“这个系统怎么扩展？”
→ “所有枚举字段都已建码表，比如dorm_status，新增状态只需INSERT一行；所有业务规则优先用CHECK约束和触发器实现，比如chk_occupancy，扩展规则只需改约束条件，不碰主表结构。”
（说完打开Word报告“逻辑设计”章节，翻到码表定义页）
关键：每句话后必须立即指向你的交付物（PPT/Word/SQL文件），让导师的视线跟着你的手指走。这比滔滔不绝讲原理有效十倍。
6.3 从那以后我每次做课设，都强制走一遍“三查清单”
这是我带过27个数据库课设项目后，总结出的保命习惯。它不耗时，但能避开90%的答辩翻车：
| 检查项 | 操作 | 为什么重要 |
|---|---|---|
| 查约束 | 在Navicat中右键每张表 → “查看DDL”，确认PRIMARY KEY、FOREIGN KEY、CHECK全部存在且语法正确 | 导师最爱问“这个外键删了会怎样？”，没建好等于没设计 |
| 查数据 | 对每张表执行SELECT * FROM table LIMIT 5;，确认测试数据符合业务逻辑（如dorm_room.capacity=4，current_occupancy≤4） | 数据是系统的血液，脏数据会让所有查询失效 |
| 查日志 | 执行一次完整调寝流程，然后查dorm_status_log表，确认有新增记录 | 日志是系统自证清白的证据，没有日志=没有运维能力 |
从那以后我每次做完SQL脚本，都打开Navicat，按F5刷新，对着这三行命令敲一遍：
SHOW CREATE TABLE dorm_assignment; -- 查约束 SELECT * FROM dorm_room LIMIT 3; -- 查数据 SELECT * FROM dorm_status_log ORDER BY id DESC LIMIT 2; -- 查日志三分钟，稳过答辩。希望帮到你。
本文还有配套的精品资源，点击获取
