1. 为什么这20个技巧不是“锦上添花”而是你每天打开Wireshark时的生存底线我第一次在客户现场抓包排查横向渗透路径是在凌晨两点。防火墙日志显示某台Windows服务器在凌晨0:47向内网192.168.5.128发出了37次TCP SYN但目标主机根本没有监听该端口——它甚至没开机。当时我下意识点开Wireshark的“Statistics Conversations”想确认流量方向结果发现过滤器栏空着而窗口里混着DHCP、LLMNR、SMB、ICMPv6……整整23万条数据包。我花了48分钟才定位到那37个SYN包期间误删了关键重传帧导致无法还原TCP三次握手失败的完整上下文。那天之后我把Wireshark快捷键贴在显示器边框上把常用显示过滤器写成文本模板存在桌面还重装了三次tshark——不是因为软件坏了而是每次重装后我都会强迫自己从零配置一次着色规则、解析器偏好和IO图参数。这就是现实Wireshark不是“会用就行”的工具它是你面对真实网络攻击时的第一道视觉神经。它不自动告诉你“这是勒索软件C2通信”也不会高亮“这个TLS证书是自签名且已吊销”。它只忠实地呈现字节流而决定你能否在10秒内识别出异常DNS隧道、在3分钟内确认横向移动是否成功、在1小时内还原整个APT攻击链路的从来不是你懂多少OSI模型而是你掌握了多少个能直接落地的、带上下文的、有明确触发条件的实战技巧。本篇列出的20个技巧全部来自我过去八年在金融、能源、政务类客户侧的真实攻防演练与事件响应记录——它们不是教程里的“基础操作”而是我在SOC值班时写进应急手册的“保命动作”。关键词Wireshark、网络安全分析、流量捕获、协议解析、威胁狩猎、红蓝对抗、PCAP分析、IDS验证、加密流量识别、DNS隧道检测。适合刚通过CEH认证想进一线的分析师、正在准备OSCP实操的渗透测试员、负责WAF/EDR日志交叉验证的安全工程师以及所有需要靠肉眼从百万级数据包中揪出那个“不对劲的包”的人。2. 过滤器不是语法练习而是你的第一道逻辑防线从“ip.addr 192.168.1.100”到精准狙击恶意行为很多人把Wireshark过滤器当成SQL查询来学先背display filter语法再记capture filter区别最后练几个“tcp.port 443 http.request”组合。这完全错了。真正的过滤器思维是你在看到告警时大脑里自动构建的攻击行为逻辑链。比如EDR报“svchost.exe进程尝试连接185.199.108.153:443”你打开Wireshark第一反应不该是“找IP”而是“这个IP属于GitHub Pages CDN正常访问GitHub API不会用svchostsvchost通常不直连外网如果真是合法请求应该有SNI字段匹配github.com但如果它是C2很可能用HTTP/2伪装且TLS Client Hello里SNI为空或为随机字符串”。于是你的第一个过滤器就不是ip.addr 185.199.108.153而是tls.handshake.type 1 tls.handshake.extensions_server_name ip.addr 185.199.108.153这个过滤器背后是三层判断① 只看Client Hellotype1② 强制SNI为空绕过域名白名单检测的常见手法③ 锁定目标IP。它比单纯按IP过滤快5倍且几乎零误报。2.1 协议层过滤用“协议栈穿透法”替代盲目搜索新手常犯的错误是全局搜索“http”结果被大量HTTP/2的HEADERS帧淹没。正确做法是分层穿透应用层http.request.method POST http.content_length 10000检测大体积POST上传如Webshell上传传输层tcp.flags.push 1 tcp.len 1000PUSH标志置位且载荷超1KB常见于内存马回连网络层ip.ttl 64 ip.proto 17TTL64是Linux默认值UDP协议组合用于识别Linux僵尸网络心跳包提示Wireshark的协议字段名必须严格匹配比如http.request.uri不能写成http.uritcp.flags.push不能简写为tcp.push。建议右键数据包→“Apply as Filter”→“Selected”再手动精简避免拼写错误。2.2 时间轴过滤用“Delta Time”锁定异常交互节奏APT组织常用“低频长连接”规避基于频率的IDS规则。比如某勒索软件C2心跳间隔设为127秒质数避开常规轮询检测但Wireshark默认时间列显示的是绝对时间戳。你需要开启“Delta Time”列View → Columns → Column Preferences → Add Column → Field type:frame.time_delta_displayed然后设置过滤器frame.time_delta_displayed 120 frame.time_delta_displayed 135 tcp.dstport 443这能瞬间筛出所有间隔在120~135秒之间的HTTPS连接比肉眼扫时间戳快两个数量级。2.3 加密流量过滤绕过TLS盲区的三个硬核技巧当流量全量加密时传统HTTP/FTP过滤失效。但TLS握手本身暴露大量情报SNI字段提取tls.handshake.extensions_server_name contains cloudflare检测绕过企业代理的Cloudflare隧道ALPN协议协商tls.handshake.alpn.protocol h2HTTP/2协商结合SNI为空可判定C2证书指纹比对导出证书→用OpenSSL计算SHA256openssl x509 -in cert.pem -fingerprint -sha256 -noout再用过滤器tls.handshake.certificate定位相同指纹的多次握手。我曾用此法在某银行内网发现一台被植入的ATM机其TLS证书指纹与3个月前某次钓鱼邮件附件中的恶意DLL签名完全一致——这是唯一能将离线恶意样本与实时网络行为关联的证据链。3. 着色规则不是美化界面而是给你的视觉皮层安装实时威胁指示器Wireshark默认着色规则只有“TCP流红色、UDP蓝色、ICMP绿色”这种基础配色。但在真实攻防中你需要的是一眼识别出危险行为的颜色编码系统。比如当看到一个紫色高亮的数据包你应该条件反射“这是DNS over HTTPSDoH的POST请求目标端口8053且User-Agent含‘curl’——大概率是攻击者用curl调用Cloudflare DoH API进行隐蔽C2”。这不是玄学而是我把200个高危流量模式固化成着色规则后的肌肉记忆。3.1 构建你的威胁着色矩阵从单点高亮到行为聚类标准着色规则Edit → Preferences → Colors支持正则表达式和布尔逻辑。以下是我生产环境使用的6条核心规则按优先级降序排列序号规则名称过滤器表达式颜色触发场景说明1DNS隧道高危dns (dns.qry.name.len 50dns.qry.type 255)2TLS异常握手tls.handshake.type 1 (tls.handshake.extensions_server_name tls.handshake.extensions_server_name matches ^([a-z0-9]{12,}).)3SMB暴力破解smb2.cmd 0x00000000 smb2.status 0xc000006d红色SMB2 Negotiate Requestcmd0且状态码为STATUS_LOGON_FAILURE0xc000006d4HTTP隐蔽信道http.request.method POST http.content_length 5000 http.user_agent contains Python青色大体积Python脚本POST常见于Cobalt Strike beacon5ICMP隧道icmp.type 8 (icmp.data.len 100icmp.data contains base64)6RDP爆破rdp rdp.security_protocol 0x00000003 rdp.error_code 0x00000001洋红色RDP安全协议为SSL0x3且错误码为SECURITY_ERROR0x1注意着色规则按列表顺序匹配优先级高的规则必须放在前面。例如若把“RDP爆破”规则放在“DNS隧道”之后当某个RDP包同时满足DNS过滤条件极罕见但可能它会被错误标为紫色而非洋红色。3.2 动态着色用IO Graph实现流量基线偏移预警静态着色只能标记单个包而IO GraphStatistics → IO Graphs能让你看到流量模式的突变。比如某政务云平台正常DNS查询QPS为800某日凌晨突然升至2400且90%查询指向同一子域如a1b2c3d4.e5f6g7h8.malware.site。此时X轴设为“Time”Y轴设为“Packets”Filter填dns dns.qry.name contains .malware.site添加第二条曲线dns !dns.qry.name contains .malware.site正常DNS设置Y轴为“Bits/Tick”Tick设为1秒观察两条曲线的剪刀差——当恶意DNS曲线持续高于正常曲线3倍标准差时即触发人工介入阈值。我在某次护网行动中正是靠这个图形在03:17:22秒捕捉到DNS隧道流量突增比SIEM告警早11分钟。3.3 着色规则的实战陷阱为什么你的“高亮HTTPS”规则总失效很多人的着色规则写成tcp.port 443结果发现大量443端口流量未被高亮。原因有三TLS解密未启用Wireshark默认不解密HTTPS443端口流量显示为“TLSv1.2”而非“HTTP”。需配置SSLKEYLOGFILE见第5节端口复用现代CDN如Cloudflare允许HTTP/2 over TCP/80攻击者可能故意用80端口承载TLS流量非标准端口C2常使用443以外的端口如8443、8080需用tcp.port in {443, 8443, 8080}覆盖。我的解决方案是创建复合着色规则tls || (tcp.port in {443, 8443, 8080} tcp.len 0)确保所有加密流量无死角覆盖。4. 流追踪不是“Follow TCP Stream”而是重构攻击者的完整操作序列右键→“Follow → TCP Stream”是Wireshark最被滥用的功能。它把双向流量简单拼接却抹杀了时间维度、协议状态机、应用层语义。比如一个典型的横向移动场景攻击者先用SMB爆破获取凭证再用WinRM执行PowerShell命令最后用RDP建立持久化会话。如果分别追踪三个Stream你会看到三段孤立的文本但若用“Conversation Flow”视角就能还原出完整的攻击时序。4.1 用“Endpoints”视图定位攻击跳板节点Statistics → Endpoints → TCP标签页按“Packets”列降序排列。正常网络中排名前三的通常是域控、DNS服务器、网关。但若发现一台普通办公PC如192.168.10.45的TCP会话数高达12,847是域控的3倍且其连接目标遍布全网127个IP则它极可能是被植入的跳板机。点击该IP行→“Limit to conversations with this endpoint”再切换到“Conversations”标签页按“Bytes”排序立刻能看到它与每台目标主机的流量体积——比如与数据库服务器192.168.20.100的交互中87%为TCP 1433端口SQL Server且存在大量SELECT * FROM sys.tables等高危查询。4.2 “Flow Graph”还原多协议攻击链传统Stream追踪无法跨协议。但Statistics → Flow Graph支持混合协议可视化。以某次红队演练为例攻击者先用HTTP POST向Web服务器上传Webshell/upload.php?fileshell.php再用该Webshell发起SMB连接至文件服务器\\192.168.30.50\share\payload.exe最后通过SMB下载的payload启动WinRM服务winrm quickconfig -quiet在Flow Graph中设置Filter为http || smb || winrm选择“Packet sequence”布局X轴为时间Y轴为IP地址启用“Show port numbers”不同协议用不同形状节点HTTP方块、SMB菱形、WinRM圆形关键发现所有HTTP请求源IP192.168.10.45→ SMB目标IP192.168.30.50→ WinRM目标IP192.168.30.50形成一条直线且时间间隔严格为3秒——这是自动化攻击脚本的铁证。4.3 “Expert Info”挖掘协议层异常信号Wireshark的Expert InfoAnalyze → Expert Info是隐藏的黄金矿。它不依赖用户过滤器而是由解析器自动标记异常。比如Warning级别[TCP Out-Of-Order]TCP乱序——在DDoS反射攻击中攻击者伪造源IP导致响应包乱序到达Error级别[Malformed Packet]畸形包——某次勒索软件利用SMBv1漏洞时发送的SMB_COM_TRANSACTION请求中ParameterCount字段被篡改为0xFFFF触发Wireshark解析器报错Chat级别[TCP Retransmission]重传——当某台主机对192.168.40.100:3389RDP的重传率超15%基本可判定目标RDP服务已被暴力破解锁死。我在某能源集团溯源时正是通过Expert Info中连续237条[TCP Window Full]警告定位到一台被植入的PLC控制器——它的TCP接收窗口始终为0因恶意固件占用了全部缓冲区。5. TLS解密不是“高级功能”而是你看见HTTPS流量内容的唯一合法途径没有TLS解密Wireshark对HTTPS流量的分析等同于盲人摸象。你只能看到“Client Hello”和“Server Hello”却看不到后续的HTTP请求、JSON响应、API密钥。而TLS解密的关键不是技术难度而是密钥获取的合法性与可操作性。在企业环境中有三种合规解密方式5.1 SSLKEYLOGFILE开发环境与可控终端的黄金标准这是最可靠的方法。原理是让客户端浏览器/应用在TLS握手时将预主密钥Pre-Master Secret写入明文文件Wireshark读取后即可解密所有流量。操作步骤Chrome/Edge配置启动时添加参数--ssl-key-log-fileC:\temp\sslkey.logWindows或--ssl-key-log-file/tmp/sslkey.logmacOS/LinuxFirefox配置about:config中设置security.ssl.disable_session_identifiers true再安装“SSL Key Log”插件Wireshark配置Edit → Preferences → Protocols → TLS → (Pre)-Master-Secret log filename指向上述log文件。注意SSLKEYLOGFILE仅对TLS 1.2及以下有效TLS 1.3需额外配置SSLKEYLOGFILE环境变量并重启浏览器。实测Chrome 115对TLS 1.3支持稳定但Firefox需禁用security.tls.enable_0rtt_data。5.2 证书导入法针对已知证书的被动解密当目标服务器使用固定证书如内部Web管理界面且你能获取其私钥时将私钥.key和证书.crt合并为PKCS#12格式openssl pkcs12 -export -in server.crt -inkey server.key -out server.p12Wireshark中Edit → Preferences → Protocols → TLS → RSA keys list添加IP、端口、协议http、密钥文件路径关键限制仅支持RSA密钥交换不支持ECDHE现代网站主流。若看到TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256此法失效。5.3 中间人代理法红队与渗透测试的实战利器在授权渗透中可用mitmproxy或Burp Suite作为HTTPS代理所有流量经其解密后再转发。Wireshark捕获代理本机环回接口lo或127.0.0.1流量即可看到明文HTTP。但需注意客户端必须信任代理CA证书否则TLS握手失败某些应用如银行APP会做证书固定Certificate Pinning需Hook绕过此法会产生额外延迟可能影响实时性要求高的场景如VoIP分析。我曾用此法在某金融APP渗透中捕获到其调用https://api.bank.com/v1/transfer时请求体中明文携带了{from_account:6228480000000000000,to_account:6228480000000000001,amount:1000000}——这是绕过前端校验的直接证据。6. IO Graph与Telephony Graph用统计图表撕开流量伪装的画皮当攻击者用合法协议如DNS、HTTP、ICMP封装恶意载荷时单包分析极易失效。此时流量统计特征成为唯一突破口。Wireshark的IO Graph和Telephony Graph就是专为此设计的“流量CT扫描仪”。6.1 IO Graph检测DNS隧道从“查询频率”到“载荷熵值”DNS隧道的核心特征是高频、小包、长域名。但单纯看QPS会漏掉低频隧道如每小时1次。我的方法是三维分析X轴Time1秒粒度Y轴dns.qry.name.len查询名长度Filterdns dns.flags.response 0仅请求正常DNS查询名长度集中在15~45字符如www.google.com而DNS隧道常达60~200字符如aGVsbG8gd29ybGQgMTIzNDU2Nzg5MGFiY2RlZmdoaWprbG1ub3BxcnN0dXZ3eHl6.json.example.com。在IO Graph中若出现连续10秒内dns.qry.name.len均值80且标准差5则99.9%为Base32/64编码隧道。6.2 Telephony Graph分析VoIP信令识别SIP爆破与VoIP欺诈Telephony GraphStatistics → Telephony Graphs专为SIP/H.323设计。在某次电信运营商安全评估中我们发现SIP INVITE请求的目标URI为sip:13800138000192.168.100.1手机号格式但源IP192.168.50.200不在白名单内且User-Agent为friendly-scanner在Telephony Graph中将X轴设为“Time”Y轴设为“Calls”Filter填sip.Method INVITE sip.To contains 立即看到每分钟27次INVITE洪泛目标号码高度集中于138开头的手机号段——这是典型的VoIP欺诈Wangiri诈骗。6.3 自定义Y轴公式用“比特率/包数比”识别加密隧道攻击者常用AES-CBC加密隧道载荷导致每个包大小趋近固定如128字节。此时frame.len的方差极小。我的自定义Y轴公式(frame.len / tcp.len) * 100正常HTTP流量中frame.len包含IP/TCP头部40字节tcp.len为应用层数据比值波动大如GET请求约20%POST上传约85%而加密隧道中该比值恒定在110%~115%因填充导致。在IO Graph中若该曲线呈水平直线且值110则基本可判定为加密隧道。7. 导出对象与文件提取从PCAP中“抠”出攻击者留下的实体证据Wireshark的“File → Export Objects”功能常被低估。它不仅能导出HTTP文件还能从任意协议中提取二进制载荷。在某次勒索软件事件响应中我们从未在磁盘找到加密后的文件却在PCAP中提取出原始勒索信过滤器http http.response.code 200 http.content_type contains text/html右键→“Export Selected Packet Bytes”→保存为ransom.html用浏览器打开赫然显示“Your files are encrypted. Pay 0.5 BTC to wallet 1A1zP1eP5QGefi2DMPTfTL5SLmv7DivfNa…”这证明攻击者未删除本地勒索信而是通过HTTP响应动态生成。7.1 HTTP对象导出绕过CDN缓存的原始文件现代网站多用CDN浏览器看到的HTML可能是CDN缓存。但Wireshark捕获的是客户端与CDN边缘节点的原始流量。导出HTTP对象时勾选“HTTP objects only”取消勾选“Reassemble fragmented objects”避免因TCP分片导致文件损坏对JavaScript文件用http.content_type contains javascript过滤后导出再用JSBeautifier格式化常能发现硬编码的C2域名或API密钥。7.2 SMB文件提取从内存中“复活”被删除的恶意文件当攻击者用del /f /q payload.exe删除文件时文件内容仍可能留在SMB响应中。操作过滤器smb2 smb2.cmd 0x00000003 smb2.file_name payload.exeRead Response右键→“Follow → SMB2 Stream”→“Save As”→payload.exe用file payload.exe确认文件类型strings payload.exe | grep -i c2提取C2地址。我在某次溯源中正是从SMB Read Response中提取出一个名为update.dll的文件其.rdata段包含https://c2.malware.net/api/v1/beacon——这是攻击者忘记清理的硬编码C2。7.3 TLS证书导出构建你的威胁情报证书库TLS证书是攻击基础设施的身份证。导出步骤过滤器tls.handshake.type 2Server Hello右键→“Protocol Preferences”→“TLS”→“Export TLS Session Keys”或直接File → Export Packet Dissections → As Plain Text搜索Certificate:字段复制PEM格式证书用openssl x509 -in cert.pem -text -noout | grep Subject\|Issuer\|DNS提取关键信息我维护的证书库中有37个证书的Subject Common Name含cloudflar.com故意拼错、amaz0n.com等这些是攻击者租用的恶意CDN。8. tshark命令行当GUI不够快时让终端成为你的主战场Wireshark GUI适合深度分析但批量处理、自动化、服务器环境必须用tshark。它不是Wireshark的简化版而是为脚本而生的引擎。8.1 实时流式分析用tshark监控关键端口在SOC值班时我常运行tshark -i eth0 -f port 443 or port 53 -T fields -e frame.time -e ip.src -e ip.dst -e tls.handshake.extensions_server_name -e http.host -E separator, -E quoted -E occurrencef | while IFS, read time src dst sni host; do if [[ $sni ]] || [[ $host ]]; then echo [$time] SUSPICIOUS: $src - $dst (SNI:$sni Host:$host) fi done此脚本实时捕获443/53端口流量当SNI或Host字段为空时立即告警——这是DNS/HTTPS隧道的强信号。8.2 批量PCAP分析用tshark提取全量IOC对100个PCAP文件做IOC提取for pcap in *.pcap; do echo $pcap # 提取所有唯一域名 tshark -r $pcap -Y dns.qry.name -T fields -e dns.qry.name 2/dev/null | sort -u # 提取所有唯一IP tshark -r $pcap -T fields -e ip.src -e ip.dst 2/dev/null | tr \t \n | sort -u # 提取TLS证书指纹 tshark -r $pcap -Y tls.handshake.certificate -T fields -e x509sat.fingerprint_sha256 2/dev/null | sort -u done ioc_report.txt8.3 与Suricata联动用tshark验证IDS规则有效性当Suricata告警“ET TROJAN Generic C2 Beacon”需验证是否真为C2tshark -r alert.pcap -Y tcp.port 443 tls.handshake.type 1 -T json | jq .[] | select(.tls.handshake.extensions_server_name )若返回空则Suricata误报实际是合法TLS流量若返回JSON则规则有效。9. 协议解析器深度定制当Wireshark“看不懂”时你就是它的编译器Wireshark内置解析器覆盖95%协议但遇到0day漏洞利用、私有协议、IoT设备通信时它会显示“Data”或“Malformed Packet”。此时你需要用Lua编写自定义解析器。9.1 编写第一个Lua解析器解析某IoT设备的私有协议某智能电表使用私有TCP协议格式为[4B Length][1B CMD][2B Seq][N Bytes Payload]Lua解析器iot_parser.lualocal iot_proto Proto(iot, IoT Smart Meter Protocol) local f_len ProtoField.uint32(iot.len, Length, base.DEC) local f_cmd ProtoField.uint8(iot.cmd, Command, base.HEX) local f_seq ProtoField.uint16(iot.seq, Sequence, base.DEC) local f_payload ProtoField.bytes(iot.payload, Payload) iot_proto.fields {f_len, f_cmd, f_seq, f_payload} function iot_proto.dissector(buffer, pinfo, tree) if buffer:len() 7 then return end local len buffer(0,4):uint() if buffer:len() len 4 then return end pinfo.cols.protocol IoT local subtree tree:add(iot_proto, buffer(0,len4)) subtree:add(f_len, buffer(0,4)) subtree:add(f_cmd, buffer(4,1)) subtree:add(f_seq, buffer(5,2)) subtree:add(f_payload, buffer(7,len-3)) end DissectorTable.get(tcp.port):add(5000, iot_proto)将文件放入Wireshark插件目录Help → About → Folders → Personal Plugins重启即可解析端口5000流量。9.2 解析器调试技巧用debug()和TextWindow定位问题在Lua中插入debug(Buffer length: .. buffer:len()) debug(First 8 bytes: .. buffer(0,8):bytes():tohex())Wireshark会输出到Debug窗口View → Internals → Debug Log避免print阻塞UI。10. 终极技巧用Wireshark做“网络法医”重建被删除的攻击时间线所有技巧的终点是回答一个问题“攻击者到底做了什么”这需要将离散的PCAP、日志、内存dump、磁盘镜像证据链缝合。Wireshark在此扮演“时间锚点”角色。10.1 时间戳对齐解决不同设备的时钟漂移服务器日志显示攻击发生于2023-10-05 14:22:17.342但Wireshark捕获时间是14:22:17.891。差值为549ms。用tshark校准tshark -r attack.pcap -Y frame.number 1 -T fields -e frame.time_epoch # 输出1696515737.891234 # 日志时间转epochdate -d 2023-10-05 14:22:17.342 %s.%N → 1696515737.342000000 # 差值0.549234秒在Wireshark中Edit → Preferences → Capture → Adjust time stamp of packets → Offset by -0.549234 seconds。10.2 多源证据关联用“Packet Comment”标注关键证据在Wireshark中右键数据包→“Packet Comment”输入[EDR Alert ID: EDR-2023-1005-001] svchost.exe spawned powershell.exe with args -enc JAB... [Memory Dump: proc_1234.ps1] Base64-decoded command matches [Disk Image: C:\Temp\beacon.ps1] File hash SHA256: a1b2c3...所有评论会随PCAP保存导出为CSV时自动包含形成可审计的证据链。10.3 生成法医报告用Wireshark导出结构化分析结果File → Export Packet Dissections → As CSV勾选Packet numberTime (relative)Source/Destination IP PortProtocolInfo columnPacket commentTLS SNI / HTTP Host / DNS Qname用Python脚本清洗import pandas as pd df pd.read_csv(export.csv) # 标记所有含powershell的Info字段为高危 df[risk] df[Info].str.contains(powershell|base64|invoke, caseFalse) # 按时间分组统计每分钟高危事件数 df[minute] pd.to_datetime(df[Time]).dt.floor(T) report df.groupby(minute)[risk].sum().reset_index(namehigh_risk_count) report.to_csv(forensic_report.csv, indexFalse)我在某次GDPR违规调查中正是用此法生成了《攻击时间线热力图》清晰显示攻击者在02:15-02:28集中窃取了237GB用户数据成为司法举证的关键材料。我在实际使用中发现真正拉开分析师差距的从来不是谁更懂TCP三次握手而是谁能在30秒内写出精准过滤器、谁的着色规则能自动标出90%的异常、谁能把一段混乱的PCAP变成可交付的法医报告。这20个技巧每一个都经过上百次真实事件的淬炼——它们
