企业官网建设流程全解析

简介：这是一套基于C#与SQL Server开发的合同信息管理系统完整源码及数据库资源，适合需要完成课程设计、毕业设计或快速搭建合同管理原型的开发者使用。系统围绕客户、项目、合同信息及执行控制等模块设计，区分管理员与普通用户权限，管理员可进行全流程管理操作，普通用户可查询客户、项目与合同明细。资源包共123个文件，包含51个C#源码文件、23个界面资源文件及配套的SQL Server数据库文件（.mdf/.ldf），另有配置文件与说明文档，压缩包仅2.82MB，结构清晰，便于直接打开解决方案附加数据库后调试运行。目前已有153人学习下载，可用于理解合同管理系统的数据库设计、WinForm界面开发及权限区分逻辑，也可作为同类型管理系统的开发参考。

1. 拿到“基于C#的合同管理系统（源码+数据库）.zip”后，从哪里开始最不后悔

如果你手里刚拿到这样一个压缩包，第一反应大概是解压之后直接双击 .sln 想跑起来。我建议先按住手，因为这类包通常不是给你“读懂全部源码”用的，而是给你“快速交付一套能用的合同台账、审批、提醒功能”用的。它叫“源码+数据库”，就意味着你要同时处理两件事：代码怎么编译，数据库怎么挂上。顺序反了，后面一半时间在排环境问题。

这类系统我们在本地跑通的完整路径一般是四步：先把数据库恢复出来，再改连接字符串，然后启动登录，最后走一遍合同新增、审核、提醒。整个过程里最劝退新手的不是 C# 代码，而是数据库文件到底怎么挂到你的 SQL Server 上——MDF、LDF、BAK、SQL 脚本四种形态处理方式完全不一样，上来就双击，大概率卡在“附加数据库失败”。这篇文直接按这条路径带你走一遍，顺便把我会踩的坑标出来。

2. 先恢复数据库：从拿到 MDF/LDF 到能连上，Windows 下最省事的几步

2.1 先分清楚压缩包里的数据库文件是什么形态

“源码+数据库”这个说法其实笼统，现实中你会遇到四种情况，处理方式完全不同。

我拿到压缩包后一般先解压到D:\Projects\ContractMS这种不带空格的路径下，然后打开文件夹排序，看有没有.mdf。因为绝大多数基于 C# 的合同管理系统教学项目都跑在 SQL Server Express 上，.mdf是最主流的交付形态。

如果你看到的是.bak，路径就简单多了——SSMS 里右键“数据库”节点 →“还原数据库”→ 选择设备 → 定位到.bak文件。但.bak有个问题：它把原库的物理文件名也带上了，还原后如果目标实例上已经有一个同名库会直接报“数据库正在使用”或“文件占用”。

2.2 附加 MDF 文件：两条路，从图形界面到命令行

最常见的是附加.mdf和.ldf。这里有个关键认知：附加不是双击文件，而是让 SQL Server 实例去“接管”这个文件。所以文件本身的访问权限必须够，否则附加必然报“操作系统错误 5（拒绝访问）”。

SSMS 附加步骤：

1. 打开 SQL Server Management Studio，连接你的实例。
2. 右键“数据库”节点，选“附加”。
3. 点“添加”，定位到.mdf文件。
4. 确认下方列表中已经自动带上了同名的.ldf，如果没有，手动添加它。
5. 点确定。

如果碰到权限问题，最快不是去改 NTFS 权限，而是把.mdf和.ldf复制到 SQL Server 默认数据目录里，比如C:\Program Files\Microsoft SQL Server\MSSQL15.SQLEXPRESS\MSSQL\DATA，再执行附加。这个目录是 SQL Server 服务账户本来就完全可控的地方，一次就过。

不想开图形界面的话，可以用命令行让 SQL Server 自己建库并关联文件：

USE [master]; GO CREATE DATABASE [ContractDB] ON PRIMARY ( FILENAME = N'D:\Projects\ContractMS\Data\ContractDB.mdf' ) LOG ON ( FILENAME = N'D:\Projects\ContractMS\Data\ContractDB_log.ldf' ) FOR ATTACH; GO

这段代码的逻辑是：CREATE DATABASE ... FOR ATTACH告诉 SQL Server 不要把文件当成新库去初始化，而是恢复文件头里记录的库结构直接挂载。FILENAME是物理路径，路径里的目录必须真实存在。执行后马上用SELECT name FROM sys.databases确认库里已经出现ContractDB。

如果你是第一次执行，SSMS 里有时会出现“文件已在使用”或“无法打开物理文件”的报错，大概率不是代码问题，而是这个FOR ATTACH要求当前连接用户有CREATE ANY DATABASE权限——用sa登录执行会省掉很多权限上的麻烦。这个细节排查很快，但卡住的时候能消耗一下午。

2.3 连接字符串：为什么这套系统的数据库死活连不上

库挂上之后，下一步就是改连接字符串。C# 项目的连接字符串一般存放在这几个位置：

• 桌面程序：App.config或web.config里的<connectionStrings>
• 老式 WebForms：web.config，但偶尔会有人写死在DBHelper.cs或SqlHelper里
• 偶尔有直接写在DataAccess层某个类的构造函数里的

先打开解决方案资源管理器，按 Ctrl+F 搜索Data Source或者Server=，这是最直观的定位方式。常见写法是：

<connectionStrings> <add name="ConnStr" connectionString="Data Source=.\SQLEXPRESS;Initial Catalog=ContractDB;User ID=sa;Password=123456;" providerName="System.Data.SqlClient" /> </connectionStrings>

参数含义：

• Data Source：实例名。.\SQLEXPRESS表示本机默认实例的 SQLEXPRESS 命名实例。如果你装的是 Developer 或 Standard 版，默认实例名就是.（一个点），写成Data Source=.。
• Initial Catalog：数据库名，必须和你附加时生成的库名严格一致。
• User ID / Password：SQL Server 登录账号。用sa要确认混合身份验证已打开；用 Windows 身份验证就把这两项改成Integrated Security=True;。

这一行配置是整套系统能不能跑起来的分水岭。改完之后怎么做验证？不要在 C# 里直接调试，先用 SSMS 用同一组账号密码连一下实例，能连上，说明连接字符串没问题；连不上，就是 SQL Server 的登录配置问题，跟你的代码无关。

3. 跑通登录和主界面：从项目启动到看到合同台账

3.1 项目启动入口怎么看，三层结构怎么下断点查

连接字符串就绪后，下一步是找到启动入口。打开.sln，先看里面有几个项目。典型的合同管理系统会分成这样：

• ContractMS.UI（WinForms 或 WPF 界面层）
• ContractMS.BLL（业务逻辑层）
• ContractMS.DAL（数据访问层）
• ContractMS.Model（实体类）

右键解决方案 →“设置启动项目”→“当前选定项目”，选择 UI 层那个，然后 F5。如果是 WinForms，入口在Program.cs里的Application.Run(new frmLogin());；如果是 ASP.NET WebForms，入口是Default.aspx。WinForms 是这类项目的大多数，下面按 WinForms 讲。

3.2 登录校验的代码定位：绕过“点登录没反应”的第一步

登录窗体通常会做三件事：取文本框内容、查数据库、比对密码。大部分老项目藏的坑是密码加密方式。你看到的代码可能是这样：

private void btnLogin_Click(object sender, EventArgs e) { string userName = txtUser.Text.Trim(); string pwd = txtPwd.Text.Trim(); // 常见做法：MD5 之后再查库，老项目很多不加密 string pwdMd5 = GetMd5Hash(pwd); string sql = "SELECT COUNT(*) FROM sys_user WHERE user_name=@name AND user_pwd=@pwd"; using (SqlConnection conn = new SqlConnection(connStr)) { using (SqlCommand cmd = new SqlCommand(sql, conn)) { cmd.Parameters.AddWithValue("@name", userName); cmd.Parameters.AddWithValue("@pwd", pwdMd5); conn.Open(); int count = Convert.ToInt32(cmd.ExecuteScalar()); if (count == 1) { this.Hide(); frmMain main = new frmMain(); main.Show(); } else { MessageBox.Show("用户名或密码错误"); } } } }

先别急着找错——这套写法本身是直通的：参数化查询避免了拼接 SQL，COUNT(*)拿是否有这条记录。如果点登录没反应，断点优先打在conn.Open()这一行。这里三步排查：

1. connStr是不是空字符串——初学者最容易把连接字符串写死在btnLogin_Click里，结果改完App.config没生效。
2. sys_user表里有没有数据——很多系统交付时附带的数据库里默认账号是admin / 123456或者sa / 123，但密码是 MD5 加密的，你手输的明文肯定进不去。先查询表SELECT * FROM sys_user看实际用户名和密码哈希。
3. 登录成功之后frmMain没有真正Show出来——有的版本用ShowDialog()，有的用Show()，如果你的frmLogin没有隐藏或关闭，主窗体可能在背后。

这个环节是整套系统里 C# 新手最麻烦的卡点，但也是最有价值的排查训练。搞定登录之后，主界面加载的就是合同台账，这一步你会直接面对DataGridView绑定数据源的问题。

3.3 主界面加载合同的常见写法：DataGridView 和数据集的关系

主窗体的Load事件一般长这样：

private void frmMain_Load(object sender, EventArgs e) { DataTable dt = GetContractList(""); dgvContractList.DataSource = dt; }

GetContractList内部是：

public DataTable GetContractList(string keyword) { string sql = "SELECT contract_id, contract_name, party_a, party_b, amount, sign_date, end_date, status " + "FROM contract WHERE contract_name LIKE @keyword"; using (SqlConnection conn = new SqlConnection(connStr)) { using (SqlDataAdapter da = new SqlDataAdapter(sql, conn)) { da.SelectCommand.Parameters.AddWithValue("@keyword", "%" + keyword + "%"); DataTable dt = new DataTable(); da.Fill(dt); return dt; } } }

这套写法的核心是SqlDataAdapter负责把查询结果填充进内存里的DataTable，再整体丢给DataGridView。注意LIKE @keyword里参数值用的是%关键词%而不是%关键词，否则只能匹配以关键词开头的合同名称。筛选时文本框TextChanged事件里重新调用GetContractList(txtKeyword.Text)再绑定，就能做到即时过滤。

如果主界面显示出来的列名不对——比如contract_id没人看得懂——可以在DataGridView的属性面板里改HeaderText，或者用 SQL 里起别名，比如SELECT contract_id AS 合同编号。老系统喜欢直接在 SQL 里用中文别名，因为省事，但这也意味着你的DataGridView的列集合是动态生成的，后续做导出时别写死列名，否则字段对不上。

4. 合同新增、审批、到期提醒：这套系统真正在管的业务逻辑

4.1 表结构的设计逻辑：合同管理系统的核心不是只有“合同表”

等你跑起来之后，看一眼数据库表清单，基本就能判断这套系统的成熟度。一个能用的合同管理系统，最少得有这些表：

大多数系统把合同附件路径存到数据库、文件本体放在服务器磁盘目录，这个设计用到今天依然没问题。你要注意的是status字段的取值。常见的状态机是：

• 0 草稿
• 1 待审批
• 2 审批通过
• 3 已驳回
• 4 已到期
• 5 已作废

如果你要二次开发，优先别改这个状态字段的含义，而是加字段。老系统里状态字段被到处硬编码的坑太多了，改枚举值会把历史数据全部带偏。

4.2 新增合同时的编辑界面：为什么主从表要分两次保存

合同新增在界面上通常是主从结构：上面填合同基本字段，下面挂附件列表。有经验的开发者会在保存时拆成两步：

private void btnSave_Click(object sender, EventArgs e) { using (SqlConnection conn = new SqlConnection(connStr)) { conn.Open(); SqlTransaction tran = conn.BeginTransaction(); try { string insertSql = "INSERT INTO contract(contract_name, party_a, party_b, amount, sign_date, end_date, status) " + "VALUES(@name, @a, @b, @amount, @signDate, @endDate, 0); SELECT SCOPE_IDENTITY();"; SqlCommand cmd = new SqlCommand(insertSql, conn, tran); cmd.Parameters.AddWithValue("@name", txtName.Text.Trim()); cmd.Parameters.AddWithValue("@a", txtPartyA.Text.Trim()); cmd.Parameters.AddWithValue("@b", txtPartyB.Text.Trim()); cmd.Parameters.AddWithValue("@amount", decimal.Parse(txtAmount.Text.Trim())); cmd.Parameters.AddWithValue("@signDate", DateTime.Parse(dtpSignDate.Value.ToShortDateString())); cmd.Parameters.AddWithValue("@endDate", DateTime.Parse(dtpEndDate.Value.ToShortDateString())); int newId = Convert.ToInt32(cmd.ExecuteScalar()); foreach (string filePath in attachmentList) { string attSql = "INSERT INTO contract_attachment(contract_id, file_name, file_path, upload_time) " + "VALUES(@cid, @fname, @fpath, GETDATE())"; SqlCommand cmdAtt = new SqlCommand(attSql, conn, tran); cmdAtt.Parameters.AddWithValue("@cid", newId); cmdAtt.Parameters.AddWithValue("@fname", Path.GetFileName(filePath)); cmdAtt.Parameters.AddWithValue("@fpath", filePath); cmdAtt.ExecuteNonQuery(); } tran.Commit(); } catch { tran.Rollback(); throw; } } }

这段代码的关键在SCOPE_IDENTITY()——它在同一个连接和事务中取得contract表刚才 INSERT 生成的自增主键，用于挂附件。这套流程里有两个容易翻车的地方。

第一，amount建议提交前先用decimal.TryParse校验，直接decimal.Parse只要用户输入了12,000这种带千分位的字符串就会抛异常。第二，附件如果只记路径不拷文件，别人拿着这个库到另一台电脑上，点附件会打开空路径；更稳的做法是把附件复制到系统自己的UploadFiles目录里再存相对路径。老系统中大量存在“存储的是绝对路径导致换机器就失效”的血泪经验，你的系统如果要交付给别人部署，这里一定改成以应用目录为根的相对路径。

4.3 到期提醒：不是定时器轮询，而是 SQL 查询

合同系统的“提醒”功能是撑门面的那个点。很多教学代码是用Timer每分钟查一次到期表，刷新 DataGridView。但如果你在正式环境里这样做，多个用户同时开着系统，等于每分钟承受 N 次查询，SQL Server 迟早会冒出SQL BulkCopy 表变动有影响或者死锁。更稳的做法是把“是否过期”作为一种查询条件，而不是后台任务：

SELECT contract_id, contract_name, party_a, end_date, DATEDIFF(DAY, GETDATE(), end_date) AS days_left, CASE WHEN DATEDIFF(DAY, GETDATE(), end_date) < 0 THEN '已过期' WHEN DATEDIFF(DAY, GETDATE(), end_date) <= 7 THEN '即将到期' ELSE '正常' END AS remind_status FROM contract WHERE status = 2 AND DATEDIFF(DAY, GETDATE(), end_date) <= 7 ORDER BY end_date;

这段 SQL 里的DATEDIFF(DAY, GETDATE(), end_date)计算的是从今天到合同截止日之间相差的天数，负数代表已经过了截止日。你只需要在主界面加载时执行一次，把结果绑定到“到期提醒”页签的表格里，再在启动时弹一次提醒，就完全够用了。

定时轮询不是不能用，而是要限制为“只有主界面打开时每 10 分钟刷一次”，并且用条件查询只取即将到期的 20 条，别把整个contract表拉回来。这也是我对这一类 C# 管理系统性能优化说得最多的点——这类系统瓶颈几乎都在数据库查询，不在 C# 代码本身。

4.4 合同台账导出：DataTable 到 CSV 的最低成本实现

导出功能是用户的刚需。老项目里图片导出到 Excel 的方式经常是逐个单元格写Excel.Application，又慢又依赖 Office 环境。我不建议你为这个引入庞大的 NPOI，如果是给内部用的台账，导出一个带 BOM 的 CSV 可以兼容 Excel 打开：

private void btnExport_Click(object sender, EventArgs e) { DataTable dt = (DataTable)dgvContractList.DataSource; StringBuilder sb = new StringBuilder(); // 写标题 string[] columns = { "合同编号", "合同名称", "甲方", "乙方", "金额", "签订日期", "到期日期" }; sb.AppendLine(string.Join(",", columns)); // 写数据 foreach (DataRow row in dt.Rows) { sb.AppendLine(string.Join(",", row["contract_id"], row["contract_name"], row["party_a"], row["party_b"], row["amount"], row["sign_date"], row["end_date"])); } string path = Path.Combine(Environment.GetFolderPath(Environment.SpecialFolder.DesktopDirectory), "合同台账_" + DateTime.Now.ToString("yyyyMMdd") + ".csv"); // 使用 UTF-8 with BOM，防止 Excel 打开中文乱码 File.WriteAllText(path, sb.ToString(), new UTF8Encoding(true)); MessageBox.Show("导出完成：" + path); }

这里需要解释两个参数。UTF8Encoding(true)的true表示写入 BOM 头，没有它 Excel 打开 CSV 时会把 UTF-8 无 BOM 的内容按 ANSI 解码，中文直接变乱码。字符串拼接里不要用+去拼一整行，用string.Join和StringBuilder而不是+=，否则数据量大时内存频繁分配，界面会卡到看起来像死机。如果你的DataTable里列名是中文，直接把columns数组换成从dt读取也可以，但为了表头可控，我一般宁可手写表头。

4.5 审批流的代码落点：approval_log 是看懂业务的分水岭

如果这套系统带审批流，那么approval_log表就是理解整套代码的钥匙。常见实现是：合同状态为 1（待审批）时，审批人点“通过”或“驳回”，界面层调用 BLL 里一个类似ApproveContract(int contractId, string action, string comment)的方法。这个方法内部通常做两件事：

-- 第一步：写审批记录 INSERT INTO approval_log(contract_id, approver, action, comment, action_time) VALUES(@cid, @approver, @action, @comment, GETDATE()); -- 第二步：更新合同状态 UPDATE contract SET status = CASE @action WHEN '通过' THEN 2 ELSE 3 END WHERE contract_id = @cid;

这两条必须放在同一个事务里，不然会出现审批记录写了但合同状态没变的情况。你现在回头看看系统里这个方法的实现，如果两条 SQL 之间没有SqlTransaction，那这就是你接手后第一个要补的洞。

5. 五个高频坑与排查：从附加数据库到程序跑飞的实战笔记

坑 1：附加 MDF 报“无法打开物理文件，操作系统错误 5（拒绝访问）”

现象：SSMS 附加数据库时直接报权限错误，文件明明在磁盘上，双击也能打开。

原因：SQL Server 服务是跑在MSSQLSERVER或SQLEXPRESS这个 Windows 服务账号下的，它没有权限读取你放在桌面或下载目录里的 MDF 文件。界面你能打开，不代表服务账号能打开。

解决：把 MDF、LDF 文件复制到 SQL Server 默认数据目录（路径里含MSSQL\DATA）再附加。或者右键文件属性 → 安全 → 给Authenticated Users加读取权限。给文件授权这个操作别嫌烦，服务重启之后才生效，所以多数人试一次就走复制文件路线了。

坑 2：VS 打开 .sln 提示“不兼容”或“需要升级”

现象：双击.sln提示版本不兼容，或者能打开但项目加载失败。

原因：.sln文件头里的版本号和你安装的 Visual Studio 不匹配。VS2017 是 15.00，VS2019 是 16.00，VS2022 是 17.00。老的 C# 教学项目经常是 VS2012/2015 时代建的，版本号只有 11.00 或 12.00。

解决：用记事本打开.sln，把Microsoft Visual Studio Solution File, Format Version 12.00改成你对应版本的数字。但项目文件（.csproj）里的TargetFramework也要看，如果项目目标是.NET Framework 4.0，VS2022 默认不给装 4.0 开发工具，你要么装对应组件，要么把目标框架改到 4.5 以上。改目标框架在.csproj文件的<TargetFrameworkVersion>节点里操作，改完重新加载项目。

坑 3：登录报错“用户 ‘sa’ 登录失败（错误 18456）”

现象：程序连接字符串里写的是 sa，一跑就报这个错。

原因：SQL Server 默认安装时只开了 Windows 身份验证模式，sa 账号根本没被启用，或者密码不对。

解决：先用 Windows 身份验证登录 SSMS，到“安全性 → 登录名 → sa”里设置新密码，并把“强制实施密码策略”勾掉，再到服务器属性 →“安全性”里选“SQL Server 和 Windows 身份验证模式”。改完必须重启 SQL Server 服务，重启方法是在“SQL Server 配置管理器”里右键实例名选择“重新启动”，或者在服务管理器里重启。只改设置不重启，配置不会加载。

坑 4：跑 SQL 脚本建库时“GO”报错

现象：拿到.sql脚本，在 SSMS 新建查询里全选按 F5，停在某个GO上报“附近有语法错误”。

原因：GO不是 T-SQL 语句，它是 SSMS 的批处理分隔符。在某些编辑器或程序里GO会被当作普通字符串发给 SQL Server，SQL Server 不认。这种现象最常见于把脚本内容复制到 C# 代码里用SqlCommand.ExecuteNonQuery()执行，或者用某些第三方数据库工具连库跑脚本时。

解决：在 SSMS 里右键脚本文件选“执行”而不是复制粘贴；如果你确实需要在 C# 里跑脚本，先把文本里的GO按行分割，逐段执行，每段之间跳过GO行。你如果现在用的就是 SSMS 却还是报错，检查一下是不是把 CREATE 语句和 GO 写在了同一行——GO 必须单独一行。

坑 5：主界面显示“无法读取中文列名”或 DataGridView 全空

现象：主界面能登录进去，但合同台账表格是空的，或者某个字段显示为System.Data.DataRowView。

原因：SQL 查询结果集的字段名和DataGridView绑定的属性名对不上。老项目如果用了DataSet设计器，界面上绑定的是设计器里定死的列名，数据库字段一改就对不上了；System.Data.DataRowView则往往是你把整个 DataRow 对象当成单元格的值绑进去了。

解决：先用 MessageBox 或断点看dt.Rows.Count，确认查询结果是真的空了，还是数据源绑定的列名不对。然后回到 DataGridView 的Columns集合，检查每个列的DataPropertyName是否和查询出的字段名完全一致，大小写也要一致。设计器里自动生成的列不会根据 SQL 变化自适应，这是 WinForms 绑定的经典坑——不要在DataGridView属性里手填列名，而应在代码里dgv.AutoGenerateColumns = true;让它自动生成列，省掉一半烦恼。

6. 把“本地能跑”变成“给别人也能跑”：三个必改点与验证方法

这套系统你自己能跑通，和你能把它部署到别人电脑上是两回事。交付时最优先改的不是代码逻辑，而是三个容易被忽略的配置点。

第一，连接字符串必须外部化。很多教学代码把connStr写死在每个窗体里，换个机器就得重编译。改造方式是在App.config里定义连接配置，代码里读取：

string connStr = ConfigurationManager.ConnectionStrings["ConnStr"].ConnectionString;

别小看这一行，它会让你后续部署时只改配置文件不动代码。更实诚的做法是把敏感数据留在App.config的appSettings里单独放一个节点，方便实施人员在现场直接改。

第二，附件存取路径改为相对路径。上面提过，合同系统附件的绝对路径在换机器后必然失效。正确做法是程序启动时把附件根目录拼出来：

string uploadRoot = Path.Combine(AppDomain.CurrentDomain.BaseDirectory, "UploadFiles"); if (!Directory.Exists(uploadRoot)) Directory.CreateDirectory(uploadRoot);

数据库里只存相对路径，读取时再拼接。这样整个系统文件夹拷走之后，附件跟着走，不用重新关联。

第三，对密码字段做哈希校验。你接手的老源码里如果密码是明文存储，务必改成加盐哈希，而不是简单的 MD5——MD5 查彩虹表秒破。能写出来的最小改造是按用户查哈希再比对：

string hash = GetMd5Hash(pwd + salt); // 从数据库查出已存的哈希，用固定时间的比较方法比对 string storedHash = dt.Rows[0]["pwd_hash"].ToString(); bool ok = string.Equals(hash, storedHash, StringComparison.Ordinal);

验证改造有没有改坏，一个最直接的方法是打开 SQL Server Profiler 跟踪数据库连接和查询执行，然后手工走一遍登录、新增合同、审批、导出四步。看每步是否都只发起了预期的那几条 SQL，有没有多余的异常连接。跑 Últimát没有报错只能说明你没搞坏基本功能，跑一遍这四条路径才能说明你能交付。

我的习惯是从接手一个 C# 系统的第一天起就建一份部署检查清单：数据库文件放哪、实例名是什么、登录账号密码是否启用、附件目录建了没有。这份清单救过我太多次——上次我把连接字符串改到外部文件后忘了把配置文件一起拷给客户，现场花了一个小时排查才发现是文件没带上。这个经历之后我交付前一定模拟一次“干净环境部署”，只拿压缩包内容在一台新机器上跑。希望这个习惯和这篇文章里的排查顺序能帮到你。

本文还有配套的精品资源，点击获取