企业官网建设流程全解析

简介：面向企业微信二次开发者与需要合规存档的企业内部IT人员，这套C#调用接口源码演示了如何通过企业微信会话内容存档API自动同步聊天记录，覆盖身份验证与权限管理、定时增量同步、数据落库、异常处理与日志记录等关键环节，可直接嵌入现有应用程序。压缩包共81个文件，以49个C#源文件为核心，配套dll依赖库、exe安装程序、config配置文件、xml数据定义及sln解决方案；整体约57.1MB，并附带VC运行库一键安装包，便于快速搭好环境。已有209人学习下载。通过源码可掌握API请求包构造、响应数据解析、消息类型拆分（文本、图片、文件、会议等）以及FinanceHelper等辅助工具类的实际写法，还能参照其中对企业微信后台配置的替换说明完成部署和维护。

1. 企业微信会话内容存档C#调用接口源码：先看清这条链路的三道坎

"企业微信会话内容存档C#调用接口源码"这个标题，通常会让人误以为下载一份代码就能直接跑起来。实际接入过的开发者都知道，这套功能虽然叫"存档"，但官方并不会把明文聊天记录推送给你——所有会话数据都以密文形式下发，C# 侧没有现成 SDK，验签、AES 解密、游标翻页、分片重组全得自己按协议实现。这篇文章把这条链路上的关键代码和踩坑点拆开讲，适合要给内部系统做合规审计、销售过程留痕或客户纠纷取证的人。读完你至少能回答三个问题：参数从哪来、密文怎么解、增量怎么拉不丢不重。

2. 开通存档与参数准备：四个参数缺一个都白搭

动手写代码之前，先把企业微信管理后台的权限和参数理清楚。这一步没做好，后面所有 C# 代码都在空转。

2.1 申请会话内容存档：认证、开通、员工授权的顺序

会话内容存档不是普通应用功能，开通门槛比一般 API 高。以我接入的经验看，第一步是企业完成主体认证，个人认证的企业没有申请入口。第二步是在管理后台找到"管理工具-会话内容存档"，点击开通并签署使用协议。第三步最关键：让员工授权。员工没有授权，就算接口调用成功，拉回来的也只有空白数据。

员工授权有两种方式，一种是员工在企业微信 App 里手动确认，另一种是管理员在后台按部门批量开启。做系统集成时，批量开启是必经之路，否则几十上百号销售挨个点确认，项目连试点阶段都走不完。我一般会先让管理员批量开启测试部门，再拿一两个测试号跑通全链路，最后才放开全量。

这一步的坑容易被忽略：授权状态是名单式的，新入职员工默认不授权，你的定时拉取任务会静默跳过他们。建议在任务里定期对比企业通讯录和授权名单，把未授权的人筛出来通知管理员，而不是等着数据缺失后再复盘。

2.2 回调URL、Token 与 EncodingAESKey 的配置规则

开通完成后，进入会话内容存档的配置页，你会看到几个必须填写的参数。它们是后面 C# 代码里所有逻辑的前提：

配置页里填写的 Token 只参与回调签名计算，和 access_token 没关系，两个概念别混。EncodingAESKey 是会话数据的"总钥匙"，泄露等于明文数据裸奔——这密钥建议由专人保管，写入配置中心而不是硬编码到源码里。

配置回调 URL 时官方会先发一个验证请求，你的服务器要能正确响应才能保存成功。这也是 C# 代码第一步要解决的问题：拿到验证参数、算签名、解密 echostr 并返回明文。下一章直接讲这部分实现。

3. C# 端基础实现：获取 access_token 与回调验签

参数齐了，开始写 C#。先从最基础的 access_token 拿法和回调验签说起，这两块是所有后续操作的底座。

3.1 获取 access_token：HttpClient 封装与缓存策略

access_token 是企业微信接口的通行证，有效期 7200 秒。会话内容存档的拉取接口每次都要带它，所以这里我给一个带缓存的最小实现：

public class TokenStore { private readonly HttpClient _http = new HttpClient(); private readonly string _corpid; private readonly string _secret; private string _token; private DateTime _expireAt = DateTime.MinValue; public TokenStore(string corpid, string secret) { _corpid = corpid; _secret = secret; } public async Task<string> GetTokenAsync() { // 提前 300 秒过期，避免临界点上用失效 token 打接口 if (_token != null && DateTime.Now < _expireAt.AddSeconds(-300)) return _token; var url = $"https://qyapi.weixin.qq.com/cgi-bin/gettoken?corpid={_corpid}&corpsecret={_secret}"; var json = await _http.GetStringAsync(url); var resp = JsonDocument.Parse(json).RootElement; if (resp.GetProperty("errcode").GetInt32() != 0) throw new Exception($"gettoken 失败: {resp.GetProperty("errmsg")}"); _token = resp.GetProperty("access_token").GetString(); _expireAt = DateTime.Now.AddSeconds(resp.GetProperty("expires_in").GetInt32()); return _token; } }

这段代码的核心逻辑是"取到就缓存，快过期再刷新"。两个参数要强调：corpid 是企业 ID，secret 必须是会话存档配置页里生成的那把，不是某个自建应用的 secret——这两者用混了，会得到类似"invalid secret"的错误码。另外我习惯把过期时间提前 300 秒刷新，因为企业微信的过期时间是从签发瞬间开始算的，网络延时加上任务调度误差，踩着整点刷新很容易偶发 401。

多实例部署时要小心，每个实例各缓存一份 token 没问题，但如果你的任务调度分散在多台机器上，同一秒内多台机器同时刷新 token，后刷新的会把先刷新的踢下线。稳妥做法是把 token 放到 Redis 里让所有实例共享，或者干脆用单机定时任务负责拉取。

3.2 回调验签：SHA1 签名校验与 echostr 明文返回

配置回调 URL 时，官方服务器会带着 timestamp、nonce、echostr 三个参数请求你的地址，同时还有一个 signature 签名。你需要做两件事：验签通过后，把 echostr 解密成明文，再原样返回明文，配置才保存成功。

public static bool VerifySignature(string token, string timestamp, string nonce, string echostr, string signature) { var arr = new[] { token, timestamp, nonce, echostr }; Array.Sort(arr, StringComparer.Ordinal); // 字典序排序 var raw = string.Concat(arr); // 拼接成字符串 using var sha = SHA1.Create(); var hash = sha.ComputeHash(Encoding.UTF8.GetBytes(raw)); var hex = Convert.ToHexString(hash).ToLowerInvariant(); return hex == signature; }

签名算法是固定的：token、timestamp、nonce、echostr 四个值按字典序排序后拼接，再做 SHA1，结果转小写十六进制字符串与 signature 比较。这里有两个容易翻车的细节：排序必须用 Ordinal 字符串比较，不能用默认的语言文化排序，某些字符在不同语言环境下排序结果不一样；timestamp 参数要从请求字符串里原样取，不要解析成 DateTime 再格式化，精度和格式都对不上。

验签通过后，echostr 的明文解复用下一章的 AES 解密方法，只是最后返回的内容不是聊天记录消息体，而是解密后的纯字符串。部署时建议把验签和返回逻辑放在一个独立的 Controller 动作里，不附加任何业务处理，保证配置验证能快速通过。

4. 核心实现：C# 拉取会话数据并解密消息体

验签通过、token 能拿，接下来进入正题：拉数据、解数据。聊天记录不会主动送到你门口，得靠轮询；拉回来全是密文，得自己开锁。这一章是整个源码方案最厚的部分。

4.1 拉取接口的调用与游标翻页

会话存档的拉取接口是分页的，一次拉一批，靠 seq 游标往前走。seq 可以理解成消息的单调递增序号，每拉一批，把最后一条的 seq 记住，下次从 seq+1 开始。接口地址不同企业微信版本可能有差异，以官方文档"会话内容存档"章节标注为准，但请求参数和返回结构是一致的。

public async Task<List<ChatRecord>> PullChatDataAsync(string token, string userId, long lastSeq) { var url = $"https://qyapi.weixin.qq.com/cgi-bin/msgaudit/getchatdata?access_token={token}"; var payload = new { seq = lastSeq, limit = 1000, userid = userId }; var resp = await _http.PostAsJsonAsync(url, payload); var json = await resp.Content.ReadAsStringAsync(); var root = JsonDocument.Parse(json).RootElement; if (root.GetProperty("errcode").GetInt32() != 0) throw new Exception($"拉取失败: {root.GetProperty("errmsg")}"); var list = new List<ChatRecord>(); foreach (var item in root.GetProperty("chatdata").EnumerateArray()) { list.Add(new ChatRecord { Seq = item.GetProperty("seq").GetInt64(), MsgId = item.GetProperty("msgid").GetString(), Encrypt = item.GetProperty("encrypt").GetString(), Action = item.GetProperty("action").GetString(), From = item.GetProperty("from").GetString(), ToList = item.GetProperty("tolist").EnumerateArray() .Select(x => x.GetString()).ToList(), RoomId = item.TryGetProperty("roomid", out var r) ? r.GetString() : null, MsgTime = item.GetProperty("msgtime").GetInt64() }); } return list; }

参数里 userId 代表拉取哪个员工的数据，所以多半要按员工维度轮询。limit 我建议设置在 800 到 1000 之间，太大单次请求容易超时，太小翻页次数多、浪费 token。返回结构里 chatdata 是数组，每项都带完整的业务信息：seq 用于游标推进，msgid 是全局唯一消息 ID，action 区分 send/recall，msgtime 是 Unix 毫秒时间戳。pull 和 push 的字段名在不同版本里高度稳定，写入代码时建议用 DTO 强类型接住，不要满篇 JsonElement。

4.2 AES-CBC 解密与消息体拆分

密文拿到了，真正的关键动作是解密。企业微信的加解密协议是公开的：EncodingAESKey 补 "=" 后做 Base64 解码得到 32 字节密钥，IV 取密钥前 16 字节，AES-256-CBC 解密后得到的字节流有自己的结构：前 16 字节随机串 + 4 字节网络序长度 + 真实消息体 + 调用方 corpid。

public static string DecryptMsg(string encryptBase64, string encodingAesKey, out string receiveId) { var key = Convert.FromBase64String(encodingAesKey + "="); var cipher = Convert.FromBase64String(encryptBase64); using var aes = Aes.Create(); aes.Key = key; aes.IV = key.Take(16).ToArray(); // IV 是密钥的前 16 字节 aes.Mode = CipherMode.CBC; aes.Padding = PaddingMode.None; using var ms = new MemoryStream(); using (var decryptor = aes.CreateDecryptor()) using (var cs = new CryptoStream(ms, decryptor, CryptoStreamMode.Write)) { cs.Write(cipher, 0, cipher.Length); cs.FlushFinalBlock(); } var all = ms.ToArray(); // 结构: rand(16) + msgLen(4, 网络序) + msg + receiveid var msgLen = (all[16] << 24) | (all[17] << 16) | (all[18] << 8) | all[19]; var msg = Encoding.UTF8.GetString(all, 20, msgLen); receiveId = Encoding.UTF8.GetString(all, 20 + msgLen, all.Length - 20 - msgLen); return msg; }

这段代码有三处最容易写错。第一，PaddingMode 必须设 None，解密后自己拆分字节流；如果图省事设成 PKCS7，解密结果是能出来，但你拆不出消息体。第二，IV 是 key 的前 16 字节，这不是惯例而是协议规定，写错会出现"解密成功但内容全乱"的诡异现象。第三，msgLen 是大端序，C# 里要把四个字节手动拼成 int，不能直接用 BitConverter 默认的小端解析。

解密完成后，建议校验 receiveId 是否等于你的 corpid。这个校验成本极低，却能挡掉配置错密钥导致的数据错乱。我在生产环境就碰到过一次，测试环境密钥和线上密钥不一致，日志里看起来一切正常，但解出的消息全是另一家企业的数据——就是没做这个尾部校验。

4.3 分片消息重组流程

当单条消息超过接口传输上限时，会被拆成多个分片，每个分片是一条独立的 chatdata 记录，共享同一个 msgid，并带有分片序号信息。这种消息处理顺序错了会留下永久数据缺口。我用字典做分片缓冲：

public class FragmentBuffer { private readonly Dictionary<string, SortedDictionary<int, string>> _buffer = new(); public bool TryAdd(string msgId, int pieceNum, int pieceCount, string encrypt, out string fullEncrypt) { if (!_buffer.TryGetValue(msgId, out var dict)) { dict = new SortedDictionary<int, string>(); _buffer[msgId] = dict; } dict[pieceNum] = encrypt; if (dict.Count != pieceCount) { fullEncrypt = null; return false; } // 序号从 0 开始，防止中间缺片也被当成完整 if (dict.Keys.Min() != 0 || dict.Keys.Max() != pieceCount - 1) { _buffer.Remove(msgId); fullEncrypt = null; return false; } fullEncrypt = string.Concat(dict.Values); _buffer.Remove(msgId); return true; } }

缓冲区的逻辑要点：按 msgid 分组，分片序号做键，用 SortedDictionary 保证拼接顺序。每来一帧先判断数量是否等于总片数，数量够了再检查序号是否从 0 连续到 pieceCount-1，缺了任何一片都视为不完整，清理掉等后续重拉。数据完整、顺序正确再把加密串拼起来走 4.2 的解密流程。

这个组件的测试要刻意模拟断片场景。我会往缓冲区里故意塞一个缺中间分片的序列，确认它不会把半截数据推给解密层。上线后真正出现过这种情况：某条大文件消息的第一个分片拉取超时被跳过，后面几个分片全到了，数量上恰好等于总片数，但序号不连续——如果没有序号连续性检查，解密就会得到一截残缺数据。

4.4 把上面的代码串成一个完整服务

单看每个方法都不难，难的是把它们组织成一个能跑轮询任务的服务类。我习惯把整个流程收敛成一个方法，输入是员工 ID 和最后一次成功的 seq，输出是解析后的消息列表和新的水位：

public async Task<BatchResult> PullAndProcessOneUserAsync(string userId, long lastSeq, FragmentBuffer buffer) { var records = await PullChatDataAsync(await _tokenStore.GetTokenAsync(), userId, lastSeq); var messages = new List<ArchivedMessage>(); long maxSeq = lastSeq; foreach (var record in records) { maxSeq = Math.Max(maxSeq, record.Seq); // 带分片信息的记录先进缓冲区，拼完整后再统一解密 if (record.PieceCount > 1) { if (buffer.TryAdd(record.MsgId, record.PieceNum, record.PieceCount, record.Encrypt, out var full)) messages.Add(ParseMessage(full, record)); continue; } var plain = DecryptMsg(record.Encrypt, _encodingAesKey, out var rid); if (rid != _corpid) throw new Exception($"receiveid 不匹配: {rid}"); messages.Add(ParseMessage(plain, record)); } return new BatchResult(messages, maxSeq); }

主流程把几条核心逻辑串起来了：token 复用、游标推进、分片缓冲、解密校验、消息解析。我特别强调一点：maxSeq 的推进必须发生在解密成功之后。如果某条数据解密抛异常，整个批次的游标都不能动，否则跳过的那条消息就永远拉不到了。宁可这一批次全部重来，也不要带病前进。

服务封装时还会遇到一个并发问题：多个员工并行拉取时，各自的水位是独立的，但 FragmentBuffer 是共享的。缓冲区键是 msgid，不同员工的消息 msgid 不会冲突，所以字典是安全的设计。真正的隐患在落库，下一章讲消息解析时会展开。

5. 消息解析与落库：从密文 JSON 到可检索归档

解密只是拿到了明文字符串，它还是一段 JSON。要把数据变成能检索的归档，下一步是解析消息体、处理特殊消息类型，再落进数据库。

5.1 消息结构解析与常见 msgtype 处理

解密后的消息体 JSON 结构相对稳定，顶层有 msgtype 字段标明消息类型，不同类型挂在各自的子对象下。常见的中转 JSON 长这样：

{ "msgtype": "text", "text": { "content": "您好，请问这个型号还有货吗？" }, "msgid": "A1B2C3..." }

图片、语音、文件这类非文本消息，大多是 mediaid + 下载地址的组合，实际内容需要通过媒体文件接口另拉。C# 侧我建议做一个统一的解析入口：

public static ArchivedMessage ParseMessage(string plainJson, ChatRecord record) { using var doc = JsonDocument.Parse(plainJson); var root = doc.RootElement; var type = root.GetProperty("msgtype").GetString(); var msg = new ArchivedMessage { MsgId = record.MsgId, Seq = record.Seq, Action = record.Action, From = record.From, ToList = record.ToList, RoomId = record.RoomId, MsgTime = record.MsgTime, MsgType = type }; switch (type) { case "text": msg.Content = root.GetProperty("text").GetProperty("content").GetString(); break; case "image": msg.MediaId = root.GetProperty("image").GetProperty("media_id").GetString(); break; case "voice": // 语音消息一般带媒体 id 和时长字段 msg.MediaId = root.GetProperty("voice").GetProperty("media_id").GetString(); msg.Duration = root.GetProperty("voice").GetProperty("play_length").GetInt32(); break; // 其他类型按需扩展，至少要留默认分支打日志 default: msg.RawJson = plainJson; break; } return msg; }

解析层最容易出问题的是"只认识 text"。真实场景里语音、图片、视频、红包、文件、链接卡片全都会出现。我建议对不认识的类型一律保留原始 JSON 而不是丢弃，这样即使你的业务系统暂时用不到某些类型，数据资产也没有缺口。等后续需要扩展检索时，直接从 RawJson 里取字段，不用重新拉历史数据。

msgid 和 seq 这两个字段在落库时要一起存：seq 用来判断消息到达顺序，msgid 用来做去重。同一批数据里不可能重复，但断点重拉时同一批可能拉两遍，没有唯一索引就会产生脏数据。

5.2 撤回消息、外发记录等特殊逻辑

撤回消息是最容易被忽略的一类。员工发出一条消息又撤回，存档里不会删掉那条记录，而是追加一条 action 为 recall 的新记录。这条记录同样带 msgid 和原消息的内容，但业务含义完全不同——客户纠纷取证场景里，撤回动作本身往往就是关键证据。

落库时要区分"消息内容"和"消息状态"。我一般把撤回记录和原消息关联起来：如果按 msgid 查到了已存在的历史记录，就把原记录的状态置为 recalled，再把撤回事件单独存一条审计日志。不要看到 recall 就直接覆盖原消息内容，那样会丢掉"谁在什么时间撤回了什么"这个事实。

员工的外部联系人标识、群聊信息也要单独留意。个人会话的 tolist 通常是员工账号，群聊会话会出现 roomid 而不是 tolist。查询归档时，按人检索和按群检索是两类完全不同的需求，建表时就要留好 roomid 的独立字段，不要全部塞进备注里。

5.3 落库表设计与增量水位

归档表设计不求花哨，但要能满足常规查询。我常用的核心表结构如下：

两个唯一索引必须建到位：seq 唯一约束兜底水位推进，msgid 唯一约束兜底重拉重复插入。生产上可以用 Ignore 式插入或者 ON CONFLICT 规则，确保同一条消息不管拉几遍都只落一次。

水位表单独建一张，记录每个员工已成功处理的 seq。轮询任务的伪逻辑是：读水位 → 拉数据 → 解析入库 → 更新水位，四个步骤顺序执行，任何一步失败水位就停在原地。这里有一个工程上的取舍：如果整批里有少量消息解析失败，我倾向于整批回滚等待下次重拉，而不是跳过坏数据继续走。会话存档数据是审计级别的，存在缺口比存在延迟更致命。

6. 避坑：C# 调用会话内容存档的 5 个经典踩坑

代码能跑起来只是第一步，真正让人头大的都在细节里。下面几条都是我实际被绊过的坑，按"现象→原因→解决"列出来，你遇到时可以对照排查。

6.1 解密抛"填充无效"或解出满屏乱码

现象：调用 DecryptMsg 时 CryptoSocket 抛 Padding 异常，或者解出来的字符串乱码。

原因：八成是 EncodingAESKey 处理不对。这个 43 位字符串直接 Base64 解码会报错，必须补 "=" 凑成 44 位；另外 AES 的 Padding 设置成 PKCS7 之后，解密动作是能完成，但字节流被 API 层处理过，拆分逻辑对不上。还有一个小概率原因是 IV 用错了，取了随机值而不是 key 的前 16 字节。

解决：先打印解密后的字节流长度，对照 16 + 4 + len + corpid 长度规则；确认 EncodingAESKey 补了 "="；确认 PaddingMode.None。按这个顺序排查，五分钟内定位。

6.2 回调配置一直验证失败

现象：在管理后台保存回调 URL 时提示验证失败，但验签代码单测是过的。

原因：签名算法的排序规则不对。我用 StringComparer.Ordinal 是安全的，如果用默认字符串排序，某些环境下结果就变了。还有一种常见情况是 Controller 把 timestamp 参数解析成了 DateTime，回传时格式变了；再就是 Token 与配置页不一致，配置页里容易复制错空格。

解决：把接收到的 token、timestamp、nonce、echostr 四个原始值打日志，和计算签名的输入逐字节比对，一眼就能看出哪一项对不上。验签用字符串原样处理，不要做任何类型转换。

6.3 拉到一半数据缺失，重启后无法补回

现象：日志显示拉取过程没报错，但数据库里某员工的消息比后台看到的少了几条。

原因：游标推进时机错误。我在前面的代码里强调 maxSeq 必须解析成功后才更新，但很多初版实现是在"接口调用成功"后立刻推进游标。接口成功只代表数据拿到了，不代表解密、入库都成功。中间任何一步抛异常，游标已经越过那条消息，就再也拉不到了。

解决：严格按照"解密成功+入库成功 → 更新水位"的顺序。批次处理中任何一条失败，整体不推进，等待下轮重拉。宁可重复处理一百条，不能漏掉一条。

6.4 拉取接口频繁返回权限相关错误码

现象：部分员工的数据拉取接口稳定报权限错误，其他员工正常。

原因：不是代码问题，是授权状态问题。新员工入职、员工换部门、外包人员到期，后台的会话存档授权列表不会自动维护。精准的错误信息里会有明确的提示，但如果只是看 errcode 而没看 errmsg，很容易误判为 token 失效。

解决：把 errmsg 完整落日志。轮询任务里维护一份员工授权名单，定期和通讯录对比，把未授权或授权过期的人筛出来。数据缺口这件事，等审计时再发现就晚了。

6.5 消息类型解析不全导致入库记录畸形

现象：text 消息都正常，但库里 media_id 大量为空，某些记录 content 为 NULL。

原因：解析层只覆盖了常用的几种类型。企业微信的消息类型比预想的多，视频、文件、小程序、位置、图文链接、日程卡片等等，遇到未覆盖的类型时程序没报错，但业务字段全是默认值。

解决：解析层必须有 default 分支，把不识别的完整 JSON 存进 raw_json 字段，同时给 msg_type 保留原始值。这样后续不论补充解析逻辑还是做数据订正，都有原始材料可以重建。

7. 验证数据完整性与增量拉取技巧

任务跑通、数据开始落库后，先别急着上线，花半小时做三件事：完整性地校验、水位恢复演练、重复数据抽检。这三件事能帮你避开最尴尬的"上线十天发现少了两天数据"。

完整性校验最直接的办法是抽查。选几个活跃员工，在企业微信后台的会话存档页面按日期看消息数，再和库里该员工的同日记录数比对。数量对不上就缩小时间范围，定位到具体哪一小时开始缺的。另一个技巧是检查 seq 连续性：同一员工的 seq 理论上应该严格递增且无空洞，SQL 里用 LAG 查一下差值大于 1 的记录，那些点就是潜在缺口。

水位恢复演练是被很多人跳过的一步。把水位表里的某员工 seq 改小几千，重启轮询任务，观察是否会从旧位置重拉并正常去重落库。演练通过一次，你就有了"删库不慌"的底气——整个存档数据都可以从企业微信侧重新拉回，只是需要时间。我经历过一次数据库回滚事故，靠的就是这套水位和唯一索引，半天时间把历史数据完整重建，没有出现重复。

增量拉取还有一个值得做的优化：按消息时间做二级过滤。游标能保证不重不漏，但某些历史会话可能在某个时间点被一次性大批量补拉，这些数据对实时性要求不高。我一般会按 msgtime 做区间分组，当日的进热队列实时落库，历史补拉的数据进冷队列错峰处理，避免轮询高峰把数据库写爆。

优化手段再说一个实践技巧：落库消息时顺手把从、到、群、时间这几个维度冗余到一张宽表，日常检索只查宽表，原始明细表留作审计追溯。宽表可以按月和员工做分区，三年前的归档数据查询也只需要扫一个分区。

我第一次做这个项目时，就死在游标推进顺序上，上线一周后对账发现缺了三个半夜产生的消息批次，最后只能靠人工补拉脚本重新抓。从那以后我给自己定了个规矩：凡是跟审计挂钩的数据链路，必须先把"重跑以后不会重复"和"中断以后不会漏掉"这两件事验证通过，再谈上线。这个习惯后来救过我很多次，希望帮到你。

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