简介：Cobalt Strike 4.5 是一套面向渗透测试与红队演练的综合性攻击框架，支持多种协议的主机上线方式，集成提权、凭据导出、端口转发、Socket代理、Office宏攻击、文件捆绑与钓鱼等常用功能，并可调用Mimikatz等外部工具，适合安全研究人员、蓝队成员及有授权的攻防演练人员在真实环境中评估目标安全性。资源包为zip压缩格式，共27个文件、约49.12MB，内部除可执行程序、Java核心组件、Windows与Linux启动脚本、第三方DLL库外，还包含用户指南文档、中文界面翻译文本及配置模板，结构清晰，便于快速部署与查阅。目前已有1576人学习下载。包内提供中文版客户端与TeamServer配置文件，可直接部署协作环境；两版官方用户指南、辅助脚本与示例配置，可协助新手从原理到实战逐步上手，整体实用性强，适合安全从业者收藏备查。

1. Cobalt Strike 4.5 不是玄学黑匣子：先懂架构再谈上线

很多人把 Cobalt Strike 当成一个“点一下就能生成远控”的黑匣子，拿到 4.5 版本的第一反应就是打开 Listeners 面板，赶紧配一个监听器出来用。上线之后才发现，真正难的不是生成一个 Beacon，而是团队服务器怎么起、客户端怎么连、监听器参数怎么设，以及不同成员之间怎么共用一个会话通道。Cobalt Strike 4.5 在红队演练和授权渗透测试里的核心价值，恰恰在于它提供了一个可多人协作、可集中记录、可通过脚本扩展的 C2 平台，类似常见测试工具里“服务器 + 客户端 + 插件”的组合思路。它包含的是 socket 软件这一层的网络通道设计，而不是一个简单的生成器。本文按“架构 → 部署 → 排查 → 进阶”的顺序，把直接在 4.5 上能复现的步骤和踩过的坑一起写出来，适合刚开始接触红队工具链的人，也适合给一线测试人员当配置参考。

2. Cobalt Strike 4.5 的骨架：团队服务器、监听器与 Beacon 模式

2.1 团队服务器与客户端：什么时候该先起服务端

在 4.5 里，第一大认知转变是“Cobalt Strike 不是单机软件，而是 client-server 架构”。你的命令行、图标、报表都来自客户端，而所有的 Beacon 回调、截图、键盘记录、会话状态都由团队服务器持有。如果只有一个人做测试，可以不开团队服务器；但是只要有第二个人参与，团队服务器几乎就是必选项——它会统一保存会话、让多个客户端同时看到同一份数据，也能通过角色和数据分离去控制谁看哪台主机。

启动团队服务器，官方给的标准姿势是在安装目录下执行：

cd /opt/cobaltstrike ./teamserver 192.168.10.5 'Str0ng!Pass' jquery-3.6.profile

这段命令里的三个参数需要分开理解：第一个 IP 是团队服务器的外部可达地址，客户端连的就是这个 IP；第二个是团队服务器密码，客户端连接时要填，它既保护管理权限，也用于客户端之间的身份确认；第三个是 Malleable C2 profile 文件，用来控制 Beacon 的通信指纹，如果暂时不想定制，可以不加这个参数。这里我把三个核心参数整理成了表格：

注意一个细节：团队服务器默认监听在 50050/TCP，这是客户端通信端口；而后面要加的 HTTP/HTTPS 监听器是独立端口，两者不是一回事。我见过不少人在云主机上只放行了 80 或 443，却忘了放行 50050，结果客户端永远连不上。起服务端后可以先做一次本地确认：

ss -ltnp | grep 50050

正常会看到类似LISTEN 0 4096 *:50050的输出，说明团队服务器已经在监听。如果这里只有几个来自 Java 的进程但没在 50050 上监听，基本是启动脚本因为端口占用或 IP 不可达而提前退出了，需要回到日志里看具体异常。

再把客户端拉起来时，要填的是团队服务器的 IP、用户名和密码。这里的用户名只用在登录框里做区分，团队服务器会直接当成日志里的事件来源记录，并不参与真正的认证；真正的认证还是那个密码。所以现场多人协作时，建议每个人用不同昵称登录，排查会话来源会方便很多——这一点往往在前期没人提，等到日志乱成一团才意识到。

2.2 Beacon 回连节奏：sleep、jitter、kill date 的设定逻辑

Beacon 是 4.5 里最重要的会话形态，它不像传统反弹 shell 那样长期保持连接，而是周期性回连团队服务器，执行命令后继续休眠。这个“周期性回连”的行为就是 Beacon 的核心，它让会话看起来像正常访问，同时保留了较强的灵活性。

sleep 参数决定 Beacon 每次休眠多久再回连一次，jitter 是休眠时间的随机扰动百分比。两者必须搭配使用。我见过有人把 sleep 设置成 300 秒、jitter 设置成 0，结果 Beacon 虽然稳定，但任何命令都要等五分钟才看到回显，项目进度被拖得一塌糊涂；也见过有人为了追求实时响应把 sleep 设成 1，目标网络稍一抖动，会话就全部超时。

实际项目里我的做法是分阶段调整。刚上线调试阶段，sleep 用 30 到 60 秒，jitter 用 20%，保证每半分钟到一分钟能确认一次链路状态；等链路稳定、需要长时间潜伏时，再提高到 300 到 600 秒，jitter 保持 20% 到 30%。这样的节奏在可控性和隐蔽性之间取了一个中间值，适合大多数授权测试场景。

kill date 是另一个容易忽略的参数。它设定一个时间点，Beacon 到期后自动停止回连并自杀，避免测试结束后残留会话在目标机上。很多人上线时根本不设 kill date，等项目收尾、团队服务器都关了，才发现目标机上还有一堆没有销毁的 Beacon 进程，只能挨个手动清理。正确做法是一开始就按项目周期设定 kill date，宁可设短一点再临时延长，也不要留后患。

设置这三个参数的命令集中在 Beacon 交互窗口里：

beacon> sleep 60 20 beacon> killdate 2026/12/31 18:00:00

第一次参数是秒数，第二个参数是 jitter 占睡眠时间的百分比。kill date 的格式注意要按工具显示的本地时间格式来写，否则解析失败不会报错，而是直接忽略这条命令。设置完成后，可以通过info命令查看当前 Beacon 的完整运行参数，确认修改已经生效。

这三个参数的组合逻辑，本质上是“回连频率、回连抖动、会话生命周期”三维控制。调得越细，对网络环境的适应越好，但前提是每次改完都重新验证链路。不要只改参数不看结果，那样很容易在正式行动中踩到上一小节提到的掉线问题。

2.3 监听器类型：HTTP、HTTPS、DNS、SMB 的取舍

监听器是团队服务器上专门负责等待 Beacon 回连的通道，它和 Beacon 必须一一对应，否则就算 Beacon 已经植入，回来也找不到能接收它的监听器。监听器类型在 4.5 里有几条主线：HTTP、HTTPS、DNS、SMB、TCP。不是说功能越多越好，而是要看测试环境的条件。我把常用的选型逻辑列在下面：

每次我给团队配置监听器时，都会顺带问一句“回连是落在同一内网，还是要穿过边界设备”。这个问题的答案基本决定选型：同一内网直接走 SMB 或 TCP 会更快，回连特征更少；跨网段优先 HTTPS，因为很多安全设备对 443 的容忍度高；如果连 HTTPS 都被限制，才去考虑 DNS 通道。反过来，一上来就配了一个 8888 端口的 HTTP 监听器，往往是回连失败率最高的配置——不是因为工具不行，而是因为选型与实际网络环境不匹配。

这里还要提醒一点：监听器配置里的端口不是一个纯技术参数，它同时影响防火墙策略、流量监控规则和告警阈值。443 端口在多数边界设备上是白名单，但如果你把监听器绑在 0.0.0.0 的 443 端口上，而本机又已经有一个 Web 服务占用了同一个 socket，就会出现监听器起不来的情况。后面避坑章里我会专门写这条。

DNS 监听器比较特殊，它需要你拥有可控域名的 NS 记录或 A 记录，Beacon 通过 DNS 查询把数据放在域名解析结果里回传。优点是出网条件极苛刻时还能用，缺点是延迟高、速度慢，只适合传递小数据块。如果你打算在项目里用 DNS 监听器，务必先确认域名解析链路完整可用，再生成对应的 DNS Beacon，否则很容易出现“能解析但不上线”的诡异问题。

2.4 Aggressor 脚本：Cobalt Strike 4.5 的“插件”形态

很多从其他工具转过来的人会问 Cobalt Strike 有没有插件机制，答案是 Aggressor Script。它是 4.5 里最接近“插件”的东西，用类 Java 语法编写，可以挂接事件、扩展菜单、添加自动化逻辑。你可以把它当作团队服务器的“外挂脚本”，既能给所有客户端加统一的菜单项，也能在 Beacon 上线时自动触发提醒。

一个最简单的脚本文件长这样：

on beacon_initial { println(" ==> 新的 Beacon 上线，session id: " + $1); }

脚本逻辑并不复杂：on beacon_initial是事件入口，表示某个 Beacon 第一次和团队服务器建立联系时触发；$1是事件上下文中携带的 session id，客户端会把这一行消息打到自己的事件窗口。对于一个几十人的红队来说，这个脚本的价值是让所有参与者第一时间感知到新增会话，而不是反复刷列表。

再复杂一点，可以在脚本里把菜单项挂到 Beacon 右键菜单上。常见的做法是定义一个菜单项，点击后直接让目标机感知一条测试命令，例如收集当前用户信息。这样团队成员不用记住每个 Beacon 的命令行语法，只需要在图形界面里点选即可。Aggressor 脚本也支持变量作用域、函数封装和定时任务，几乎可以覆盖平时手动操作的绝大多数场景。

加载方式有两种：一是在客户端顶部菜单打开 Script Manager，把 .cna 文件拖进去执行；二是在启动团队服务器时，把脚本路径作为参数带进去。第二种方式适合“所有客户端都必须加载同样策略”的场景，比如团队约定的统一别名、统一命令封装，写在启动参数里就能保证每个登录的人看到的界面一致。我一般会把团队公共脚本做成一个固定加载项，每次起服务都带上，彻底杜绝“某个客户端漏加载脚本”的问题。

3. 把 4.5 转成可用的 C2：从命令行启动到一条 Beacon 回连

3.1 服务端与客户端启动：参数错了后面全是白忙

我习惯把 Cobalt Strike 的启动过程拆成两层看：第一层是团队服务器进程，第二层是客户端 GUI。一层没起来，后面所有操作都无从谈起。先给一个更完整的启动脚本示例，它包含 Malleable C2 profile 和 Aggressor 脚本的同时加载：

cd /opt/cobaltstrike ./teamserver 0.0.0.0 'Server@2024' jquery.profile \ --script team-autoload.cna

这里的关注点有三个。第一个是0.0.0.0，它表示团队服务器监听所有可用网卡地址，适合服务器有多个网卡、不确定客户端从哪个网段过来的场景；如果只绑内网 IP，跨网段客户端就连不上了。第二个是jquery.profile，它决定 Beacon 回连时的 HTTP 请求长什么样，包括 URI、User-Agent、Cookie 字段等；第三个是--script参数，它让 Aggressor 脚本在团队服务器侧自动加载，不需要客户端手动执行。

启动后建议立刻做一次连通性验证，而不是急着点 GUI。我在多台服务器上验证过，最简单有效的方式是直接看端口监听状态和进程状态：

ps -ef | grep java | grep -v grep ss -ltnp | grep -E "50050|443"

正常情况下会看到两个 java 相关进程，一个负责团队服务器，一个负责后面的监听器管理。如果 50050 在监听但 443 没起来，那不是团队服务器的问题，而是后续加的 HTTPS 监听器还没生成，需要在 GUI 里确认监听器状态。很多人习惯一旦上不了线就怀疑 Beaccon 配置，其实更常见的坑是团队服务器启动时只看到程序跑起来了，但监听器在 GUI 里处于红色不可用状态。

客户端启动时，如果是 Linux 或 macOS，直接执行安装目录下的./cobaltstrike脚本；如果是 Windows，则运行cobaltstrike.bat。客户端输入团队服务器 IP、用户名和密码后，会和团队服务器建立长连接。这里有一个容易被忽略的细节：客户端与团队服务器之间的连接不是一次性请求，而是持续保持的长连接，所以客户端所在网络如果对长连接有限制，也会出现登录成功但随后不断掉线的情况。

3.2 配置 HTTPS 监听器：字段不是越多越好

监听器配置面板里有大量字段，新手容易把每一项都填满，结果反而把简单问题复杂化。对于 HTTPS 监听器，最重要的是四组字段：HTTP Host、HTTP Host Stager、HTTPS Port、Profile。四者之间的关系可以这样理解：Beacon 回连时访问的域名写在 HTTP Host 里，实际连接的端口是 HTTPS Port，流量伪装由 Profile 决定，而 HTTP Host Stager 管的是“预置在载荷里的下载地址”。

一个常见的合规配置可以按下面这张表来填：

注意这里有一个反直觉的点：HTTP Host 和 HTTP Host Stager 不一定要相同。HTTP Host 是 Beacon 最终回连的地址，HTTP Host Stager 是载荷启动后去拉下一段内容时用的地址。在生产交付场景里，两者分离可以让第一阶段载荷指向一个临时域名，真正上线后切换到正式域名，这样即使早期域名被拉黑，也不影响已经植入的 Beacon。我一般会在测试阶段把两者写同一个值，减少变量；正式做项目时再拆开。注意这段话讨论的是授权的渗透测试项目，不要把分离逻辑用在不该用的地方。

Profile 文件这里多说一句。4.5 里自带的c2lint工具可以对 profile 做静态验证，减少配置错误上线的概率。比如你想自定义一个监听器，让它看起来像常见的静态资源请求，可以写一个简化版 profile：

http-get { set uri "/jquery-3.6.min.js"; set User-Agent "Mozilla/5.0 (Windows NT 10.0; Win64; x64)"; client { header "Accept" "text/javascript"; metadata { base64; prepend "var token='"; append "';"; header "Cookie"; } } }

这个片段定义了 HTTP GET 请求的 URI、User-Agent 和 metadata 的编码方式。注意base64表示先把元数据做一次 Base64 编码，再通过prepend和append加上前后缀，最终放到 Cookie 字段里回传。实际项目里不会只用这么简单的变换，但这几行足够说明 Profile 的核心作用：让每次回连的请求形态更贴近真实业务流量，避免一眼就被识别出是默认特征。

3.3 生成 Beacon 并完成首次回连：一次完整的验证流

监听器配完之后，先别急着生成很多东西，应该先做一次最小化验证。我把这个流程固定成四步。

第一步，在客户端顶部菜单进 Attack → Packages → Windows Executable (S)，生成一个包含 Stager 的可执行文件。这里的“Staged”表示第一阶段先建立连接，再拉取完整的 Beacon 代码，因此文件体积极小，适合网络环境复杂的场景；另一种Windows Executable不带括号后缀，是 Stageless，会把整个 Beacon 打进行程里，体积大但依赖阶段少。

第二步，把生成的文件放到一台与团队服务器网络可达、且已获得授权的测试机里，先在本机用杀毒软件扫一遍看是否自带误报，然后再执行。

第三步，回到客户端 GUI，打开 View → Applications，观察是否新增了一个 Beacon 条目。如果条目出现，说明会话已建立，可以右键进入 Beacon 命令交互窗口。

第四步，在交互窗口执行一次最基础的回显命令，验证通道双向通信是否正常：

beacon> shell whoami

如果返回的结果带有主机名和用户信息，说明 Beacon 的上下行链路都通了。这条命令不是白跑的——它同时验证了 Beacon 命令解析、目标机命令执行和结果回传三条链路。如果你只看到 Beacon 上线但执行命令没有任何回显，多半是监听器的 Profile 里没有写上下行通信的数据变换规则，或者 Beacon 与团队服务器的网络路径上存在丢包。

我把最后这段流程单独提出来，是因为很多人第一次跑通时根本不记录“上线时间、监听器类型、Profile 文件版本”这三个信息。等到第二次测试出了问题，想对比第一次和第二次的差异，却发现完全没有参照，只能整个环境重来。所以我建议每次生成载荷之前，先在本地维护一个简单的文本记录，把监听器名称、Profile 文件名、生成时间和目标机类型写清楚。这是成本最低的后悔药。

3.4 用 Shell 脚本固化“上线验证”：简化重复操作

当项目里需要同时管理多个监听器、多份 Profile 时，我习惯把启动和验证过程固化成脚本。以下是我的做法之一，供参考：

#!/bin/bash PROFILE="jquery-3.6.profile" TEAMIP="0.0.0.0" PASS="Server@2024" LOG="startup_$(date +%Y%m%d_%H%M%S).log" ./teamserver "$TEAMIP" "$PASS" "$PROFILE" > "$LOG" 2>&1 & echo "teamserver started, pid: $!" sleep 3 ss -ltnp | grep -E "50050|443" | tee -a "$LOG"

脚本做的事很简单：先启动团队服务器，把标准输出和标准错误都写入带时间戳的日志文件，隔三秒检查 50050 与 443 端口；再把检查结果追加进同一个日志。这样做的好处是，每次启动的配置、时间、端口状态都有据可查，不会出现“上一次是怎么起的”这种问号。

实际使用时要注意一个变量：如果服务器上已经占用了 443 端口，grep搜不到对应空结果，这个脚本会以为启动失败，但真正原因可能是监听器还没生成。脚本只能帮你缩短排查时间，不能代替你去看日志。我通常会在脚本跑完后，再人工看一眼启动日志尾部有没有 Exception。

4. 避坑：Cobalt Strike 4.5 使用中的五个翻车现场

4.1 客户端一直提示无法连接团队服务器

现象：客户端启动后输入团队服务器 IP 和密码，界面停在“Connecting”状态，过几秒提示连接超时。

原因：最常见的是云主机安全组或本机防火墙没有放行 50050/TCP。团队服务器默认监听 50050，客户端与服务器通信全靠这个端口，其他端口放行得再多也到不了客户端连接这一步。另一种原因是团队服务器绑定了内网 IP，客户端却用外网 IP 去连。

解决：先在团队服务器上执行ss -ltnp | grep 50050，确认它确实在监听；再在另一台机器上用nc -vz 服务器IP 50050测试端口连通性；如果是云主机，检查安全组入方向是否放行了 TCP/50050。绑内网 IP 的场景，就把 teamserver 启动参数的第一个值改成 0.0.0.0，让所有网卡都可用。实践里我会把端口连通性测试放在首位，因为安全组配置错误的比例远高于工具自身问题。

4.2 Beacon 刚上线就掉线，事件日志里全是超时

现象：会话列表中能看到 Beacon，但几秒后变灰，再次刷新时消失；事件日志中频繁出现类似 timeout 的提示。

原因：Beacon 的 sleep 间隔设得太小。默认配置下 Beacon 会按设定的时间周期回连，如果sleep 5而且目标网络延迟较高，Beacon 请求还没到团队服务器，客户端侧就会判定超时并标记离线；反过来，sleep 设得太大，比如 4 小时，就会出现“看起来根本不在线”的假象。

解决：把 sleep 调到 30 到 60 秒之间，同时把 jitter 控制在 20% 左右，先确认目标网络到团队服务器这条路径的通畅程度，再逐步收敛。不要一上来就追求低频回连——那是在链路已经验证之后才做的优化。这个坑我踩过一次之后，每次新建监听器都会先看目标机的网络延迟，再决定初始 sleep 值。

4.3 目标机上进程能起来，但 Beacon 就是不上线

现象：生成的 payload 在测试机进程列表里有进程，但没有新的 Beacon 出现在 Applications 面板，事件日志里也没有任何报错。

原因：payload 里的监听器信息和当前监听器不匹配。比如生成 payload 时选择的是 HTTP 监听器，但团队服务器上后来把监听器配置改成了 HTTPS，Payload 里的下载地址和回调地址全部失效。另一个原因是第一阶段 Stager 去找后续代码时拿不到，常见于 HTTP Host Stager 写了一个内网 IP，但目标机走的是外网路径。

解决：检查生成 payload 时用的监听器名与当前监听器名是否一致；再去确认 HTTP Host Stager 填写的是目标机实际能访问到的地址。最简单的方法是重新生成一次 payload，不要在原文件上改端口改 IP，这能排除掉很多“看起来改了其实没改”的误操作。生成 payload 时我一般会截图保存监听器配置，后续对比时一眼就能看出差异。

4.4 HTTPS 监听器在 GUI 里显示红色，端口起不来

现象：监听器列表里 HTTPS 条目是红色或不可用状态，日志显示 Bind Exception，提示端口已被占用或 socket 绑定失败。

原因：443 端口被目标系统或同一台服务器上的其他服务占用，或者当前用户没有权限监听 1024 以下的端口。Linux 上非 root 用户经常遇到后者，Java 进程抛出 permission denied。

解决：确认监听器端口改用 8443 或其他高位端口，验证服务能否起来；如果必须用 443，让团队服务器以足够权限运行，或者使用 setcap 为 Java 进程放开低端口绑定权限。注意 socket 绑定地址不要写成内网 IP，应该写 0.0.0.0 或公网可访问地址，否则外部流量进不来。遇到这个报错时不用慌，先用netstat -ltnp | grep :443看占用，再决定是换端口还是清理冲突服务。

4.5 团队服务器的日志文件看不到有价值的记录

现象：一个项目做完，想回看某条命令是什么时间执行、结果是什么，结果在日志目录里只有启动信息，完全找不到操作记录。

原因：Cobalt Strike 默认会把大量事件输出到客户端界面，团队服务器进程也会在终端输出一部分，但不一定会把所有命令回显落盘。如果直接从团队服务器的安装目录去找，很可能只看到日志分割文件或空目录。

解决：在客户端顶部菜单打开 Event Log 并将视图切到会话日志，先确认事件已实时显示；再通过脚本把事件导出成文件。Aggressor 脚本里提供事件钩子，可以在每次命令执行时把数据写入独立日志文件——这在多人协作时几乎是必备配置，因为单靠 GUI 翻历史记录在会话多的时候根本来不及。

以下是我平常用的一段 Aggressor 脚本片段，用于把事件追加到文件里：

on appendText { local('$logFile'); $logFile = "/tmp/cobalt-events.log"; writeFile($logFile, $1); }

这里on appendText会捕捉客户端事件流中的每一条文本，writeFile把内容追加到指定路径。注意这个脚本必须每个客户端都加载，否则只记录自己窗口里的内容，其他人执行的操作不会被记录。我在团队里统一要求所有人登录后必须加载同一套日志脚本，否则不参与当次项目，这样日志才能回收到同一个文件里。

5. 进阶：给 Cobalt Strike 4.5 加一道“验证关”：配置自查与回滚

刚接触时大家都急着上线，等遇到过几次“上一次能通、这一次不通”的问题后，我开始给团队定了一条规定：所有 Malleable C2 profile 和 Aggressor 脚本都必须经过静态验证并纳入版本管理，不允许“先改后试”直接丢到团队服务器上。

第一步是静态校验。Cobalt Strike 4.5 附带的c2lint工具就是干这个用的，它会对 profile 文件做语法和结构检查，告诉你哪些 transform 块不合法、哪些字段缺少必要参数。我平时会在提交前跑一遍：

cd /opt/cobaltstrike ./c2lint jquery-3.6.profile

输出里如果出现ERROR:前缀，profile 大概率不能正常加载；如果只有WARNING:或INFO:，要看具体提示再决定是否调整，因为部分警告只是对某些字段的建议，并不影响启动。这个工具本身不复杂，但很多人会跳过它，因为 GUI 启动时并不强制检查 profile 内容，只有在团队服务器启动时才会一次性报错。先静态过一次，就能把多数低级错误挡在启动之前。

第二步是部署后做一次链路自检。在目标机网络可达的前提下，我一般会先看监听器的访问日志，而不是急着发命令。比如 HTTPS 监听器上如果出现了多条带特定 URI 的请求，说明 Beacon 的 HTTP 流量确实到达了团队服务器；如果没有这些请求，问题大概率出在网络路径或域名解析，而不是监听器本身。

第三步也是我最看重的一步：用 git 管理所有 profile 和脚本变更。红队演练周期短，经常出现“今天调了 UA、明天调了 URI、后天又改回昨天的版本”的情况。没有版本管理时，线上配置和本地文件分叉，出了问题根本不知道是哪一次改动引入的。我的做法是在 Cobalt Strike 安装目录外建一个profiles/和scripts/目录，所有用到的 .profile 和 .cna 文件都提交进 git，每次改动先 commit 再上服务器。这样一旦新配置上线后行为异常，直接git revert回退到上一个稳定版本，重载 profile 即可。

从那以后，我每次调整 profile 都会强制走一遍“静态验证 → 记录 commit → 上线 → 看监听器访问日志”的流程，自己没再因为配置改挂而造成整个测试链路中断，也希望这套验证流程在你自己的项目里能帮你少走弯路。

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