1. 项目概述与准备工作
1.1 为什么用 Wireshark 看网络流量
网络问题是我日常排障里最头疼的一类。你盯着服务日志，看到的是应用层吐出来的状态；但真正在网络上发生了什么，往往被层层缓冲和重试机制遮住了。举一个我遇到过的场景：某个接口偶尔慢 3 秒，应用日志没有异常，数据库查询也不慢，最后抓包才发现，原来是前端请求在 TCP 连接建立阶段就发生了 SYN 重传，服务端虽然回了包，但中间某个转发设备把包丢了一段时间。这类问题如果不看包，光靠猜，可能要猜几天。
Wireshark 的价值就在这儿：它把网卡上真正经过的数据帧原封不动地收下来，按协议栈逐层解析，让你看到最真实的字节级现场。不管是 HTTP 状态码对不对、DNS 解析花了多久、TCP 握手是否反复、有没有重传和乱序，都能在抓包文件里找到证据。
这次实战用的环境是 Ubuntu 22.04。选这个系统，是因为它是当前最普及的服务器和开发机发行版之一，绝大多数线上服务器跑的就是它，抓包技巧可以直接迁移到工作场景里。这篇文章会从安装环境讲起，再到第一个抓包实验，然后是过滤器、协议分析、命令行自动化，最后是常见问题速查。看完你就能自己完成一次完整的网络排查闭环。
1.2 Ubuntu 22.04 安装与授权细节
第一步肯定是装包。Ubuntu 22.04 的默认软件源里就带 Wireshark，不需要去官网下安装包：
sudo apt update sudo apt install -y wireshark tshark注意我一次装了两个包：wireshark 提供图形界面，tshark 是命令行版本。有些教程只装 wireshark，等你想要在服务器上跑抓包脚本时才发现没有 tshark，又得回头补装。两个包一起装，图形界面和命令行都齐了，后面的工作都会顺手很多。
安装过程中系统会弹出交互窗口，问你要不要允许非 root 用户抓包。这里我的建议是按使用环境区分：
- 如果是开发机，选“是”，然后把你的账号加进 wireshark 组，日常抓包不用反复 sudo。
- 如果是线上服务器，选“否”，抓包时显式用 sudo，避免普通用户权限过大。
如果安装时选错了，不用卸了重装，跑一条命令重新配置就行：
sudo dpkg-reconfigure wireshark-common重新配置后再把用户加入抓包组，并重新登录一次。很多人在第一步就翻车，就是加了组之后没有注销重登，导致组权限不生效，打开界面后依然报没有抓包权限。判断权限是否生效，可以执行：
id看输出里是否包含 wireshark 组。如果没有，要么没加成功，要么没重新登录。
2. 第一次抓包：界面认知与抓包设置
2.1 动手前的三个决策
打开 Wireshark，你会看到一张接口列表，里面有 eth0、ens33、wlan0、lo、any 等等。不要凭感觉选接口直接开始抓，先回答三个问题。
第一，抓哪个接口。访问本机的服务，一定要抓 lo，回环接口上的流量只在 lo 上可见；请求外部网络，抓出口网卡，常见名字是 eth0 或 ens33；无线网络抓 wlan0。如果实在不知道是哪个，可以看接口列表里的实时流量预览，数值在跳的那个大概率就是主网卡。
第二，要不要开混杂模式。GUI 里每个接口的左侧都有个复选框，默认是开启的。混杂模式的意思是网卡把物理链路上收到的所有帧都收进来，不限目标 MAC。在交换机镜像口或者虚拟机桥接这种共享链路环境里，它可以让你看到其他主机的流量。但在普通交换机下，交换机会按 MAC 地址只把帧发给目标端口，开了混杂模式也看不到别人家的流量，所以这个开关不是用来偷看的，而是用于合法排查场景：比如你在交换机上做了端口镜像，需要把镜像流量全部收下来分析。
第三，要不要先写捕获过滤器。如果流量特别大，而且你明确只要某个端口的包，可以在抓包前写一个捕获过滤器，比如port 80。它的好处是从源头丢掉无用包，不占用磁盘和 CPU；坏处是一旦丢弃就再也找不回来了。所以我一般只在长期抓包、存储有限时才用捕获过滤器，短时间排障一律抓全量，后面用显示过滤器慢慢筛。
2.2 一次完整的 Nginx 访问抓包
接下来走一遍标准流程，目标：抓取一次本机 Nginx 的访问流量。
第一步，选择接口。假设 Nginx 监听在 80 端口，客户端是另一台机器，请求会从 eth0 进来，所以双击 eth0。
第二步，配置轮转文件。点击抓包选项图标，在“多个文件”区域勾选启用，把单个文件大小设为 10MB，数量设为 10。这样抓包文件最多占用 100MB 磁盘，流量爆发时不会写爆。生产机器上因为抓包把磁盘写满的，我不是没见过，轮转保存是低成本高收益的习惯。
第三步，开始抓包。在客户端上执行 curl，或者在浏览器访问 Nginx 页面：
curl -v http://172.16.10.20/index.html第四步，停止抓包。回到 Wireshark 点红色方块按钮，把文件保存成 /tmp/nginx-test.pcapng。
第五步，看协议分级统计。菜单“统计 -> 协议分级统计”，会按协议树显示出包数和占比。HTTP 访问一次，理想情况应该看到 TCP 和 HTTP 的占比合理，DNS 不应该出现太多。如果出现大量 DNS，说明客户端在反复解析域名，这本身就是排查线索。
第六步，分析关键包。在显示过滤器输入http.request，就能只看 HTTP 请求包，右键任意请求选择“追踪流 -> TCP 流”，可以看到完整的请求和响应内容。第一次跑通这个过程，你基本就掌握了 Wireshark 的主要使用链路：抓包、保存、统计、过滤、追踪。
2.3 设置时间列与显示习惯
抓包排延迟问题时，默认的时间列不一定够用。Wireshark 的时间列默认是抓包开始后的相对时间，单位是秒。如果你想知道每个包和上一个包相隔多久，可以在列头部右键，把“时间对之前显示分组包头的增量”加进来。增量时间列对定位哪一段链路耗时大特别有效：客户端发出 SYN 到收到 SYN+ACK，增量就能读出握手 RTT；发出 DNS 查询到收到响应，增量就是 DNS 总耗时。
还要建议关闭自动滚屏。抓包时界面默认会跟着最新包滚动，流量一大，GUI 渲染反而消耗 CPU，甚至影响抓包效率。在抓包界面右下角有个自动滚屏按钮，点一下关掉它。抓包过程中不要盯着屏幕看，等停止之后再在静态文件里分析，这是更专业的做法。
3. 过滤器使用：从全量流量到目标流量
3.1 两套过滤器，别搞混
说起过滤器，绕不开一个常见的混淆点：Wireshark 里有两套过滤器，一个叫捕获过滤器，一个叫显示过滤器。两套语法功能完全不同，但初学阶段很容易记混。
| 对比项 | 捕获过滤器 | 显示过滤器 |
|---|---|---|
| 语法示例 | port 80 | tcp.port == 80 |
| 生效时机 | 抓包开始前 | 抓包进行中或结束后 |
| 是否删数据 | 是，不匹配的直接丢弃 | 否，只是隐藏显示 |
| 性能开销 | 低，内核层过滤 | 较高，CPU 参与 |
| 适用场景 | 大流量、长期抓包 | 分析阶段反复切片 |
有一个记忆技巧：捕获过滤器在抓之前生效，它的关键词写法很简略，比如port 80、host 1.2.3.4；显示过滤器在抓之后使用，字段要用等号和点号来表示，比如tcp.port == 443。凡是在分析阶段能做的事，尽量别放到捕获阶段去做，因为捕获就丢掉了数据，显示只是把数据藏起来。这两种策略各有使用场景，我把我的默认建议写在这里：一次性的短线排障，抓全量，无损取证；长期的守护抓包，加捕获过滤器，避免吃满磁盘和 CPU。
3.2 最常用的显示过滤器
我把实际工作中使用频率最高的显示过滤器整理成了一张表，只要复制进过滤栏，回车就能用。
| 需求 | 过滤器写法 | 说明 |
|---|---|---|
| 只看某个 IP 参与的所有包 | ip.addr == 10.0.0.5 | 源或目的地址匹配都可以 |
| 只看某一端口的 TCP/UDP 包 | tcp.port == 443 | 同理可用udp.port == 53 |
| 只看 HTTP 请求包 | http.request | 只要客户端发起的请求 |
| 只看 HTTP 响应包 | http.response | 只要服务端回的内容 |
| 只看 DNS 流量 | dns | 查询和响应都会显示 |
| 只看 TCP SYN 包 | tcp.flags.syn == 1 and tcp.flags.ack == 0 | 握手第一个包 |
| 只看有负载的 ACK 包 | tcp.flags.ack == 1 and tcp.len > 0 | 确认携带数据的包 |
| 筛出可疑 TCP 行为 | tcp.analysis.flags | 重传、乱序、零窗口等 |
| 只看目标端口是 8080 | tcp.dstport == 8080 | 排除源端口干扰 |
| 只看 ARP | arp | 二层地址解析相关 |
关于tcp.analysis.flags多说几句。它不是一个真实存在网络包里的字段，而是 Wireshark 根据协议状态推导出来的标记。比如重传、快速重传、乱序、DUP ACK、零窗口、丢包后的补救行为，都会在这个字段显式标出来。用它和具体条件做组合，比如tcp.port == 8080 and tcp.analysis.flags，一条过滤器就能把异常连接全筛出来。这个套路在排线上偶发延迟时非常高效，几乎没有失效过。
3.3 字段补全与表达式生成器
很多新手不敢写复杂过滤器的原因是怕记不住字段名。Wireshark 有两个帮手：一个是表达式生成器，在过滤栏旁边有个菱形图标，点开后可以搜字段名，比如输入 dns，就能看到 dns.time、dns.flags.response 等一大堆字段，双击就会生成完整的过滤条件；另一个是自动补全，你在过滤栏输入ip.、tcp.、http.，下拉会自动列出该协议下面的所有字段。
有个小技巧：任何一个包都可以作为字段模板。点开某个包，在中间协议树里找到感兴趣的字段，右键选择“作为过滤器应用”或“准备过滤器”，Wireshark 会自动生成等价过滤语句。比如你在 DNS 响应包里看到 dns.time 字段值很大，右键选中它并选择“作为过滤器应用 -> 选中”，过滤栏里就会出现dns.time > 0.1这样的条件。学会这种从包到过滤器的用法，根本不用死记语法，实践中越用越熟。
4. 协议疑难排查：TCP、HTTP、DNS 实例
4.1 TCP 三次握手与延迟定位
几乎所有 TCP 应用的连接耗时，都可以归结到三次握手。过滤tcp.flags.syn == 1会把 SYN 包列出来。正常情况下握手是：
客户端 SYN -> 服务端 SYN+ACK -> 客户端 ACK
在显示里，你可以通过时间增量列查看定位延迟的具体操作：双击一个 SYN 包，看它和紧接着的 SYN+ACK 包之间的时间差。这个差值就是连接建立时服务端响应的速度。如果差值一直很大，比如几百毫秒，说明服务端的内核协议栈或中间设备处理不过来。
我处理过一个典型的偶发连接超时案例：某服务平时都正常，但高峰期偶尔会有新建连接变慢。应用日志没有报错的线索，因为从应用层看只是 TCP 连接建立等待时间变长。抓包后发现，同一个客户端对同一端口在 1 秒内连续发出了三个 SYN，间隔分别是 1 秒、2 秒、4 秒，而服务端迟迟不回 SYN+ACK。这个现象说明 SYN 请求到了服务端但没被及时处理，或者丢包。继续对比服务端负载和内核机制后，最后定位到半连接队列被占满，于是调整了系统参数，问题才真正解决。
抓包里关于 TCP 的另一个高频关注点是重传和乱序。重传包会让上层等待，进而表现为接口变慢；乱序则可能让接收端的缓冲区颠簸，触发快速重传。过滤tcp.analysis.retransmission能直接看到重传包，过滤tcp.analysis.out-of-order能看到乱序包。如果你的抓包里重传比例超过 1%，网络状况就该警惕了。
4.2 追踪流：还原完整 HTTP 对话
HTTP 明文协议对抓包非常友好，每一个包都是可见的文本。但只看单独的包效率很低，因为一个请求往往被拆成多个 TCP 段。Wireshark 把这个问题用追踪流解决了：右键任意 HTTP 包，选择“追踪流 -> TCP 流”，Wireshark 会把这条 TCP 连接上的双向数据按顺序拼接起来，显示成完整可读文本。窗口底部可以选择原始 ASCII、十六进制、以及导出原始字节。
这个功能在排查接口返回内容和预期不一致时几乎是决定性工具。有一次，前端说解析后端返回的 JSON 失败了。后端看代码完全没看出来什么问题，测试环境反复尝试也复现不了。我让同事在线上一台机器上抓包，然后我用追踪流看那份响应体，发现实际返回的字节流里在 JSON 中间插了一段错误拼接的字符串，导致解析中断。问题最终指向底层网关的响应封装逻辑。这个结论从来不是靠读代码看出来的，只有把线上实际的字节流拉出来才能确定。
追踪流窗口还支持搜索，可以在整个会话里搜特定字符串。这在分析长连接或者大响应时特别有用，能够帮你快速定位某一个关键参数的上下文。需要注意的是，TCP 流会把整条连接从第一个包到最后一个包都拼出来，如果连接持续时间很长且包含大量数据，打开时会消耗不少内存；对超大流，先用过滤器把时间范围缩小会稳妥很多。
4.3 DNS 时延与失败分析
DNS 往往是拖慢页面的隐形杀手。一个页面里可能有十几个外域资源，每个都要先做 DNS 解析。浏览器开发者工具的网络面板里，你只能看到每个资源的总耗时，但 DNS 解析到底花了多久，面板里不容易看清。抓包则可以精确拆解。
抓包后过滤dns，然后加入 dns.time 列。Wireshark 会把查询包和对应的响应包自动关联，在响应包里显示这一次解析用了多少毫秒。正常本地缓存的解析一般在 1 毫秒以内，正常的局域网解析也就几毫秒。如果看到几百毫秒，说明 DNS 服务器路径上存在明显延迟，比如请求被转发到了很远的上游，或者本地网络质量差。
还有一个常见问题是反复解析。如果同一个域名隔几秒就出现一次查询，而且没有命中缓存，说明客户端没有正确缓存，或解析逻辑每次都被调用。这种看起来没毛病但时时在等的时间损耗，非看包很难意识到。
DNS 错误也值得关注。过滤dns.flags.rcode != 0，会列出解析失败的包。rcode 为 0 表示无错误，常见的非 0 值有 2（服务器失败）、3（域名不存在）。再用协议分级统计看看 DNS 失败率，如果失败比例明显高于正常水平，就值得深入查上游解析配置了。
4.4 HTTPS 的解密条件与边界
现在最常用的应用流量几乎都是 HTTPS，默认抓包只能看到 TLS 握手和密文。如果你想分析的是自己负责的服务、自己控制的客户端，有一个正规途径可以解密：在客户端设置 SSLKEYLOGFILE 环境变量，让浏览器或 curl 把 TLS 会话密钥写入文件，再把密钥文件加载到 Wireshark 的 TLS 配置里。
Chrome、curl 以及大多数主流 HTTP 库都支持这个环境变量。操作步骤如下：
- 在终端里设置环境变量并启动客户端，比如：
export SSLKEYLOGFILE=/tmp/keys.log curl -k https://127.0.0.1/api/v1/demo- 打开 Wireshark，菜单“首选项 -> 协议 -> TLS”，在“Pre-Master-Secret log filename”里填上同一个文件路径。
- 抓包并重新发起请求，此时显示过滤器里输入
http，就能看到解密后的 HTTP 头，追踪流也能看到明文内容。
这个方法有个前提：你必须有客户端进程环境的控制权，且只能在它记录的会话里解密。它不是用来对任意第三方流量做监听的，也谈不上什么技术魔法。按合规和边界的原则，你只应该用它分析自己业务系统的流量，别动别人的数据。
有几个坑要提醒。第一，密钥文件要重新生成或覆盖后才去加载，否则 Wireshark 里看不到新的会话密钥。第二，客户端必须先设置环境变量再发起请求，如果会话在设置之前已经建立，抓到的密文依然解不开。第三，Linux 环境变量不会自动传递给已运行的 GUI 程序，如果用图形界面启动的浏览器，需要改启动脚本或者用终端启动。
TLS 解密还受密钥交换方式影响。如果服务端强制用 ECDHE 之类的前向保密算法，那么会话密钥不会长期固定，而是每次握手都会重新协商；但只要客户端把每段会话的密钥都写进日志文件，Wireshark 就能逐个解开。如果你的服务端用了静态 RSA 密钥且不支持前向保密，情况反而不同，但这类旧配置在最近几年的环境里已经很少见了，遇到再说。
5. 命令行抓包与统计分析
5.1 为什么需要 tshark
图形界面在交互分析时体验最好，但有两个场景它完全无能为力：一是远程服务器没有图形界面，你要抓包；二是要对几百个 pcap 文件做批量统计，不可能一个个打开点击。这时候就用 tshark。
tshark 是 Wireshark 的命令行版本，解析引擎同一套，显示过滤器语法完全一致。这意味着你在图形界面里会的技能，在命令行里基本可以平移。使用 tshark 的另一个好处是资源占用低，它不像 GUI 那样需要渲染界面，可以在低负载环境下长时间抓包。
还有一个常被忽略的理由：自动化。网络排障经常需要定时抓包，比如每天高峰时段自动抓 5 分钟，或者在某进程启动前抓一段基线数据。这些场景用 tshark 写进脚本，配合定时任务，可以做到无人值守采集，遇到问题再调阅存档。
5.2 常用抓包与读包命令
先看抓包的基础命令：
sudo tshark -i eth0 -f "tcp port 80" -w /tmp/http.pcapng -a filesize:102400 -b files:10参数拆开解释：
-i eth0：指定网卡-f "tcp port 80"：捕获过滤器，只抓 TCP 80 端口-w /tmp/http.pcapng：输出到文件-a filesize:102400：文件达到 100MB 即轮转-b files:10：最多保留 10 个轮转文件
这样组合的采集设计，最多占用 1GB 磁盘，适合长时间抓重点端口流量。
读包最常见的需求是把抓包文件里所有 HTTP 请求信息提取成文本：
tshark -r /tmp/http.pcapng -Y "http.request" -T fields -e ip.src -e http.request.method -e http.host -e http.request.uri每一行输出一个请求，依次是来源 IP、方法、域名、URI。整理成这个格式后可以直接丢给 grep、awk、sed 做后续处理，也可以导入表格统计。平时我排查线上问题时，经常先用这条命令快速把谁向谁请求了什么拉出来，再决定要不要下载完整的 pcapng 文件做深入分析。
5.3 统计模块：io,stat 与端点统计
tshark 自带的统计模块也非常实用。-z参数后面可以接统计类型，常用的有io,stat（流量统计）和endpoints（端点统计）。
统计按时间桶分布的流量：
tshark -r trace.pcapng -q -z io,stat,1,tcp.port==443这条命令按 1 秒一个桶打印每秒的流量总量和过滤匹配数，输出形如：
| Interval | Frames | Bytes | 过滤匹配 |
|---|---|---|---|
| 0-1s | 200 | 40000 | 150 |
| 1-2s | 350 | 72000 | 310 |
时间桶里的峰值能直观看出流量是否突发。配合io,stat里叠加多个过滤条件和采样间隔，还能统计每 5 秒、每 10 秒的平均吞吐，排序后找到高峰期起点。
查看通信端点排行：
tshark -r trace.pcapng -q -z ip,hosts它会列出所有通信端点的收发字节数，帮助你快速找到谁是流量大户。若怀疑是某个内网 IP 在持续打满带宽，跑这一条命令就能定位。
统计模块的特点是输出即文本，可以直接作为监控告警的输入。很多运维脚本里，我见过同行把 tshark 统计结果喂给监控系统，判断高峰期的 TCP 重传率是否超标。这也是把抓包能力变成常态化监控的一条可行路径。
6. 常见问题与避坑实录
6.1 权限与接口问题
问题一：打开抓包接口列表是空的，或者点击开始后提示权限错误。
可能性如下：
- 用户不在 wireshark 组，解决：
sudo usermod -aG wireshark $USER，然后重新登录。 - 正在用普通用户但没有 root，解决：用 sudo 跑 tshark，或者加入 wireshark 组。
- 容器环境没有抓包所需的内核权限，解决：在宿主机抓包，或者为容器配置相应权限并挂载设备。
判断当前用户权限是否到位，用id命令看组列表。如果组里已经有 wireshark 还是报权限错误，可能是 dumpcap 的可执行权限不对。Ubuntu 包管理一般会处理，但如果你手动改过权限或者从源码安装过，可以检查 /usr/bin/dumpcap 的所属权和执行位是否正常。
接口列表里出现无线网卡但抓不到其他设备的流量，这个和无线模式、驱动行为都有关系，不一定是配置错误。普通无线抓包只能看到自己发送和接收的数据，要抓其他客户端的数据，得网卡支持监控模式，且驱动开放相关接口。这里多数场景用不上，先不必深究。
6.2 抓包丢包与文件轮转
问题二：抓包过程中右下角提示 N 个包被丢弃。这表示抓包缓冲区满了，来不及处理的数据被网卡驱动丢弃。调整思路有三个。
首先，增加缓冲区大小。在“捕获 -> 选项”里，把缓冲区内存调到 128MB 或者更大。内核会为抓包进程分配一块环形缓冲，容量大一些就能吸收突发流量。
其次，在源头减少输入。加捕获过滤器，比如只抓tcp port 443，把无关流量挡在缓冲区外。这比任何后续处理都有效。
最后，避免 GUI 占用资源。GUI 的实时渲染非常消耗 CPU。生产场景建议关闭图形界面，用 tshark 抓包到文件，抓完再拿回分析。
前面提到的轮转文件，本质不是解决丢包，而是解决磁盘被写满的隐患。但如果发现轮转文件非常多且磁盘空间有限，也可以限制总轮转数量，或者定期清理旧文件。保存 pcapng 时勾上压缩选项，也能明显减小体积，解析时同样能读取。
6.3 名称解析导致的干扰
问题三：抓包结果里所有 IP 都显示成一堆主机名和厂商缩写，反而看不懂了。
Wireshark 默认会尝试做几类名称解析：MAC 厂商解析（把 MAC 前缀显示成某个厂商）、网络名称解析（按 hosts 或 DNS 反查 IP 主机名）、传输层名称解析（按服务端口显示协议名）。对于日常排障，我建议关掉前两类，只在确实需要时手动开启。做法：菜单“视图 -> 名称解析”，把对应的选项都取消勾选。否则，在离线环境里 Wireshark 尝试反查 DNS 会一直等超时，看着就像界面卡住了。处理大型抓包时，名称解析会额外增加不少内存和耗时，关闭后打开文件的速度会有可感知的提升。
如果你确实想保留解析结果，但又不想卡顿，也可以抓包后先用工具生成一份静态的 IP 主机名映射，再考虑是否合并。
6.4 大文件与分析卡顿
问题四：抓了一个文件有几个 GB，打开后操作很卡。
对于大文件，GUI 打开后会把整个文件加载到内存做索引，如果文件过大内存不足，就会走交换空间，进而卡顿。应对办法有几个：
用 tshark 先按条件切分：
tshark -r big.pcapng -Y "ip.addr==10.0.0.5" -w small.pcapng先把目标 IP 的包筛出来，再打开小文件分析。所以生产环境在抓包时设置多文件轮转，让每个文件都小一点，宁可多几个文件，也不要在后期做一次大文件处理。还可以在 GUI 里用标记包功能，把可疑的包标注出来，再导出标记的包，进一步缩小分析范围。
还有一个常年踩坑点：不要开着自动滚屏去抓大流量。这个在前文提过，但值得重复，因为它是新手最容易忽视的 GUI 优化点。
7. 一些使用习惯上的建议
文章写到这里，核心使用方法都过了一遍。最后分享几点我在实际抓包中沉淀下来的习惯。
第一，抓包之前先明确要验证什么。是排查连接超时？还是看响应内容？还是看 DNS 延迟？目的不同，接口选择和过滤器写法完全不同。盲目抓包只会得到一大坨数据，反而让人无从下手。第二，每段抓包都先看协议分级统计，再看 TCP 异常标记，最后才深入具体包。这个顺序能让自己快速建立全局感。第三，抓到的 pcapng 文件按“日期-事件-接口”命名，关键会话加备注，方便事后复盘。一个文件命名混乱，过两天自己都想不起来当时为什么要抓。
抓包不是一个需要靠天赋的技能，它更接近手艺。只要你肯把所有网络疑难杂症都拉到字节层面看一遍，大多数问题都会从模糊的猜测变成确定的证据链。希望这篇文章能成为你第一次独立抓包的起点，也欢迎你在实操中遇到有意思的包，回来一起聊聊。
