企业官网建设流程全解析

1. 什么是光纤交换机的Zone配置？它到底解决什么问题？

“光纤交换机配置zone”这个标题，乍看是网络存储领域一个非常具体的技术动作，但背后其实藏着一套成熟、严谨、且在企业级数据中心里天天都在用的访问控制逻辑。我干这行十多年，从最早调试第一台Brocade 200E开始，到后来在多个某大型金融后台系统里部署FC SAN架构，几乎每个项目上线前都要花至少半天时间反复核对zone配置——不是因为它难，而是因为一旦配错，后果是静默的、灾难性的：某台数据库服务器突然看不见存储LUN，业务中断；备份任务莫名失败；甚至更隐蔽的——两台本不该通信的主机在底层光纤通道上意外建立了会话，导致数据覆盖或心跳冲突。这些都不是报错弹窗式的故障，而是“看起来一切正常，但关键业务就是跑不起来”。

简单说，Zone（分区）是光纤通道（Fibre Channel, FC）交换机提供的一种逻辑隔离机制，它定义了哪些设备（通常是HBA卡端口WWPN）可以在同一FC Fabric内互相发现并建立连接。注意，它不是IP网络里的VLAN，也不是防火墙规则，而是一种发生在FC协议第二层（FC-2层）的、由交换机固件强制执行的“准入白名单”。你可以把它理解成光纤世界里的“门禁卡系统”：交换机是大楼，每台服务器和存储的HBA端口是员工，而zone就是一张张授权通行的工牌列表——只有同时出现在同一张工牌上的两个员工，才被允许在楼内走廊（即FC Fabric）上碰面、握手、交换文件。

为什么非得用zone？因为FC网络天生是“全连通”的。一台新HBA插进交换机，只要物理链路通，它就会自动向Fabric广播自己的存在（FLOGI注册），然后所有其他已注册设备都能看到它。如果没有zone，整个SAN就像一个没有隔断的大开间办公室，所有人彼此可见，任意两台设备都可能尝试建连。这在测试环境或许无妨，但在生产环境里，数据库服务器A和备份服务器B如果都连着同一套存储阵列，它们的HBA端口若未被zone隔离，就可能出现A正在写入关键表空间时，B却发起LUN扫描或快照挂载，直接触发存储侧的I/O锁竞争，性能断崖式下跌。而zone就是那堵看不见的墙，它不改变物理连接，只过滤逻辑可见性。

这个操作的核心关键词就是“WWPN”——全球唯一端口名称，一个16进制字符串，比如21:00:00:24:ff:5a:12:3b，它是FC设备的身份证，比MAC地址还刚性，出厂即固化，不可修改。所有zone配置，本质上都是在交换机上维护一张“WWPN对”的映射表。你不会去配IP地址，也不会配子网掩码，你配的永远是这一串十六进制字符。这也是新手最容易栽跟头的地方：抄错一位，设备就彻底“隐身”，排查起来像大海捞针。

适合谁来学？如果你是刚接手SAN运维的初级工程师，或者正准备考取FCIA（Fibre Channel Industry Association）认证，又或者你所在的公司正从NAS转向FC SAN架构做核心数据库承载，那么zone配置不是可选项，而是上岗前必须闭眼都能写的肌肉记忆。它不涉及编程，不依赖特定品牌CLI语法（虽然Brocade和Cisco MDS命令略有差异，但逻辑完全一致），它考验的是你对FC寻址模型的理解、对业务拓扑的敬畏，以及一种近乎偏执的配置校验习惯。接下来，我们就一层层拆开它，看看从设计思路到敲下回车键，中间到底隔着多少个必须踩实的台阶。

2. Zone配置的整体设计思路与方案选型逻辑

很多人一上来就想翻手册敲命令，结果配完发现设备看不见，就开始怀疑线缆、光模块、HBA驱动……其实90%的问题，根源不在执行环节，而在最开始的设计阶段。Zone不是零散的命令堆砌，它是一套需要前置规划的访问控制策略。我见过太多团队，把zone当成“临时打补丁”的工具：A部门要上新应用，临时加一条zone；B系统做灾备演练，又临时删一条；半年下来，交换机里存了上百条相互嵌套、命名混乱的zone，最后谁也说不清哪台服务器到底能访问哪些LUN。这种状态，离生产事故只差一次误操作。

所以，真正的起点，永远是一张清晰的业务拓扑图。这张图不能是画在PPT里的漂亮箭头，而必须精确到每一根光纤跳线两端的物理端口（例如：交换机A的port 3/17 → 存储阵列A的controller A port 0）、每一台服务器HBA卡的具体WWPN（不是型号，是贴在HBA金手指旁那个小标签上的16进制码），以及每一个LUN在存储侧的WWN（注意，这是存储卷的WWN，不是HBA的WWPN，两者完全不同）。我习惯用Excel三张表来管理：第一张是“设备清单”，列明所有服务器、存储、交换机的型号、序列号、管理IP、各端口WWPN/WWN；第二张是“业务系统映射”，明确标注“核心交易库”需要访问哪几台存储的哪几个LUN组；第三张才是“Zone规划表”，在这里，我才开始动笔设计zone结构。

这里的关键决策点有三个：

2.1 基于端口（Port-based）还是基于WWPN（WWN-based）？

这是最根本的选型。Port-based zone，顾名思义，是按交换机物理端口号来划分，比如“把交换机1的port 1、2、3划为一个zone”。它的优点是配置简单，交换机重启后依然有效（因为端口物理位置不变）。但致命缺陷是脆弱：一旦你把服务器A的HBA线从port 1拔下来，插到port 5，它就立刻脱离原zone，业务中断。而WWN-based zone，是直接绑定设备的WWPN，无论这台服务器插在交换机哪个口，只要HBA没换，它就永远属于那个zone。这才是生产环境的黄金标准。我经手的所有金融、电信级项目，全部强制使用WWN-based。Brocade叫“Defined Configuration”，Cisco MDS叫“Soft Zoning”，本质一样。别被名字迷惑，认准“WWPN”这三个字母。

2.2 Zone的粒度：大而全，还是小而精？

常见误区是“一个zone包打天下”，比如把所有数据库服务器和所有存储端口全塞进一个zone。这看似省事，实则埋雷。首先，FC Fabric的Name Server（负责设备发现）有条目数限制，一个zone里设备过多，可能导致部分设备无法被正确发现；其次，安全合规审计（如等保2.0）明确要求“最小权限原则”，你不能让备份服务器拥有和数据库服务器同等的LUN访问权。我的实践是：一个zone，只包含一对逻辑关系明确的实体。典型模式是“1台服务器HBA + 1个存储控制器端口 + 它需要访问的1个LUN组”。例如，服务器DB-SVR-01的HBA WWPN21:00:00:24:ff:5a:12:3b，需要访问存储STOR-A的controller A port 0（WWPN50:00:00:00:00:00:00:01）上的LUNs 100-199，那就单独建一个zone，名字就叫ZONE_DB-SVR-01_STOR-A_CTRLA_LUN100-199。清晰、可追溯、易审计。后期扩容时，只需新增对应zone，旧zone纹丝不动。

2.3 Active Zone Set的管理策略：单Zone Set还是多Zone Set？

交换机可以保存多套zone配置（称为Zone Set），但同一时刻只能激活（activate）其中一套。很多团队喜欢搞“开发Zone Set”、“测试Zone Set”、“生产Zone Set”，认为这样切换方便。这是危险的懒惰。实际运行中，你永远只应该有一套Active Zone Set，且它必须100%匹配当前生产环境的业务需求。所谓“多套”，只应存在于你的配置备份文件里，作为回滚预案。原因很简单：Zone Set切换是Fabric级操作，会触发所有设备重新进行FLOGI/FDISC注册，整个Fabric会经历短暂的“失联-重连”过程，对正在运行的I/O是冲击。我亲眼见过一次误操作，把测试Zone Set激活了，结果核心支付系统的数据库连接池瞬间耗尽，APM监控里延迟曲线直接拉成一条直线。所以，我的铁律是：Active Zone Set = 生产唯一真相，任何变更必须走严格变更窗口，提前48小时邮件同步所有相关方，并在变更后立即执行show zone active验证。

这三点想清楚了，后面敲命令才不会心虚。配置不是目的，保障业务连续性才是。每一次回车，都该带着对业务拓扑的敬畏。

3. 核心配置细节与实操关键步骤详解

现在，我们进入真正的“动手环节”。但请记住，所有命令的输入，都必须严格对应你前面画好的那张Zone规划表。没有规划，就没有配置。我以目前市场占有率最高的两款企业级FC交换机为例：Brocade Gen6（如G620）和Cisco MDS 9000系列（如MDS 9706）。它们的CLI风格不同，但底层逻辑完全一致，掌握一个，另一个看手册半小时就能上手。

3.1 Brocade交换机上的Zone配置全流程

Brocade的zone配置遵循“Alias → Zone → Zone Set → Activate”四步法，每一步都不可跳过，且顺序严格。

第一步：创建Device Alias（设备别名）

直接用WWPN配置太反人类，21:00:00:24:ff:5a:12:3b这种字符串，看三遍就忘两遍。Brocade的Alias就是给它起个好记的名字。登录交换机（SSH或串口），进入config模式：

switch:admin> configure switch(config)# aliascreate "DB_SVR_01_HBA0", "21:00:00:24:ff:5a:12:3b" switch(config)# aliascreate "STOR_A_CTRLA_PORT0", "50:00:00:00:00:00:00:01" switch(config)# aliascreate "STOR_A_LUN_GRP_100_199", "60:00:00:00:00:00:00:01" # 注意：这是LUN组的WWN，非端口

提示：Alias名严禁空格和特殊字符，建议全大写+下划线。创建后，务必用aliasshow命令确认是否录入成功，检查WWPN拼写——这是最常见的低级错误。

第二步：创建Zone（分区）

用刚才创建的Alias来定义zone，语义清晰：

switch(config)# zonecreate "ZONE_DB_SVR_01_STOR_A_LUN100_199", "DB_SVR_01_HBA0; STOR_A_CTRLA_PORT0; STOR_A_LUN_GRP_100_199"

注意分号;是分隔符，不是逗号。一个zone里可以有多个成员，但必须是“发起者（Initiator）+ 目标者（Target）+ LUN”的组合。zonecreate命令本身只是把定义存入内存，尚未生效。

第三步：创建并添加到Zone Set（分区集）

Zone Set是zone的容器。先创建，再把zone加进去：

switch(config)# zonesetcreate "ZS_PRODUCTION_ACTIVE", "ZONE_DB_SVR_01_STOR_A_LUN100_199" # 如果已有Zone Set，用以下命令追加： # switch(config)# zonesetadd "ZS_PRODUCTION_ACTIVE", "ZONE_DB_SVR_01_STOR_A_LUN100_199"

第四步：激活（Activate）Zone Set

这是最关键的一步，也是唯一影响业务的一步：

switch(config)# zonesetactivate "ZS_PRODUCTION_ACTIVE" # 系统会提示：This operation will cause a fabric wide reconfiguration. Continue? (y/n) # 此时务必确认：y

注意：激活过程通常需要10-30秒，期间Fabric会短暂“抖动”。务必选择业务低峰期，并提前通知存储和服务器管理员。激活后，立即执行zoneshow active，确认新zone已出现在列表中，且状态为Active。

3.2 Cisco MDS交换机上的Zone配置全流程

Cisco的逻辑更接近“对象化”，核心是vsan（虚拟SAN）、zone、zoneset三层。

第一步：确保VSAN已创建并分配端口

FC交换机默认在VSAN 1，但生产环境强烈建议为不同业务划分独立VSAN。假设我们已在VSAN 100中：

switch# configure terminal switch(config)# vsan database switch(config-vsan-db)# vsan 100 interface fc1/1, fc1/2, fc1/3 # 将服务器和存储端口加入VSAN 100

第二步：创建Zone并添加成员（直接使用WWPN）

Cisco不强制用Alias，但强烈推荐，因为可读性高：

switch(config)# zone name ZONE_DB_SVR_01_STOR_A_LUN100_199 vsan 100 switch(config-zone)# member pwwn 21:00:00:24:ff:5a:12:3b # 服务器HBA switch(config-zone)# member pwwn 50:00:00:00:00:00:00:01 # 存储端口 switch(config-zone)# member pwwn 60:00:00:00:00:00:00:01 # LUN组WWN switch(config-zone)# exit

第三步：创建Zone Set并加入Zone

switch(config)# zoneset name ZS_PRODUCTION_ACTIVE vsan 100 switch(config-zoneset)# member ZONE_DB_SVR_01_STOR_A_LUN100_199 switch(config-zoneset)# exit

第四步：激活Zone Set

switch(config)# zoneset activate name ZS_PRODUCTION_ACTIVE vsan 100 # 系统会提示：WARNING: Zone activation may disrupt traffic. Continue? (y/n) # 确认：y

注意：Cisco的激活命令会立即生效，无需额外copy running-config startup-config，因为zone配置默认就保存在startup-config中。但Brocade需要手动save。

3.3 配置后的必做验证动作（比配置本身更重要）

配完不验证，等于没配。我总结了五步验证法，缺一不可：

1. 交换机侧验证：show zone active（Brocade）或show zoneset active（Cisco），确认zone名称、成员WWPN全部正确显示。
2. 服务器侧验证：在Linux服务器上，执行cat /sys/class/fc_host/host*/port_name查看HBA端口WWPN是否与规划一致；执行ls /sys/class/scsi_host/host*/device/target*/*/scsi_level确认FC链路已建立。
3. 存储侧验证：登录存储管理界面，查看“Host Group”或“Initiator List”，确认该服务器HBA WWPN已成功注册，并被分配到正确的LUN组。
4. 操作系统识别验证：在服务器上执行lsscsi -v或multipath -ll，确认新的LUN设备（如/dev/sdb）已识别，且multipath路径状态为active。
5. 业务级验证：这才是终极检验。用dd if=/dev/zero of=/mnt/testfile bs=1M count=100 oflag=direct写入测试文件，再用md5sum校验，确认I/O路径全程畅通，无超时、无错误。

这五步，我称之为“五步穿心”。少走一步，故障定位时间就要翻倍。尤其第4步，multipath -ll的输出必须是status=active，如果出现failed或ghost，说明zone虽激活，但存储侧LUN映射或HBA驱动仍有问题，此时绝不能上线业务。

4. 实操过程中的核心环节实现与参数解析

Zone配置看似是“填空题”，但每个环节背后都有其严格的参数逻辑和物理约束。忽略这些，轻则配置无效，重则引发Fabric分裂（Fabric Segmentation）——即两台本该互通的交换机，因为zone配置冲突，变成了两个互不感知的孤岛。下面，我们深挖几个最常被忽视的核心环节。

4.1 WWPN的获取与校验：源头数据必须100%准确

所有后续操作的基石，就是那一串16进制的WWPN。它错了，一切皆空。获取方式因平台而异，但必须交叉验证：

• Linux服务器：最可靠的是cat /sys/class/fc_host/host*/port_name。注意，host*是HBA卡编号，一台服务器可能有多个HBA，需逐个检查。lspci | grep -i fibre可先确认HBA型号和数量。
• Windows服务器：打开“设备管理器”→“光纤通道适配器”，右键属性→“详细信息”→“属性”下拉选“硬件ID”，里面会有VEN_...&DEV_...&SUBSYS_...，但WWPN藏在“光纤通道”页签下的“World Wide Port Name”字段。注意，这里显示的是21000024FF5A123B（无冒号），而交换机配置需要带冒号格式21:00:00:24:ff:5a:12:3b，大小写不敏感，但冒号必须有。
• 存储阵列：登录Web管理界面，在“Hosts”或“Initiators”列表里查找。高端存储（如某主流全闪存阵列）会明确标注“WWPN”和“WWNN”（Node Name），务必区分。Zone配的是WWPN（端口名），不是WWNN（节点名）。

提示：我有个血泪教训。某次升级HBA驱动后，/sys/class/fc_host/host*/port_name显示的WWPN末尾变了两位。查证发现，新驱动启用了“Port Name Randomization”功能，导致每次重启WWPN都变。这在zone配置里是灾难！解决方案是：在HBA BIOS或驱动参数里关闭此功能，或改用更稳定的WWNN（但需确认交换机支持WWNN zoning，Brocade默认不支持，需开启高级许可）。

4.2 Zone名称与成员命名规范：这不是形式主义

一个叫zone1的配置，和一个叫ZONE_APP_WEB01_STOR_BKUP_LUN001_010的配置，在技术上完全等价。但前者会让你在三个月后抓狂，后者能让你在凌晨三点的故障现场，30秒内定位问题。我的命名铁律是：

• 前缀统一：所有zone以ZONE_开头，所有zone set以ZS_开头，一眼区分层级。
• 业务标识优先：APP_WEB01比SRV01更能说明角色。
• 设备角色明确：STOR_BKUP表明这是备份存储，而非生产存储。
• 资源范围精确：LUN001_010表明只包含10个LUN，而不是模糊的LUNs。
• 全大写+下划线：杜绝大小写混淆和空格。

同样，Alias命名也要一致。DB_SVR_01_HBA0中的HBA0表示第一块HBA卡，如果服务器有双HBA做冗余，就该有HBA0和HBA1，并在zone里分别配置两条路径。这直接关系到multipath的负载均衡策略。

4.3 Fabric ID与Domain ID：理解交换机在Fabric中的“身份证”

当你有多台FC交换机级联时，fabric id和domain id就成了关键。每台交换机在Fabric中必须有一个唯一的Domain ID（通常1-239），它决定了该交换机在Fabric地址空间中的位置。fabric id则是整个Fabric的全局标识，由Fabric中Domain ID最小的交换机自动担任Principal Switch（主交换机）生成。

为什么重要？因为Zone配置是Fabric级的。如果你在交换机A上配了一个zone，但交换机B的Domain ID和A冲突（比如都是1），那么这两台交换机将无法形成统一Fabric，各自为政，zone自然失效。排查方法很简单：在任意一台交换机上执行fabricshow（Brocade）或show fcdomain（Cisco），查看所有成员的Domain ID是否唯一，Principal Switch是否只有一个。

注意：Domain ID冲突是“静默故障”的高发区。新上架交换机，默认Domain ID常为1，必须在加入Fabric前，用configure命令手动修改为未使用的ID（如101、102），再用fabricprincipal（Brocade）或fcdomain distribute（Cisco）命令将其加入Fabric。这步漏掉，后面所有zone配置都是空中楼阁。

4.4 Zone Merge与Fabric Stability：为什么不能随便加交换机？

当你要把一台新交换机接入现有Fabric时，“Zone Merge”是绕不开的坎。Merge不是简单的物理连接，而是两台交换机的zone数据库、name server条目、fabric参数的深度同步。如果两台交换机的zone配置存在冲突（比如同名zone包含不同成员），Merge会失败，Fabric会分裂。

我的做法是：永远先做“预合并”验证。在新交换机上，用cfgactvshow（Brocade）或show zoneset active（Cisco）导出其当前active zone set，与生产环境的zone set做文本比对。重点检查：

• 是否有同名zone但成员不同？
• 新交换机的zone set是否为空（推荐）？如果是，Merge风险最低。
• 所有WWPN是否在生产环境的设备清单里有记录？未知WWPN是重大安全隐患。

只有100%确认无冲突，才进行物理连接，并在连接后立即执行fabricshow，观察新交换机是否成功加入Fabric，Domain ID是否正确注册。整个过程，我习惯开着tail -f /var/log/messages | grep -i fabric（Linux服务器）和交换机console日志，实时监控Fabric状态变化。

5. 常见问题与排查技巧实录：那些手册里不会写的坑

配置文档写得再完美，也抵不过现实世界的千奇百怪。下面这些，全是我和团队在真实项目里，用无数个深夜和一杯杯咖啡换来的经验。它们不会出现在厂商手册里，但却是你快速定位问题的“黄金线索”。

5.1 典型问题速查表

5.2 独家避坑技巧

技巧一：“回滚快照”比“记住命令”重要十倍

在激活新Zone Set前，务必执行：

• Brocade:configupload将当前完整配置（含所有alias、zone、zoneset）上传到TFTP服务器备份。
• Cisco:copy running-config tftp:同样备份。 这不是多此一举。曾有一次，同事在激活时手滑，把ZS_PRODUCTION_ACTIVE输成了ZS_PRODUCTION_ACTVE（少了个i），系统创建了一个新zoneset，而旧的被覆盖。没有备份，我们花了3小时从服务器和存储日志里，一点点反推出了原来的zone成员。从此，我的每台交换机配置变更前，第一件事就是备份。

技巧二：用zoneobjectrename（Brocade）或zone rename（Cisco）代替删除重建

当需要修改zone成员时，新手常删掉旧zone，再建个新zone。这会导致Fabric短暂中断（因为zone被移除瞬间，设备失去可见性）。Brocade的zoneobjectrename命令可以直接在不中断Fabric的情况下，修改zone的成员列表。Cisco也有类似zone modify的命令（需在特定OS版本）。学会用它，能让你的变更窗口缩短一半。

技巧三：errdump日志是沉默的证人

当一切看起来都对，但业务就是不通时，别急着重配。在Brocade交换机上，执行errdump，它会输出最近24小时所有硬件和协议错误。我曾靠它发现一根光纤跳线的RX光功率低于阈值-20dBm，导致FC帧大量CRC错误，而portshow显示端口状态却是Online。这种底层物理问题，zone配置再完美也无济于事。

技巧四：永远相信show flogi database

这是FC世界的“ARP表”。在交换机上执行此命令，你会看到Fabric中所有已注册设备的WWPN、所属VSAN、连接端口。如果某台服务器的WWPN没出现在这里，说明它根本没成功注册到Fabric，问题一定出在物理链路、HBA驱动或交换机端口enable状态上，和zone配置毫无关系。这是排查的第一站。

最后分享一个小技巧：我随身U盘里，永远存着一个Excel模板，里面预置了所有常用命令的语法、参数说明、以及我标注的“高频错误点”。比如zonecreate命令后，我用红色字体写着：“注意：成员间用分号;，不是逗号,，不是空格，不是冒号:”。这种笨办法，救了我无数次。

6. 后续演进与扩展思考：Zone不是终点，而是起点

把zone配通，只是SAN运维万里长征的第一步。随着业务发展，你会发现，单纯的静态zone配置会越来越力不从心。这时，就需要向更智能、更自动化的方向演进。这不是为了炫技，而是业务规模倒逼的必然选择。

第一层演进：自动化配置与版本管理

当你的Fabric从2台交换机、20台服务器，扩张到10台交换机、200台服务器时，手工敲命令、人工核对Excel表，效率和准确率都会崩塌。这时候，Python脚本就成了救命稻草。我用pexpect库封装了Brocade和Cisco的CLI交互，输入一个CSV格式的Zone规划表（列：ZoneName, InitiatorWWPN, TargetWWPN, VSAN），脚本就能自动生成完整的配置命令流，并调用ssh执行。更重要的是，我把所有历史配置都纳入Git版本管理。每次变更，都是一次git commit，附上变更原因、影响范围、回滚步骤。这样，当某次变更引发故障时，git diff就能瞬间告诉你，到底改了哪一行。

第二层演进：与CMDB和Orchestration平台集成

真正的高手，不会让zone配置游离于ITIL流程之外。我们把交换机、服务器、存储的资产信息，全部同步到公司的CMDB（配置管理数据库）中。当CMDB里一台新服务器的“FC_HBA_WWPN”字段被填写，一个自动化工作流就会被触发：自动在交换机上创建Alias、创建Zone、加入Production Zone Set、发送邮件通知相关人。整个过程，无需人工干预，变更记录自动写入CMDB的变更日志。这不仅提升了效率，更让每一次配置变更，都成为可审计、可追溯的合规事件。

第三层演进：从Zone到FC-NVMe与SDN Fabric

FC协议本身也在进化。最新的FC-NVMe（NVMe over Fibre Channel）标准，让SSD的极致性能得以在FC网络上释放。而它对zone的要求更高——不仅要隔离WWPN，还要支持NVMe的Namespace级别的精细控制。同时，软件定义网络（SDN）理念也开始渗透FC领域。像Brocade的Fabric Vision，已经能基于实时流量分析，动态建议最优的zone划分策略，甚至预测潜在的I/O瓶颈。这意味着，未来的zone管理员，不仅要懂WWPN，还要懂NVMe协议栈，要能看懂流量热力图，要会用Python调用SDN控制器API。

所以，当你今天第一次在交换机上敲下zonecreate时，请记住：你启动的不是一个简单的配置任务，而是一扇通往企业级存储网络核心世界的大门。门后，是精密的协议、是严苛的SLA、是业务连续性的千钧重担。而这份对细节的执着、对逻辑的敬畏、对每一次回车的审慎，正是资深从业者与普通操作员之间，那道看不见却无比真实的分水岭。我在实际操作中发现，真正让人成长的，从来不是配置成功的那一刻，而是为了解决一个NO_FDISC状态，在凌晨两点反复比对fabricshow输出时，那种近乎偏执的耐心。