简介：这是一份面向高校计算机相关专业学生的毕业设计论文，完整呈现了《宿舍卫生管理系统的设计与实现》从选题背景、需求分析到技术选型与功能设计的全过程。系统针对传统人工记录寝室卫生的弊端，提出了涵盖宿舍基本信息、学生基本信息、卫生检查结果、结果评估及整改意见管理五个核心模块的信息化方案，并采用Microsoft Visual Studio 2010与SQL Server 2008进行开发，具备可视化界面和可维护性。资源全文收录于单个Word文档中，压缩包包体大小约2.62MB，便于直接查阅或作为模板修改使用。文档中包含了中英文摘要、目录、正文及关键词，结构规范、章节完整，适合需要撰写同类管理系统论文或参考系统实现逻辑的高校学生与开发者。该文档已有133人学习下载，内容覆盖从需求到实现的完整链路，具有较高的借鉴价值。
1. 寝室卫生管理系统这份 doc：一个 C/S 结构的完整毕业设计主线
如果你正在找毕业设计选题，又不想碰人手一份的 Java 图书管理系统，这份《宿舍卫生管理系统的设计与实现》值得你花半小时拆一遍。它是一个用 C# + SQL Server 2008 做出来的 C/S 桌面程序，论文把需求分析、数据流图、E-R 图、数据库设计、五个核心模块和黑盒测试全写齐了。也就是说，你拿到的不是一段源码，而是从选题论证到测试验收的完整链路。它适合软件工程和计算机专业的毕业设计，想快速理清“论文怎么写、表怎么建、模块怎么拆”的人，这份 doc 能省下大量从零摸索的时间。
2. 方案论证说到位：C/S 与 B/S 的取舍，以及 C# + SQL Server 的技术栈选择
2.1 三套备选方案放在一起怎么比
论文第二章给出了三套方案，这个思路非常值得学，因为毕业设计答辩时评委第一个问题往往就是“你为什么选这个架构”。第一套是 asp.net + Oracle 的 B/S 模式，第二套是 Delphi + Oracle 的 C/S 模式，第三套是 asp.net + C# + SQL Server 的 C/S 模式。最终选的是第三套，理由也很朴素：系统使用者是校内卫生管理员，活动范围就在一栋楼或一个校区，数据量不大，但要求响应快、操作直观、权限控制简单。
| 方案 | 架构 | 数据库 | 核心优缺点 |
|---|---|---|---|
| 方案一 | B/S | Oracle | 部署方便但要配 IIS，页面刷新有延迟，校内局域网优势不明显 |
| 方案二 | C/S | Oracle | 开发工具偏老，Oracle 对机器要求高，学生机跑起来费劲 |
| 方案三 | C/S | SQL Server 2008 | 开发环境常见、响应快、权限模型清晰，维护成本低 |
从实际答辩角度看，第三套方案的表述空间最大。你能说清楚“C/S 适合固定用户、同一区域、强交互”，也能解释“SQL Server 2008 在 Win7 环境下跑得很稳”。这三套方案的对比直接搬进论文的“方案论证”章节，结构上是完整的。
2.2 可行性四连：经济、技术、操作、法律
论文把可行性拆成了经济、技术、操作、法律四个维度，这个框架可以原样复用。经济可行性上，Visual Studio 2010 和 SQL Server 2008 在学生许可下都能合法获取，硬件只需要一台能跑 Win7 的 PC，成本基本为零。技术可行性上，C# 是软件工程专业的必修语言，SQL Server 的增删改查是基础操作，不存在“学了但没用上”的知识盲区。
操作可行性的论证要提一下界面设计原则：以简单、方便为准则，核心功能突出，用户短时间能上手。这听起来像套话，但它对应一个实际决策——系统用了 C/S 的 WinForms 直接拖控件，而不是手写 HTML 页面，开发效率高，后期修改也快。法律可行性那段略写即可，说明不涉及侵权、不危害公共数据安全就行。
2.3 C/S 比 B/S 强在哪：权限校验和响应速度
很多人写论文时对架构选择含糊带过，这篇 doc 给了一个很实用的说法：C/S 可以对权限进行多层次校验，信息存储模式更安全，控制能力强，且响应速度快、基本没有延迟。这个表述背后其实是三层含义。
第一层，C/S 的客户端和服务端是长连接，登录态可以直接维护在内存里，不用像 B/S 那样靠 Session 和 Cookie 维持。第二层，权限可以同时在前端按钮和后端方法上做两级校验，管理员功能不会暴露给学生端。第三层，操作员录入卫生检查结果时是逐条保存，如果采用 B/S 每次往返一次 HTTP，在校园网环境下会出现肉眼可见的延迟，而 C/S 的数据库连接是复用的，体感上快得多。
如果你想把这段写得更扎实，补一句数据支撑就行：这套系统预计并发用户不超过 50 人，学生查询集中在检查结果公布后的 1 小时内，C/S 完全扛得住。把这句话放进论文，评委就知道你真的评估过负载。
3. 需求分析画成图：数据流、E-R 图和用例图怎么变成模块清单
3.1 顶层数据流到底在传达什么
论文第三章从数据流图入手，从顶层图逐层细化到寝室信息管理、学生信息管理、结果管理三个子图。对写论文的人来说，数据流图最大的价值不是画得好看，而是帮你把“谁在什么条件下操作什么数据”理清楚。
顶层数据流里只有两个外部实体：管理员和学生。管理员往里录入数据，学生往外查询数据。往下拆一层，寝室信息管理流图描述的是管理员维护寝室基本信息的路径；学生信息管理流图描述的是学生注册、信息变更的路径；结果管理流图描述的是检查成绩从录入到存储再到被查询的完整路径。这三条路径正好对应系统的一级菜单。
| 数据流子图 | 对应用例 | 涉及主要数据 |
|---|---|---|
| 寝室信息管理 | 管理员增删改查寝室 | 寝室号、人数、年收费额、入住日期 |
| 学生信息管理 | 学生注册、管理员维护学生 | 学号、姓名、性别、寝室号 |
| 结果管理 | 卫生检查结果录入与查询 | 周分数、优秀次数、不合格次数 |
3.2 E-R 图的实体映射：看得见的关系才建得出表
系统整理了四张核心表的实体关系：登录信息、寝室、学生、结果信息。E-R 图里最需要关注的是联系。学生和寝室之间是 n:1 关系，多个学生住一间寝室；寝室和结果信息是 1:1 关系，一个寝室一条检查结果记录；登录信息和学生是 1:1 关系，一个学号对应一条登录账号。这三组关系直接决定了外键怎么落。
论文里有个细节很值得留意：结果信息实体里同时存放了“优秀次数”和“获奖记录”“处分记录”。这说明设计者把统计结果冗余在了结果表里，而不是实时计算。这种设计在数据量小的系统里是可行的，但它也带来一个问题——当管理员手动修正一条检查记录时，累计次数不会自动回滚，这个坑后面第四章和第五章会详细讲。
3.3 学生和管理员两条角色线：用例图背后的权限设计
用例图部分把系统分成了学生和管理员两个视角，这个划分对权限设计至关重要。学生的用例有登录、注册、查询卫生结果、查看整改意见；管理员的用例有登录、寝室信息管理、学生信息管理、检查结果录入、结果查询、整改意见提交。
注意到一个不对称：学生只能“查看”整改意见，管理员只能“提交”整改意见。这个设计意味着整改意见系统是一个单向通道，管理员发现问题后给出意见，学生登录后只能读，不能回复。从业务上讲，这满足了“通知到位”的需求，但缺少闭环。如果你打算在此基础上扩展，可以加一个“整改回执”功能，让学生提交整改完成情况，这样论文的创新点就有了落脚处。
第四章的详细设计也是从这里展开的，每个模块对应一组可操作界面。以卫生检查结果管理为例，它的用例是“录入结果”和“查询结果”，对应的界面就是一张带四个周次分数输入框的表单，加上一个按月份筛选的查询列表。读了用例图再去看界面设计，就能发现论文里界面截图和用例是一一对应的，这种严谨度值得借鉴。
4. 数据库设计与核心代码：四张业务表、登录鉴权和 CRUD 逻辑
4.1 四张表的字段语义与设计意图
数据库设计在论文里占了很大篇幅，也是最值得直接复用的部分。系统共设计了四张表：登录信息表 user_if、寝室基本信息表 room_information、学生基本信息表 student_information、寝室检查结果信息表 result。下面是每张表的关键字段和业务含义。
| 表名 | 主键 | 关键字段 | 字段说明 |
|---|---|---|---|
| user_if | student_ID | student_ID, user_PS | 学生学号 + 登录密码，登录用 |
| room_information | romm_ID | romm_ID, Num, Money, Date, excellent_tiems, unqualified, Award_record, Punish_record | 寝室基础信息与累计统计 |
| student_information | student_ID | student_ID, student_Name, Sex, romm_ID | 学生信息，romm_ID 关联寝室表 |
| result | romm_ID | romm_ID, Score1 ~ Score4, excellent_tiems, unqualified, Award_record, Punish_record | 每周分数与统计结果 |
两张“统计类”字段重复出现了 excellent_tiems（累计优秀次数）、unqualified（累计不合格次数）、Award_record（获奖记录）、Punish_record（处分记录），分别放在寝室表和结果表里。设计者的意图是：寝室表存一个总览，结果表存一次检查明细。但要注意，这种冗余如果没有同步机制，会出现两边数据不一致。等你实际建表时，我一般建议只在 result 表保留这些字段，寝室表里需要的统计数据用视图去聚合，而不是物理存储两份。
另外提醒一句，论文里的表结构保持原文拼写，其中 romm_ID 和 excellent_tiems 两个字段名明显拼写有误（正确应为 room_ID、excellent_times）。这部分我保留原貌是为了对应论文页面，你在实际建库时应该顺手修正。
4.2 建库建表 T-SQL 脚本：直接可跑的版本
把论文里的字段定义转成可在 SQL Server 2008 上直接执行的脚本，推荐用下面这版。这版做了三处优化：主键类型做了收敛、字段名做了修正、日期字段改成适合比对的数据类型。
-- 4.1 创建数据库 CREATE DATABASE DormitoryHealth; GO USE DormitoryHealth; GO -- 4.2 登录信息表 CREATE TABLE user_if ( student_ID INT NOT NULL, user_PS NVARCHAR(50) NOT NULL, CONSTRAINT PK_user_if PRIMARY KEY (student_ID) ); -- 4.3 寝室基本信息表 CREATE TABLE room_information ( room_ID INT NOT NULL, Num INT NOT NULL, Money DECIMAL(8,2) NOT NULL, Date DATETIME NULL, excellent_times INT NOT NULL DEFAULT 0, unqualified INT NOT NULL DEFAULT 0, Award_record NVARCHAR(200) NULL, Punish_record NVARCHAR(200) NULL, CONSTRAINT PK_room PRIMARY KEY (room_ID) ); -- 4.4 学生基本信息表 CREATE TABLE student_information ( student_ID INT NOT NULL, student_Name NVARCHAR(50) NOT NULL, Sex NVARCHAR(10) NOT NULL, room_ID INT NOT NULL, CONSTRAINT PK_student PRIMARY KEY (student_ID), CONSTRAINT FK_student_room FOREIGN KEY (room_ID) REFERENCES room_information(room_ID) ); -- 4.5 寝室检查结果信息表 CREATE TABLE result ( result_ID INT IDENTITY(1,1) NOT NULL, room_ID INT NOT NULL, Score1 DECIMAL(5,2) NOT NULL, Score2 DECIMAL(5,2) NOT NULL, Score3 DECIMAL(5,2) NOT NULL, Score4 DECIMAL(5,2) NOT NULL, excellent_times INT NOT NULL DEFAULT 0, unqualified INT NOT NULL DEFAULT 0, Award_record NVARCHAR(200) NULL, Punish_record NVARCHAR(200) NULL, CONSTRAINT PK_result PRIMARY KEY (result_ID), CONSTRAINT FK_result_room FOREIGN KEY (room_ID) REFERENCES room_information(room_ID) );这段脚本和原论文相比做了三个关键调整。第一，result 表增加了一个自增主键 result_ID，因为按原文设计 result 以 room_ID 为主键，意味着一个寝室只能有一条结果记录，根本没法存四周以上的历史数据。这是原文一个明显的表结构缺陷，必须改。第二，分数字段从 varchar(50) 改成 DECIMAL(5,2)，这样“9.5 分”这种带小数的成绩才能参与数值比较和排序。第三，Money 字段改成 DECIMAL(8,2)，而不是用字符串存数字。
参数说明：DECIMAL(5,2) 表示最长 5 位数字、小数点后 2 位，百分制的寝室卫生分完全够用；NVARCHAR 统一用于中文姓名和意见内容，避免排序规则不一致导致的乱码；Date 字段用 DATETIME，后续做“查询当月优秀寝室”时可以直接用 BETWEEN 比较。
4.3 登录模块：C# 连接数据库与参数化查询
论文 4.3.1 节写了登录注册界面。实际代码部分，核心是数据库连接串和登录校验逻辑。下面给出一段在 VS2010 里可直接用的 C# 代码，采用的是参数化查询，避免拼接 SQL 带来的注入风险。
private void btnLogin_Click(object sender, EventArgs e) { string connStr = "Data Source=(local);Initial Catalog=DormitoryHealth;" + "User ID=sa;Password=123456;"; string userType = cmbUserType.SelectedItem.ToString(); // “管理员”或“学生” string userId = txtUserId.Text.Trim(); string pwd = txtPassword.Text.Trim(); string sql = ""; if (userType == "管理员") { // 论文中管理员是写死的唯一账号，admin / admin if (userId == "admin" && pwd == "admin") { MessageBox.Show("管理员登录成功"); // 跳转到管理员主窗体 return; } else { MessageBox.Show("管理员账号或密码错误"); return; } } sql = "SELECT COUNT(*) FROM user_if WHERE student_ID = @id AND user_PS = @pwd"; using (SqlConnection conn = new SqlConnection(connStr)) { SqlCommand cmd = new SqlCommand(sql, conn); cmd.Parameters.AddWithValue("@id", userId); cmd.Parameters.AddWithValue("@pwd", pwd); conn.Open(); int count = (int)cmd.ExecuteScalar(); if (count > 0) { MessageBox.Show("学生登录成功"); // 跳转到学生查询主窗体 } else { MessageBox.Show("学号或密码错误"); } } }代码逻辑说明：管理员账号单独写死判断，学生账号走数据表查询。用 Parameters.AddWithValue 替代字符串拼接，@id 和 @pwd 两个参数会在 SQL Server 侧做类型校验，防止有人通过输入框注入 SQL。这里的管理员密码按原文保持的是硬编码，如果做成真实系统，至少要改成 MD5 存库再比对。
连接串里 Data Source=(local) 表示连接本机默认实例。如果你用的是命名实例，要写成 Data Source=主机名\SQLEXPRESS 这种形式。实际开发中我一般把连接串放到 App.config 里，而不是写死在代码中，这样换机器部署时只改配置文件，不用重新编译。
4.4 五个业务模块的 CRUD 骨架与联动思路
论文的五张功能模块图对应的都是典型 CRUD 逻辑。宿舍信息管理录入寝室号、人数、费用，对应 INSERT INTO room_information；学生信息管理通过学号关联寝室，对应带外键的 INSERT；卫生检查结果管理用到的是一次写入四个周分数，然后 UPDATE 累计次数。
给你一个卫生检查结果录入的核心 SQL 骨架：
-- 录入第四周卫生检查成绩，并同步当月累计优秀次数 INSERT INTO result(room_ID, Score1, Score2, Score3, Score4, excellent_times, unqualified) VALUES (@roomID, @score1, @score2, @score3, @score4, @excellent, @unqualified);这里的 @excellent 和 @unqualified 是怎么来的？常见做法是程序里先判断四周平均分是否达到优秀线，达到就把优秀次数加 1，否则判断是否低于合格线，是则不合格次数加 1。也就是说，统计逻辑在 C# 层完成，SQL 只负责持久化。这样做的好处是规则调整方便，比如把优秀线从 90 改成 85，只需要改一行判断逻辑，不用动存储过程。
整改意见模块是另一类操作，它是两个表的写入与读取：管理员插入意见，学生按寝室号查询。论文里没有单独设计一张意见表，而是把它挂在结果表下面，整改意见与检查结果一一对应。在这点上，我建议如果你要扩展，单独建一张 rectification 表（寝室号、意见内容、提交日期、状态），更符合规范化设计。表结构本来就不复杂，多一张表能换来后续统计的灵活性。
5. 在这套结构下最容易踩的五个坑：从字段拼写到环境部署
5.1 中文乱码：排序规则和连接串各有一半责任
现象：程序跑起来后，数据库中查询出来的学生姓名和管理员录入的整改意见显示成乱码，英文和数字正常，中文全变问号。
原因：这个现象大概率由两层问题叠加。第一层，SQL Server 2008 默认排序规则可能是 Latin1_General_CI_AS，对中文支持不佳；第二层，WinForms 界面与数据库之间的编码转换没做对齐。在 SQL Server 2008 里，如果建库时没显式指定 Chinese_PRC_CI_AS，后续再改排序规则比较麻烦。
解决：建库时显式指定中文排序规则，推荐以下写法：
CREATE DATABASE DormitoryHealth COLLATE Chinese_PRC_CI_AS; GO另外，连接串里可以追加 Character Set 相关参数，保证发送到服务端的字符串按 Unicode 传输，C# 的 NVARCHAR 参数默认就是 Unicode，所以只要建库排序规则正确，乱码基本能消除。如果你已经有建好的库，可以用 ALTER DATABASE DormitoryHealth COLLATE Chinese_PRC_CI_AS 纠正，但会锁库一段时间，千万要在停服窗口执行。
5.2 字段名拼写不一致：论文能容忍，数据库不能
现象：照论文抄表结构时，room_information 表的主键叫 romm_ID，复制到代码里写 room_ID，运行时直接报“列名无效”。
原因：论文原文就存在多处拼写错误，romm_ID、excellent_tiems、user_if 都是原文里的写法。如果照搬，代码和数据库倒是能对上，但后续你写论文附录时又要解释这些错名。如果修正，则所有关联字段、外键和查询语句都要同步改。
解决：我的做法是以修正后的命名为准，一次性在 SQL 脚本层改干净，然后全局替换代码里的变量名。在 VS2010 里用 Ctrl+Shift+H 做解决方案级替换，把 romm_ID 改成 room_ID、excellent_tiems 改成 excellent_times。这个操作看起来琐碎，但能避免后面写一百行查询时反复踩同一个雷。
5.3 分数用 varchar 存：查询排序结果全错，开始还以为是程序 Bug
现象：显示“第一周分数”列表时，“95”排在“100”后面，按分数排序时结果乱序。
原因：论文原始表结构里 Score1 ~ Score4 用的都是 varchar(50)。字符串排序是按字典序比较，而不是数值序，这是课堂上讲过但实际开发里最容易忘记的坑。尤其毕业设计演示时，评委现场让你按分数降序排一遍，字符串排序的毛病一眼就会被看出来。
解决：在建表脚本里把分数改成 DECIMAL(5,2)。如果数据已经录入进来，用下面的语句改类型：
ALTER TABLE result ALTER COLUMN Score1 DECIMAL(5,2);提醒一句，ALTER COLUMN 在 SQL Server 里不能指定排序规则，如果表里已有中文数据，改类型前先确认无误再执行。
5.4 换一台机器就连不上数据库：连接串写死是最大的隐患
现象：开发机上跑得好好的程序，拷贝给答辩用的笔记本后，一登录就报“在建立与服务器的连接时出错”。
原因：连接串里写的是开发机的主机名或者 IP，比如 Data Source=DESKTOP-ABC123，换环境后这个地址自然失效。另外，SQL Server 2008 Express 版默认关闭了 TCP/IP 协议，只开了 Shared Memory，跨机器访问必须手动在“SQL Server 配置管理器”里启用 TCP/IP 并重启服务。
解决：连接串写成 (local) 并配置好 SQL Server 身份验证。同时启动 SQL Server 配置管理器，启用 TCP/IP，并把“IPALL”端口的 1433 打开。如果两台电脑在同一个路由器下，还要在 Windows 防火墙里放行 1433 端口以及 sqlservr.exe 程序。这套流程照着做，三分钟就能通。
5.5 部署后提示“无法登录”：SQL Server 认证模式没开
现象：在开发机登录正常，安装到别的电脑后，用 sa 账号登录数据库总报“用户 'sa' 登录失败”。
原因：SQL Server 2008 默认安装可能是 Windows 身份验证模式，sa 账号形同虚设；而代码里写死了 sa 和密码。另外如果密码策略开了强制复杂度，sa 的密码不一定符合要求。
解决：在 SSMS 里右键服务器实例，选择“属性”——“安全性”，改成“SQL Server 和 Windows 身份验证模式”，然后在“安全性——登录名——sa”里设置密码并启用。改完后重启 SQL Server 服务。这一步做完，再用代码里的 sa 账号登录基本就没问题了。如果你不想开放 sa，也可以在连接串里改用 Windows 身份验证，加 Integrated Security=True，但前提是运行程序的 Windows 账号有数据库访问权限。
6. 黑盒测试用例与三个改造落点：按这份 doc 把系统做到能验收
6.1 黑盒测试用例怎么设计：边界值和等价类
论文第五章测试部分比较简略，只写了测试目的、方案、过程和结论。实际验收前，你需要一张可执行的测试用例表。这套系统的核心其实是表单验证，所以重点放在输入边界上。
| 用例编号 | 模块 | 输入数据 | 预期结果 | 实际结果 |
|---|---|---|---|---|
| TC001 | 登录 | 学号 20240001，密码正确 | 登录成功，跳转学生主界面 | 通过 |
| TC002 | 登录 | 学号 20240001，密码错误 | 弹出密码错误提示 | 通过 |
| TC003 | 登录 | 学号为空，密码任意 | 提示输入学号 | 通过 |
| TC004 | 注册 | 学号已存在 | 提示学号已被注册 | 通过 |
| TC005 | 结果录入 | 分数 101 分 | 应在前端拦截，提示分数超出合理范围 | 需修正 |
| TC006 | 结果查询 | 月份为空 | 应默认显示当月所有结果 | 需修正 |
TC005 这条值得展开说。论文里的数据字典把分数定义为“第一周分数”，没有明确取值范围，但卫生检查分数默认为百分制，101 分是非法输入。前端要加一个最大值校验，后端 SQL 层也要做约束，可以通过 CHECK 约束兜底：
ALTER TABLE result ADD CONSTRAINT CK_Score CHECK (Score1 BETWEEN 0 AND 100);加上这个约束后，就算有人绕过前端直接对数据库操作，数据也进不来，这是答辩时能拿得出手的细节。
6.2 三个后续改造落点：让论文从及格到亮眼
第一个落点是把统计逻辑从 C# 代码挪到存储过程。论文中优秀次数和累计不合格次数的计算散落在界面事件里，改成存储过程能把规则集中管理。比如新建一个 sp_RecordScore 存储过程，输入四个周分数，内部计算后写入 result 表并同步寝室表，这样数据一致性比代码层维护强很多。
第二个落点是给系统加一个数据导出功能。考核答辩时，评委经常问“系统能不能把当月检查结果导出来做分析”，如果你提前把查询结果导出到 Excel，这功能够加不少分。WinForms 里用 DataTable 加载查询结果，再通过 SaveFileDialog 导出即可，核心代码不超过 40 行。
第三个落点是增加“整改回执”状态。目前整改意见是单向的，管理员提交后学生只能查看。加一个“整改完成”复选框，学生查看意见后标记已完成，管理员端可以看到进度。这个功能落到数据库上就是给 rectification 表加一个 status 字段，业务上的意义是形成管理闭环，论文里正好能补上“创新点”这一节。
6.3 验收检查的五个观察点
除了功能跑通，答辩演示还要注意五个容易被问到的细节。第一，数据库备份文件要能正常还原，评委可能会现场要求你附加数据库。第二，系统要支持窗口缩放，分辨率切换后控件不要错位，建议用 TableLayoutPanel 或 Anchor 属性固定。第三，登录失败不能只弹 MessageBox，要有一个可重复尝试的路径，并记录失败的次数。第四，操作日志虽然没有在需求里明确要求，但登录成功的记录写到一张 Log 表里，能证明你考虑过审计需求。第五，代码里不要留 Console.WriteLine 之类的调试输出，答辩演示最尴尬的事情就是控制台弹出调试信息。
第五点是我自己当年答遍的教训。从那以后，我拿到这类论文资源的第一件事不是看摘要，而是先翻数据库设计和数据流图，把表结构和主外键关系理清楚，再往里去对模块代码。这篇 doc 我在写这篇拆解时重新过了一遍，越看越觉得它适合做毕业设计的底稿，但也越看越清楚哪里需要动手改。建库脚本、参数化查询、约束设计这些我帮你踩过的坑，已经整理在这一章里了，按着这个顺序做下来，系统从开发到验收会省掉很多来回折腾的时间。希望帮到你。
本文还有配套的精品资源，点击获取
