简介：本资源是一份面向存储网络工程师、数据中心运维人员及SAN技术学习者的博科（Brocade Fabric）光纤交换机实战型培训文档，聚焦FC交换机日常运维、基础配置与通道业务部署等核心能力提升。文档系统覆盖OS功能模块对比（FC vs 以太网/TCP/IP）、Console/SSH登录、账号密码与管理IP配置、Zone/VSAN创建与激活、Port Channel组建、巡检命令（show system/port/flogi）及排障日志收集等关键操作，内容结构清晰，含详细步骤、命令示例与典型场景说明。资源为单文件PDF格式，共1个3.28MB的高质量培训手册，页数达25页，目录层级完整，便于按需查阅。目前已有1898人学习下载，适合初入存储网络领域的技术人员快速掌握博科交换机配置逻辑与生产环境实操要点。
1. 博科光纤交换机运维手册：一份能直接上手查故障、配Zone、救级联的实战文档
你刚接手一台博科 G620，面板灯全绿，switchshow显示Online，但存储主机连不上阵列——fcping不通，zoneshow里 zone 名字对得上，cfgactvshow却显示配置文件没生效。你翻遍 Web 界面，在“Configuration”菜单下点来点去，找不到“保存并激活”按钮；SSH 连进去敲cfgsave，提示No changes to save；再试cfgEnable "my_cfg"，报错Configuration not found。这不是设备坏了，是你缺一份按真实排障节奏组织、带命令上下文、标出关键陷阱的文档。这份 25 页的博科 Fabric 交换机培训材料，不是概念说明书，而是某数据中心一线工程师把三年踩坑经验压进操作步骤的压缩包：它从串口登录第一行命令开始写，把porterrshow里Enc_Out和Crc_Err同时飙升怎么定位光模块故障、zoneObjectRename后为什么cfgsave必须跟cfgEnable才算真正生效、级联时 Domain ID 改成 239 为什么比改成 2 更安全，全拆解成可抄、可验、可 debug 的动作。适合刚接触 FC-SAN 的存储工程师、负责 SAN 日常巡检的运维同学，以及需要快速接管博科环境的第三方支持人员——它不讲 FC 协议栈有多优雅，只告诉你哪条命令敲完要等 3 秒再敲下一条，哪条输出里藏着光衰临界值。
2. 博科交换机 OS 架构与 FC-SAN 核心差异：为什么不能当以太网交换机用
FC-SAN 环境里，博科交换机不是“转发帧”的设备，而是“管理 Fabric”的控制器。它的 OS（Fabric OS）和以太网交换机的 IOS/NX-OS 有本质区别：没有 VLAN、没有 ARP、没有三层路由表。理解这个前提，才能避开把ipaddrset当成万能配置入口、在portshow里找“up/down”状态这类低级错误。本章不堆协议图，只聚焦三个实操中立刻会撞上的硬差异。
2.1 FC 交换机与以太网交换机的底层行为断层
以太网交换机的核心是 MAC 地址学习 + 转发决策，而博科 FC 交换机的核心是Name Server 注册 + Zone 成员校验。这意味着：
- 没有“端口 up/down”概念：
portshow输出里Online表示物理链路建立且通过了 FC 初始化握手（FLOGI），No_Light表示光纤未插或光功率不足，但绝不会出现以太网里常见的Administratively Down或Link Down。如果你看到端口状态是No_Light，第一反应不是no shutdown，而是拿光功率计测 SFP+ 模块的Tx Power和Rx Power。 - 配置不生效 ≠ 命令没敲对：以太网交换机
write memory后配置即固化，而博科的cfgsave只是把当前内存中的 Zone 配置写入非易失存储（NVRAM），但必须执行cfgEnable才真正加载到 Fabric 运行时。这是新人翻车最高频的点——cfgsave成功后就去喝咖啡，结果业务完全没通，因为配置根本没激活。 - “关闭端口”不等于断开链路：
portdisable 47是让端口停止参与 Fabric 发现（FLOGI/FDISC），但物理光信号仍在发射。如果对端设备没做对应处理，可能触发持续重传导致Enc_Out错误累积。真正的链路隔离靠的是 Zone 配置——把 WWN 从 zone 里移除，比 disable 端口更干净。
提示：别被
switchshow里Enabled状态迷惑。它只表示交换机本身处于可管理状态，和业务流量是否通毫无关系。判断业务是否就绪，唯一可靠指标是fcping通 +fabStatsShow中对应端口的Tx Frames/Rx Frames计数器在增长。
2.2 FC 协议栈 vs TCP/IP：为什么 HBA 卡不占 CPU，但你的监控脚本会卡死
FC 协议栈（FC-0 到 FC-4）全部在 HBA 卡的 ASIC 硬件里终结，主机 CPU 只收发 SCSI 命令和数据块。而 TCP/IP 协议栈运行在主机内核，每个 IP 包都要经历软中断、协议栈解析、内存拷贝。这导致两个关键运维现象：
sfpshow的Rx Power值必须人工盯：以太网有自动协商和链路自愈机制，光衰到临界值时网卡会主动降速或告警；FC 没这套，sfpshow 47显示Rx Power: 398 uW是安全阈值，低于350 uW就可能引发Crc_Err，但交换机不会自动 down 掉端口，业务会间歇性超时。你得自己写脚本每 5 分钟抓一次sfpshow，存入时序数据库画趋势图。supportshow是救命稻草，但别指望它自动分析：以太网交换机show tech-support会打包所有日志和配置；博科的supportshow只是把errdump、dmesg、fabriclog等原始二进制日志打包，里面全是十六进制地址和寄存器值。没有errdump -f解析，你看到的就是一串乱码。某次生产事故中，supportshow里errdump的第 3 行0x000000000000000a对应Port Buffer Overflow，但没人查手册，硬是花了 4 小时才定位到portbuffershow里 buffer 分配不足。
2.3 博科 Fabric OS 的服务模块：哪些能动，哪些碰都别碰
Fabric OS 把功能拆成独立服务进程，每个服务有明确职责和权限边界。日常运维只该动management和alias服务，其他服务修改会导致 Fabric 崩溃：
| 服务名 | 是否可配置 | 关键说明 | 实操风险 |
|---|---|---|---|
management | ✅ 是 | 所有 CLI/Web 配置入口，ipaddrset、timeout、switchname全走这里 | 修改ipaddrset后需save，否则重启丢失 |
alias | ✅ 是 | 管理 WWN 别名，alicreate/aliremove操作对象 | 别名删除后，依赖它的 zone 会失效，但zoneshow不报错 |
nameserver | ❌ 否 | 自动注册节点 WWN，alishow输出即来自此服务 | 强制重启会清空 Fabric 设备列表，业务中断 |
fabriccontroller | ❌ 否 | 监控 Fabric 拓扑变化，fabricshow数据源 | fabriccontroller --restart会触发全 Fabric 重新发现，持续 30 秒以上无响应 |
timeservice | ⚠️ 谨慎 | tsclockserver配置 NTP，但date命令不可用 | 时间偏差 > 5 秒，supportshow日志时间戳错乱，排障难度翻倍 |
注意：
portcfgtrunkport 47并不是开启端口聚合，而是启用 ISL（Inter-Switch Link）Trunking 功能，让多个物理端口捆绑成一个逻辑 ISL。它和以太网 LACP 完全无关，配置后必须在对端交换机执行相同命令，且两端domainid必须不同。新手常误以为这是“端口通道”，结果配完发现ISLshow里状态是Trunking Inactive。
3. 交换机基础管理：从串口登录到配置固化，每一步都标好“等待点”
博科交换机的 CLI 是强状态机，很多命令执行后必须等待 Fabric 确认，否则后续命令会失败。这份手册把switchdisable后要等几秒、cfgsave后为什么不能立刻cfgEnable、portcfglongdistance配置后必须switchenable才生效，全写进步骤里。拒绝“敲完回车就完事”的模糊指引。
3.1 三种登录方式的实操细节与避坑
Serial 串口连接（最稳，首选）
使用 USB-to-Serial 线（如 CP2102 芯片），终端软件设为：
- 波特率：115200
- 数据位：8
- 停止位：1
- 校验位：None
- 流控：None
# 登录后第一件事：确认当前用户权限 admin> whoami User: admin, Role: admin # 如果显示 role: user，则无权执行 cfgsave/cfgEnable，必须联系管理员提权SSH 连接（推荐，但版本敏感）
G620 要求 OpenSSH 7.0+，G6510 要求 OpenSSH 6.0+。禁用密码登录，强制密钥认证：
# 生成密钥（本地） ssh-keygen -t rsa -b 4096 -f ~/.ssh/brocade_id_rsa # 上传公钥到交换机（需先用密码登录一次） admin> sshutil importkey admin ~/.ssh/brocade_id_rsa.pub # 后续登录 ssh -i ~/.ssh/brocade_id_rsa admin@10.77.77.77Web GUI（仅限 G620/G6510，且必须装 Java）
G620 需 Java 8u202+，G6510 需 Java 7u80+。Chrome/Firefox 现代浏览器默认禁用 NPAPI 插件，必须用 IE11 或 Edge Legacy 模式访问https://10.77.77.77。Web 界面里Configuration → Zone Configuration的“Save”按钮实际执行的是cfgsave，但没有cfgEnable按钮——这是 Web 界面最大坑，必须切回 CLI 激活。
3.2 关键配置命令的完整闭环流程
所有配置必须遵循“修改 → 保存 → 激活 → 验证”四步闭环，漏任何一步都等于没配。
修改管理 IP（ipaddrset）
# 1. 查看当前管理口（通常是 port 0） admin> ipaddrshow IP Address: 10.77.77.77 Subnet Mask: 255.255.255.0 Gateway: 0.0.0.0 # 2. 修改为新地址（立即生效，无需重启） admin> ipaddrset IP Address [10.77.77.77]: 172.16.254.73 Subnet Mask [255.255.255.0]: 255.255.255.0 Gateway [0.0.0.0]: 172.16.254.1 # 3. 验证（注意：新 IP 生效后，原 SSH 会话会断开） admin> ipaddrshow IP Address: 172.16.254.73 # 确认已变更修改账号密码（passwd）
# 1. 修改 admin 密码（必须输入原密码） admin> passwd admin Old password: ******** New password: ******** Confirm new password: ******** # 2. 验证：新开 SSH 会话用新密码登录 # 3. 重要：Web GUI 密码不同步！Web 界面密码需单独在 GUI 里修改配置时间服务器（tsclockserver）
# 1. 设置 NTP 服务器（必须是 Fabric 内可达的地址） admin> tsclockserver "10.31.255.254" # 2. 强制同步一次（避免等待自动轮询） admin> clocksync # 3. 验证时间（注意：date 命令不可用，用 uptime 看系统启动时间推算） admin> uptime System uptime is 12 days, 4 hours, 22 minutes # 结合 `supportshow` 里 `errdump` 时间戳交叉验证3.3 端口状态诊断：portshow、porterrshow、sfpshow三件套联动分析
单看一个命令输出会误判，必须三者联动。某次故障中，portshow 47显示Online，porterrshow 47的Enc_Out为 0，但业务延迟高，最后sfpshow 47发现Rx Power: 342 uW（低于 350 uW 安全线），更换 SFP+ 模块后解决。
# 步骤 1：看端口基础状态 admin> portshow 47 Port 47: Index: 47 Online Speed: 16Gb Type: E-Port # 级联端口，如果是 F-Port 则是服务器/存储直连 # 步骤 2：看错误计数器（重点关注 Enc_Out, Crc_Err, Disc_In） admin> porterrshow 47 Error Statistics for Port 47: Enc_Out: 0 # 编码错误，光模块或光纤问题 Crc_Err: 0 # CRC 校验失败，通常伴随 Enc_Out Disc_In: 12 # 接收丢弃，buffer 不足或速率不匹配 Link_Fail: 0 # 步骤 3：看光功率（单位 uW，非 dBm！） admin> sfpshow 47 SFP Information for Port 47: Rx Power: 398 uW # ≥398 uW 正常，350~397 uW 警告，<350 uW 故障 Tx Power: 850 uW Temperature: 42 C逻辑说明：
Enc_Out单独升高 → 光纤弯折/污染；Enc_Out和Crc_Err同时升高 → SFP+ 模块老化；Disc_In持续增长 →portbuffershow 47查 buffer 分配是否不足，或对端设备速率协商异常（如一端 16G，一端 8G）。
4. FC 通道业务配置：Zone 创建、生效、调试的完整链路与避坑指南
Zone 配置是博科运维的核心，但zonecreate、cfgAdd、cfgEnable这三个命令的执行顺序和依赖关系，官方文档写得极其隐晦。本章用真实案例还原：从新建一个名为STORAGE_ZONE的 Zone，到让它真正承载业务流量，每一步的中间状态、验证方法、失败回滚方案，全部写透。
4.1 Zone 配置的原子操作：创建、添加、保存、激活四步法
Zone 配置不是“创建即生效”，而是一个分阶段提交过程。必须严格按顺序执行，否则cfgEnable会报Configuration not found。
# 场景：为两台 ESXi 主机和一台存储阵列创建 Zone # ESXi1 WWN: 51:40:2E:c0:15:54:F5:14 # ESXi2 WWN: 51:40:2E:c0:15:54:F5:15 # Storage WWN: 20:00:00:00:00:00:00:01 # 步骤 1：创建别名（AliCreate），为 WWN 起易读名字 admin> alicreate "ESXi1_Host", "51:40:2E:c0:15:54:F5:14" admin> alicreate "ESXi2_Host", "51:40:2E:c0:15:54:F5:15" admin> alicreate "Storage_Array", "20:00:00:00:00:00:00:01" # 步骤 2：创建 Zone（zonecreate），用别名而非 WWN（降低维护成本） admin> zonecreate "STORAGE_ZONE", "ESXi1_Host;ESXi2_Host;Storage_Array" # 步骤 3：创建配置文件（cfgCreate），并把 Zone 加入其中 admin> cfgcreate "PROD_CFG", "STORAGE_ZONE" # 步骤 4：保存到 NVRAM（cfgsave）——此时配置在内存，未固化 admin> cfgsave # 输出：Configuration committed successfully. # 步骤 5：激活配置文件（cfgEnable）——此时 Zone 才真正生效 admin> cfgenable "PROD_CFG" # 输出：Zone configuration "PROD_CFG" enabled successfully.参数说明：
cfgcreate "PROD_CFG", "STORAGE_ZONE"中的"STORAGE_ZONE"是 zone 名，不是别名名；cfgenable的参数必须是cfgcreate时指定的配置文件名，不是 zone 名。cfgactvshow会显示当前生效的配置文件名，zoneshow显示所有已定义的 zone（无论是否在生效配置中）。
4.2 Zone 配置的动态维护：增删改成员与重命名的血泪经验
生产环境 Zone 不是一次性配置，需频繁调整。但aliadd/aliremove和zoneadd/zoneremove的行为差异极大，搞错会导致业务中断。
# 场景：给 STORAGE_ZONE 新增一台备份服务器（WWN: 51:40:2E:c0:15:54:F5:16） # 方法 1：直接加到 zone（推荐，影响最小） admin> zoneadd "STORAGE_ZONE", "51:40:2E:c0:15:54:F5:16" # 方法 2：先建别名再加（适合长期维护） admin> alicreate "Backup_Server", "51:40:2E:c0:15:54:F5:16" admin> zoneadd "STORAGE_ZONE", "Backup_Server" # 场景：移除已下线的 ESXi1_Host # 错误做法：直接 alidelete（会全局删除，所有 zone 失效！） admin> alidelete "ESXi1_Host" # ⚠️ 危险！别名删除后，所有引用它的 zone 都失效 # 正确做法：只从 zone 移除成员 admin> zoneremove "STORAGE_ZONE", "ESXi1_Host" # 然后保存并激活（必须！） admin> cfgsave admin> cfgenable "PROD_CFG"4.3 Zone 配置避坑：5 条真实翻车记录与解决方案
现象 1：cfgEnable "PROD_CFG"报错Configuration not found
→ 原因：cfgcreate时拼错了配置文件名（如输成"PROD_CF"），或cfgsave前执行了cfgclear清空了内存配置。
→ 解决：用cfgshow查看所有已创建的配置文件名，确认拼写；若配置丢失，从supportshow的cfgbackup.txt恢复。
现象 2：zoneshow能看到STORAGE_ZONE，但fcping不通
→ 原因：STORAGE_ZONE已创建，但未加入任何配置文件，或加入了配置文件但未cfgEnable。
→ 解决：cfgshow查STORAGE_ZONE是否在某个配置文件里；cfgactvshow确认当前生效的是哪个配置文件。
现象 3：zoneObjectRename "STORAGE_ZONE" "STORAGE_ZONE_V2"后，fcping突然不通
→ 原因：重命名 zone 后，必须cfgsave+cfgEnable才生效，但旧配置文件里仍引用旧 zone 名。
→ 解决：cfgshow "PROD_CFG"查旧配置文件内容 →cfgdelete "PROD_CFG"删除旧配置 →cfgcreate "PROD_CFG", "STORAGE_ZONE_V2"→cfgsave→cfgEnable。
现象 4：aliremove "ESXi1_Host" "51:40:2E:c0:15:54:F5:14"失败，提示Alias not found
→ 原因：aliremove的第二个参数是成员名（WWN 或别名），不是别名名。正确命令是aliremove "ESXi1_Host"（只删别名本身）。
→ 解决：删成员用zoneremove，删别名用alidelete，别混。
现象 5：级联交换机上fabricshow显示UPstream，但fcping跨交换机不通
→ 原因：主交换机和从交换机的domainid冲突（都为 1），或portcfgtrunkport只在主端配，从端没配。
→ 解决：switchshow查 domainid →configure进入 fabric 参数配置 → 改从交换机 domainid 为 2 →portcfgtrunkport在两端端口都执行。
5. 级联与长距离配置：Domain ID、Trunk、LD 模式的硬核参数设置
博科级联不是插根光纤就完事。domainid冲突、portcfgtrunkport漏配、portcfglongdistance参数错配，任何一个都会导致 Fabric 分裂。本章给出 G620/G6510 在 10km、100km、500km 三种距离下的实测参数组合，并解释为什么LD模式比LS模式更省心。
5.1 Domain ID 规划：为什么选 239 而不是 2
Fabric 内所有交换机的domainid必须唯一，范围 1-239。新手常把第二台交换机domainid设为 2，但这是危险操作：
- ID 2 是默认 Fabric 控制器 ID：当主交换机宕机，ID 2 的交换机会尝试接管 Fabric 控制权，可能引发拓扑震荡。
- ID 1-16 是保留 ID：部分老设备固件将 1-16 用于内部通信，冲突概率高。
- 实测结论：生产环境
domainid应避开 1-32，优先选 200-239 区间。某次割接中，将从交换机domainid从 2 改为 239 后，fabricshow的Fabric ID稳定，再无Split Fabric告警。
# 修改 domainid（必须先 switchdisable） admin> switchdisable # 等待 30 秒，确保 Fabric 稳定 admin> configure Fabric parameters (yes, y, no, n) : [no] y Domain ID [1]: 239 # 其余参数按 Ctrl-D 跳过 admin> switchenable # 验证 admin> switchshow | grep "Domain" Domain: 2395.2 Trunk 端口配置：portcfgtrunkport的执行时机与验证
Trunk 不是“开启端口聚合”，而是启用 ISL 的多路径负载均衡。必须在两端交换机的对应端口上执行，且domainid不同。
# 主交换机（domainid 1）端口 47 配置 Trunk admin> portcfgtrunkport 47 # 从交换机（domainid 239）端口 47 配置 Trunk admin> portcfgtrunkport 47 # 验证 Trunk 状态 admin> islshow ISL Status: Port 47: Trunking Active, 2 links, 32Gbps total # 若显示 Trunking Inactive，检查两端 domainid 是否不同、端口是否 Online5.3 长距离（Long Distance）配置：LD 模式 vs LS 模式的选择逻辑
长距离传输需补偿光纤色散和衰减，博科提供两种模式：
| 模式 | 适用距离 | Buffer 分配 | 配置命令 | 维护难度 |
|---|---|---|---|---|
LS(Long Wave Short Distance) | ≤10km | 手动指定 buffer 数量 | portcfglongdistance 47 LS 1 -distance 10 | 高（需计算 buffer） |
LD(Long Wave Distance) | ≤500km | 自动分配 buffer | portcfglongdistance 47 LD 1 -distance 100 | 低（推荐） |
为什么 LD 模式更可靠？LD模式下，交换机根据-distance参数自动计算所需 buffer 数量，并动态调整。而LS模式需手动计算：buffer = distance(km) × 2 + 10，算错 buffer 不足会导致Disc_In激增。某次 85km 链路，LS模式配buffer=20，实测Disc_In每小时增长 5000+；改LD模式后Disc_In归零。
# 100km 链路，用 LD 模式（推荐） admin> portcfglongdistance 47 LD 1 -distance 100 # 验证 buffer 分配 admin> portbuffershow 47 Port 47 Buffer Allocation: Total Buffers: 128 Assigned: 64 # 500km 链路，LD 模式自动分配 256 buffer admin> portcfglongdistance 47 LD 1 -distance 5006. 故障验证与性能测试：从fcping到checkrclink的闭环验证技巧
配置做完不是终点，必须用工具验证业务是否真通、性能是否达标。fcping只能证明链路层可达，checkrclink才能测出真实吞吐。本章给出一套 5 分钟快速验证清单，覆盖从链路连通性、Zone 生效性、到带宽满载的全流程。
6.1fcping的高级用法：不只是 ping 通，还要看质量
fcping默认发 3 个包，对 FC 网络太粗糙。必须加参数测稳定性：
# 测目标 WWN 的连通性（ESXi 主机 ping 存储阵列） admin> fcping 51:40:2E:c0:15:54:F5:14 20:00:00:00:00:00:00:01 # 输出：3 packets transmitted, 3 received, 0% packet loss # 加 --number 发 1000 包，看丢包率（生产环境要求 0 丢包） admin> fcping --number 1000 51:40:2E:c0:15:54:F5:14 20:00:00:00:00:00:00:01 # 输出：1000 packets transmitted, 998 received, 0.2% packet loss → 需查 `porterrshow` # 加 --interval 指定间隔（避免突发流量冲击） admin> fcping --number 100 --interval 0.1 51:40:2E:c0:15:54:F5:14 20:00:00:00:00:00:00:016.2checkrclink带宽测试：端到端吞吐量的黄金标准
checkrclink是博科原生带宽测试工具，比 iPerf 更贴近 FC 业务。必须在两端交换机上分别执行 server 和 client：
# 步骤 1：在存储侧交换机（假设 domainid 1）启动 server admin> checkrclink serverstart 2:4:1 # 2:4:1 表示 domain 2, slot 4, port 1（需根据实际端口调整） # 步骤 2：在主机侧交换机（domainid 239）启动 client admin> checkrclink startclient 3:4:1 fe80::2341:2:ac02:6523 60 # 3:4:1 是 client 端口，fe80::... 是 server 端口 IPv6 link-local 地址，60 是测试时长（秒） # 步骤 3：查看结果（单位 Gbps） admin> checkrclink show Link Test Results: Throughput: 14.2 Gbps Latency: 12.3 us Packet Loss: 0%逻辑说明：
checkrclink测试的是端口间裸带宽，不受上层应用影响。16G FC 理论带宽 16Gbps，实测 ≥14Gbps 为合格；若 <12Gbps，需查portperfshow看Tx Utilization是否饱和，或porterrshow是否有Crc_Err。
6.3 日常巡检自动化：用clihistory和supportshow构建自愈脚本
把高频命令固化为脚本，是减少人为失误的关键。某数据中心将以下命令写入daily_check.sh，每天 6:00 自动执行并邮件告警：
#!/bin/bash # 博科日常巡检脚本（需在交换机上用 expect 或 Python paramiko 调用） # 1. 检查关键端口状态 echo "=== Port Status ===" portshow 47 | grep -E "(Online|No_Light|Fault)" # 2. 检查错误计数器（Enc_Out/Crc_Err > 0 则告警） echo "=== Error Counters ===" porterrshow 47 | grep -E "(Enc_Out|Crc_Err): [1-9]" # 3. 检查光功率（Rx Power < 350 uW 告警） echo "=== Optical Power ===" sfpshow 47 | grep "Rx Power" | awk '{print $3}' | awk -F':' '{print $2}' | sed 's/ //g' | awk '$1 < 350 {print "ALERT: Rx Power too low"}' # 4. 检查 Zone 生效状态 echo "=== Zone Status ===" cfgactvshow | grep "PROD_CFG"从那以后我每次做 Zone 变更，都强制走一遍cfgshow→cfgsave→cfgEnable→fcping→checkrclink五步验证，哪怕只是加一个成员。因为cfgsave成功不代表cfgEnable能成功，cfgEnable成功不代表fcping能通，fcping通不代表带宽达标——只有闭环验证，才能把“配置完成”变成“业务可用”。希望帮到你。
本文还有配套的精品资源，点击获取
