网线插着、电脑也没报错但同事就是打不开网页微信却能正常收发消息。这种场景每个搞网络的人应该都不陌生。我平时做运维和安全自查面对这类问题从来不会先打开图形化抓包工具而是先把那8个常用网络命令在命令行里敲一遍。原因很简单ping、netstat、tracert、nslookup、arp、route、telnet、curl这套组合能在最短时间内告诉你故障到底发生在物理链路、网络配置、路由转发、DNS解析还是应用服务层。这篇文章我打算把这8个严格来说是8组常用网络命令掰开揉碎讲清楚包括命令参数、输出解读、安全自查思路和真实排障流程适合刚入门安全的新人、运维同学也适合自己折腾服务器和虚拟机的人参考。我发现很多人遇到网络问题只会无脑重启路由器或者装个网络修复工具点一下但都不知道这些工具背后到底发了什么数据包、查了哪些表。这就是基本功缺失的体现。网络命令就像是给网络做体检的听诊器掌握之后哪怕没有专有的监控平台你也能通过一行行的输出把故障范围从“整个网络”缩小到“某一个请求超时”这种能力在排查效率和面试面试官面前都非常加分。1. 内容整体设计与思路拆解1.1 为什么网络命令是安全排障的第一响应工具在做安全自查或者网络排障的时候我特别看重“确定性”。网络不通到底是哪一段不通界面工具往往给你一个笼统的“网络连接异常”但从命令行我们能拿到具体的来源地址、目标地址、跃点列表、端口状态、丢包率、DNS解析IP。这份确定性是后续所有判断的基础。举个例子你用浏览器访问某个网站超时浏览器只会给你一个“该网页无法访问”。但如果你依次执行ping 网关、ping 公网IP、nslookup 域名、telnet 域名 80很快就能判断出是内网链路问题、运营商链路问题、DNS解析问题还是目标服务器Web服务没响应。这就是行业里常说的“分层排查”也是这些网络命令最核心的价值所在。安全自查时也一样。如果怀疑主机被植入了恶意程序netstat -ano 一下所有对外建立的TCP连接和本地监听的端口都能拉出来再结合任务管理器里的 PID 反查进程基本就能锁定可疑对象。没有这些命令行工具你只能靠杀毒软件的查杀日志但那些东西往往都是有特征库才能发现的而基本的命令排查能帮你捕捉到“异常”本身。1.2 八组命令如何分层覆盖网络协议栈我习惯把网络命令按它们工作的协议层来划分这样记起来不容易乱用起来也能意识到“我现在在验证哪一层”。命令组工作层次核心用途典型场景ping网络层 ICMP测本机到目标主机的连通性、延迟、丢包网关是否通、外网是否通、延迟是否高ipconfig / ifconfig网络接口层查看本机IP、掩码、网关、DNS、MAC判断是否获取到地址、配置是否正确netstat传输层查看TCP/UDP连接状态、端口监听查端口占用、查可疑连接、看连接状态tracert / traceroute网络层追踪数据包经过的路径定位路由黑洞、链路绕路nslookup应用层查询DNS解析记录验证域名解析是否正确arp链路层查看和操作IP与MAC的映射表检测局域网ARP欺骗、排查IP冲突route网络层查看和操作路由表排查多网卡、多网关的选路问题telnet / curl应用层/传输层探测目标端口是否开放、查看服务响应检测服务端口连通性、查看HTTP状态码按这个表格来看其实你只要把八组命令练熟从网线链路到应用层服务的每一层你都能亲手测一遍。这也是我特别推荐刚入行的人不要一上来就学各种重型扫描工具的原因——你把基础命令练透了对协议栈的理解会比别人深得多因为每次敲命令你都在真实地观察数据包的行为。1.3 先配置、再链路、后应用的排查思路可能有人会问碰到问题我先无脑 ping 外网 IP 行不行我建议不要这样。很多年前我也犯过这种错误结果 ping 不通外网我就以为是出口路由问题查了半天发现其实本机网卡压根没获取到正确IP。所以我现在给自己定了一个排查顺序也推荐给你第一步用 ipconfig / ifconfig 确认本机网络配置是最起码的相当于先看清“我是谁、我在哪个网络”。第二步ping 127.0.0.1 验证本机协议栈是否正常。第三步ping 默认网关验证二层链路和本机到路由器的连通性。第四步ping 公网IP验证路由和出口链路。第五步nslookup 验证DNS。第六步telnet 或 curl 验证具体服务端口。最后再用 tracert 定位到底是哪一跳出了问题。这个顺序背后其实是一条依赖链DNS解析依赖外网路由外网路由依赖网关链路网关链路依赖本机配置。先验底层再验上层哪一层失败马上就能圈定范围排查效率至少翻倍。2. 核心细节解析与实操要点2.1 ping连通性测试与ICMP报文怎么看ping 应该算网络命令里最基础的一个它通过发送 ICMP Echo Request 报文等待目标主机回复 ICMP Echo Reply 来判断连通性。我实测下来它可以快速测出三层连通性、往返时间和丢包率三个指标足够判断网络链路“通不通、快不快、稳不稳”。Windows 下我常用这几个参数ping -t 目标IP持续 ping 直到按 CtrlC 结束适合长时间观察链路稳定性。ping -n 10 目标IP指定发送 10 个包适合短时间定量测试。ping -l 1024 目标IP指定发送数据包大小为 1024 字节测大包是否会分片或丢包。ping 目标IP /?查看完整参数说明。Linux 下的写法有一点点区别常用的是ping -c 4 目标IP发送 4 个包后自动停止。ping -i 0.5 目标IP每 0.5 秒发送一个包。ping -s 1024 目标IP指定数据包大小。很多人不会看 ping 的输出。举个例子ping 返回 “来自 192.168.1.1 的回复: 字节32 时间1ms TTL64”。这里“时间1ms”代表往返时间“TTL64”代表数据包经过的设备还没把它减到0。TTL 值一般表示数据包最长能经过多少个路由器每经过一跳 TTL 会减1如果减到0路由器就会丢弃报文并通知源主机“超时”。这也造成一个常见误区不要单纯依据 TTL 值判断对方是什么操作系统因为现在很多系统允许手工修改TTL而且不同系统的初始TTL并不统一。我在排障时通常会先 ping 127.0.0.1 验证本机协议栈再 ping 网关验证二层链路最后 ping 外网IP验证路由。如果 ping 网关丢包多问题大概率在局域网内部比如网线接触不良、局域网广播风暴如果 ping 网关正常但 ping 外网IP丢包那问题就在出口路由器到运营商这一段。2.2 ipconfig / ifconfig本机网络身份的第一步检查拿到一台有网络故障的电脑我第一件事就是看它的网络配置。Windows 下是 ipconfigLinux 下是 ifconfig 或 ip addr。这一步能看出非常多问题IP 地址是不是 169.254.x.xWindows 的 APIPA 自动私有地址说明DHCP没分配成功、网关地址是否正确、DNS 配置是否指向了不可用的服务器、子网掩码跟实际网段是否匹配。ipconfig /all 会比普通 ipconfig 输出更多字段物理地址MAC、IPv4地址、子网掩码、默认网关、DHCP服务器、DNS服务器等。如果公司电脑用的是固定IP你还能核对是不是跟网管规划的VLAN段一致。Linux 下 ip addr 是更现代的命令信息比 ifconfig 更全输出里 “inet 192.168.1.100/24” 表示IP地址和前缀长度/24 等价于掩码 255.255.255.0。如果你想看更详细的路由信息还可以配合 ip route。还有一个容易被忽略的地方Windows 本地 DNS 缓存。如果域名解析被改过或者缓存出错即使 DNS 服务器是正常的系统也可能一直用旧的解析结果。这时候可以执行 ipconfig /flushdns 把本地 DNS 缓存清掉再重新 nslookup 验证。很多“网页突然打不开”的问题靠这一条就能解决。2.3 netstat端口与连接状态的显微镜netstat 是我在安全排查里使用频率最高的命令之一。它的作用简单说就是“看一下这台机器当前有哪些网络连接、哪些端口在监听”。Windows 下我最常用的组合是 netstat -ano“-a”显示所有连接和监听端口“-n”用数字显示IP和端口而不是反解域名“-o”显示对应的进程PID。Linux 下我习惯用 netstat -tunlp其中“-t”显示TCP、“-u”显示UDP、“-l”显示监听端口、“-p”显示进程名和PID。为什么要看连接状态因为 TCP 连接状态能透露很多信息。常见状态有LISTENING本地某个端口正在监听等待连接正常情况下这是我们启用的服务异常情况下可能是恶意程序开的隐蔽端口。ESTABLISHED本机跟某个远端地址建立了连接正在通信。如果发现一个陌生的远端IP长期 ESTABLISHED而且连接进程名称很可疑就要重点排查。TIME_WAIT连接已关闭但为了保证最后的ACK能送达系统会保留这个状态一段时间。大量 TIME_WAIT 一般见于高并发服务端不一定代表故障。CLOSE_WAIT远端关闭了连接但本地程序没主动关闭。如果大量连接堆积在 CLOSE_WAIT说明应用程序有连接泄漏得查代码了。安全自查时我通常会执行 netstat -ano | findstr ESTABLISHED 看一下本机对外建立的连接列表再执行 netstat -ano | findstr LISTENING 看一下本机到底开了哪些端口。如果发现某个端口监听在 0.0.0.0 上且对应进程很可疑就需要进任务管理器去查这个 PID 到底是什么程序。2.4 tracert每一跳都看得见的数据包路径当网络链路通但不管是访问什么都慢或者 ping 某个外网IP有延迟时用 tracert 可以看到数据包从你电脑到目标主机之间经过的每一跳节点。这对定位“出口绕路”和“路由黑洞”特别有用。Windows 下命令是 tracert 目标IP或域名Linux 下是 traceroute。我常用的参数包括-d 不解析每个跃点的主机名排查时能大幅提速-w 指定等待超时时间-h 指定最大跳数一般设30就够。看 tracert 输出时每一行代表一跳第几跳、中间路由器IP、三次探测的往返时间。要注意的是中间某些跳返回“超时”不一定代表链路故障很多路由器出于安全考虑直接丢弃 ICMP 报文所以会出现星号这并不影响后续节点继续响应。但如果你发现从某一跳开始往后的所有节点全部超时而且目标地址也 ping 不通那问题大概出在那个节点或它的回程链路。有一次我排查一个“视频会议卡顿”问题本机 ping 网关延迟1msping 公司互联网出口延迟2ms但 ping 对端服务器延迟高达120ms。用 tracert 一看发现流量绕了大半个网络才到达目标直接在路由层面把问题定位了。2.5 nslookupDNS解析异常一查便知你可能会说“我明明能用浏览器访问啊DNS能有什么问题”但“能访问”和“DNS解析正确”是两码事比如反查域名解析到旧IP、解析记录返回多个IP甚至解析超时这些都会导致细小的访问异常。nslookup 基本用法是 nslookup 域名。Linux 和 Windows 都支持。如果你想指定某台 DNS 服务器来做解析就写成 nslookup 域名 DNS服务器IP比如 nslookup www.example.com 223.5.5.5也能验证是不是本地DNS服务器的查询结果跟公共DNS不一致。输出里值得关注的有几个字段Server 和 Address 表示当前使用的DNS服务器Non-authoritative answer 表示这是缓存得到的非权威应答最后 Name 和 Address 就是域名对应的IP。如果同一个域名查询一次一个IP、再查一次又变成另一个IP而且变化很频繁那多半是DNS轮询或者存在解析异常需要结合业务情况判断。安全场景下nslookup 还能查特定类型的解析记录。nslookup -typeTXT 域名 可以查TXT记录nslookup -typeCNAME 域名 可以查别名记录。做安全评估时确认域名解析到了正确的IP、有没有异常的CNAME指向往往是排查域名劫持和钓鱼仿冒的第一步。2.6 arp局域网地址解析和欺骗自查ARP 解决的问题是已知目标IP怎么找到对应的MAC地址。每台主机会在本地维护一个 ARP 缓存表记录IP和MAC的映射关系。Windows 下用 arp -a 查看Linux 下用 ip neigh show 查看。如果你所在的是办公网或实验室网络ARP 缓存表非常值得关注。最典型的安全问题是 ARP 欺骗攻击者通过发送伪造的 ARP 报文把网关IP映射到攻击者的MAC地址这样一来同网段主机的流量就会先发到攻击者的机器上可以抓包分析或者篡改后再转发而用户侧很难感知。自查方法其实很简单在故障时间内连续多次执行 arp -a 查看网关IP对应的MAC地址如果发现网关的MAC一直在变或者一个IP对应了多个MAC就要高度怀疑局域网存在ARP欺骗。如果确认是ARP欺骗常规处理是用 arp -d 清空缓存、重新获取正确的ARP映射然后从接入层交换机排查是谁在发异常ARP报文。注意Windows 下 arp 命令本身也能手工添加静态映射但在家庭或办公网环境下我不建议你手工指定因为一旦 IP 或 MAC 变化静态表会导致网络完全不通反而引入新的故障。2.7 route路由表决定流量怎么走路由表是每个主机的“方向感”它决定一个数据包到达某个IP段时应该交给哪个网关。Windows 下输入 route printLinux 下输入 ip route就可以看到完整路由表。我一般在第一次配置服务器或者修复多网卡主机时非常依赖 route。如果一台机器有多个网卡比如一个连内网、一个连外网系统默认只会用第一个符合条件的网关这就可能导致“内网能通、外网不通”或者反过来。这时候就需要手动往路由表里加一条指定的静态路由告诉系统“去某个网段的流量走某个网关”。添加静态路由的格式在 Windows 下是route add 目标网段 mask 掩码 网关 -p最后带上 -p 表示持久化重启不会丢。Linux 下则是 ip route add 目标网段/前缀 via 网关。查看路由表时最需要注意的是 Default Route默认路由。如果默认路由缺失或指向了不可达的网关即使IP和DNS配置都正常你也上不了外网因为系统根本不知道该把数据包交给谁。很多人排查外网不通的时候会漏掉这一步直接用 ping 外网IP结果怎么都不通其实检查一下默认路由一秒就能发现问题。2.8 telnet / curl应用层端口连通性的一次“握手”网络层和传输层都通了不代表应用层就一定正常。举个例子你能 ping 通一台服务器但访问它的 8080 端口却白屏这时候就要用 telnet 或 curl 来验证端口和服务响应。telnet 的经典用法是 telnet 目标IP 端口如果端口开放你会进入一个黑窗口或者看到服务的Banner信息如果端口拒绝连接或超时说明服务没监听该端口或防火墙拦截了。不过 Windows 默认可能没有安装 telnet 客户端如果不想装组件可以用 PowerShell 的 Test-NetConnection 目标IP -Port 端口来替代。curl 是更偏应用层的工具它能直接发起HTTP请求看到完整响应头和状态码。排查 Web 服务时我常执行 curl -v http://域名 或者 curl -I http://域名前者能显示SSL握手、请求头、响应体的全过程后者只取响应头。看到 HTTP 200 说明服务正常返回 500 说明服务端代码异常返回 403 可能是权限问题。在这个意义上curl 算是一个轻量级的接口自测工具。有一点要专门提醒telnet 和 curl 都只能证明“端口通、服务有响应”并不能证明应用功能完全正常。曾经有个同事拿 telnet 测试一个端口显示能连接就认为服务没问题结果其实那个端口上是一个坏进程在监听业务根本不可用。所以端口探测通常要和业务自身的健康检查接口配合使用。3. 实操过程与核心环节实现3.1 一次真实的“浏览器打不开网页”排查实录下面我用一个实际遇到的排查过程把这些命令串起来。场景是这样的某天下午办公网里一位同事反馈浏览器打不开网页但微信和钉钉收发消息正常。我先记录下当前时间然后开始命令行排查。第一步ipconfig /all。我看到本机IP是 192.168.1.108掩码 255.255.255.0默认网关 192.168.1.1DNS 也是 192.168.1.1。这是很常见的小型办公网配置说明DHCP有正常分配地址本机网络配置没问题。第二步ping 127.0.0.1。返回正常说明本机TCP/IP协议栈没有异常网卡驱动层面基本正常。第三步ping 192.168.1.1。延迟小于1ms没有丢包说明本机到网关的链路物理层和二层都正常。到这里内网基础链路已经排除。第四步ping 223.5.5.5。结果请求超时。看到这个结果时第一个怀疑对象变成了出口路由或运营商链路。但注意这里不能立刻下“外网不通”的结论因为很多网络设备会拦截 ICMP 报文导致 ping 不通但实际TCP业务正常微信能正常收发正好印证了“出口可能没有完全断”。第五步nslookup www.example.com。返回了正常解析地址。所谓打不开网页DNS解析不是罪魁祸首。于是我把重点放在“TCP 443端口到目标服务器是否可以连通”。第六步用 curl -v https://www.example.com 测试。结果一直卡在连接阶段最后超时。再用 telnet www.example.com 443 测试同样无法建立连接。这说明从本机到目标网站的443端口存在通信阻断而出于微信正常说明并不是所有外网流量都被阻断更像是针对某些目标IP或端口段的访问异常。第七步为了看看到底是哪一跳的问题我执行 tracert -d www.example.com。发现前几跳都能正常响应但到第三跳之后就开始超时之后的跳数也全部星号。综合前面“微信正常、网页超时”的现象能大概判断问题出在出口路由策略或运营商互联链路对特定目的地址的限制。第八步用 netstat -ano 看了一眼当前浏览器进程有没有建立到目标IP的 TCP 连接果然没有任何 ESTABLISHED 记录进一步确认浏览器不是连接成功后被服务器主动断开而是压根没连上。最后结论是本机网络、DNS、网关、基础出口都正常问题更可能出在特定链路段的策略限制上。后续我把traCert和curl结果反馈给出口网络负责人他们排查后在防火墙上做了对应调整网页访问恢复正常。这套流程从开始排查到定位问题大概10分钟。如果一上来就盲目重装浏览器或者把电脑重启几遍大概率仍然解决不了问题。3.2 一份可以直接抄的排查顺序表为了方便你以后照葫芦画瓢我整理了一份通用排查顺序表排查目的命令判断标准确认本机网络配置ipconfig / ifconfigIP不是169.254网关和DNS配置正确验证协议栈ping 127.0.0.1能收到回复验证内网链路ping 默认网关延迟低、不丢包验证出口和路由ping 公网IP能通说明出口链路正常验证DNS解析nslookup 域名能返回正确IP验证具体服务端口telnet 目标IP 端口能连接说明端口开放验证Web服务curl -v 域名有HTTP响应状态码符合预期定位路径问题tracert -d 目标观察哪一跳开始超时检查端口和连接netstat -ano确认端口监听和连接状态检查局域网ARParp -aIP和MAC映射正常这张表基本覆盖了从物理层到应用层的所有检查项。遇到情况时按顺序执行把每一步的结果记录下来会比满脑子乱猜高效得多。3.3 把常用命令组合成自动化巡检脚本平时如果不想每次出问题都手动一条条敲命令可以把上面这些命令写成一个脚本在计划任务里定时跑每次输出带时间戳的日志。这样事后回溯时就有一份“当时的网络状态现场记录”。Windows 下可以写一个简单的批处理脚本思路是逐条执行命令并重定向到日志文件echo off set LOGFILEC:\logs\netcheck_%date:~0,10%.log echo %date% %time% %LOGFILE% ipconfig /all %LOGFILE% 21 ping -n 4 127.0.0.1 %LOGFILE% 21 ping -n 4 192.168.1.1 %LOGFILE% 21 ping -n 4 223.5.5.5 %LOGFILE% 21 nslookup www.example.com %LOGFILE% 21 netstat -ano %LOGFILE% 21 route print %LOGFILE% 21Linux 下可以用 Shell 脚本#!/bin/bash LOG/var/log/netcheck_$(date %F).log echo $(date %F %T) $LOG ip addr $LOG 21 ip route $LOG 21 ping -c 4 127.0.0.1 $LOG 21 ping -c 4 192.168.1.1 $LOG 21 ping -c 4 223.5.5.5 $LOG 21 nslookup www.example.com $LOG 21 ss -tunlp $LOG 21把这些脚本放进定时任务里每天跑几次一旦收到“上午10点网络出过问题”的反馈直接把对应时间点的日志拉出来看到的不是用户的主观感受而是真实的IP、延迟、丢包、端口状态数据定位效率完全不一样。4. 常见问题与排查技巧实录4.1 高频报错速查与处理思路我把自己在排障过程中经常遇到的几个报错和排查方向整理成了一张表方便你遇到时快速对照报错现象可能原因处理思路目标主机无法访问 / 请求超时对端主机宕机、防火墙禁ping、路由不可达先ping网关缩小范围再试tracert看断在哪一跳Destination host unreachable本机路由表里找不到通往目标网段的路径检查route print确认默认路由或静态路由一般故障网卡配置异常、网线断开ipconfig /all看IP是否为169.254检查物理连接无法解析服务器的DNS地址DNS服务器不可达或配置错误nslookup 指定可信DNS服务器ipconfig /flushdns清缓存端口连接被拒绝服务未启动、防火墙拦截telnet目标IP端口检查服务进程监听状态大量 TIME_WAIT高并发短连接后正常现象结合QPS评估如果异常剧增再查服务端连接队列大量 CLOSE_WAIT应用程序没有主动关闭连接netstat -ano找出对应PID排查程序代码或连接池配置我特别提醒一句出现“请求超时”和“目标主机不可达”不要当作同一个问题前者说明数据包发出去后没回应可能是对端丢弃或防火墙限ICMP后者说明网络栈已经明确告诉你这个目标不可达通常是路由问题。这两个报错背后的排查方向完全不同。4.2 三个反直觉的网络排查经验第一个反直觉经验TTL值变小不代表链路一定变差。TTL的作用是防止数据包在网络里无限循环每经过一台路由器就减1。默认TTL一般会是64、128或255所以你ping一个很远的目标发现TTL是54只能说明经过了10跳而不是“目标主机有问题”。第二个反直觉经验tracert 输出里的星号并不等于网络中断。很多路由器默认丢弃ICMP或者接口限速你会在某一跳看到星号但后续节点依然正常响应。只有从某一跳开始连续所有跳都星号而且最终目标也不通才需要怀疑是那个位置链路中断。第三个反直觉经验netstat 看到大量 TIME_WAIT 不一定就是被攻击了。只要你的服务是高并发或短连接模式比如Web接口被频繁调用TIME_WAIT 多是非常正常的现象。反而是系统里如果出现大量 ESTABLISHED 连接到同一个陌生IP或者本机多了若干个非预期监听的端口才更值得警惕。4.3 排查习惯比命令本身更值钱我见过不少新人把命令参数背得很熟但一到真实故障现场就乱了手脚原因就是没有形成相对固定的排查动作。我自己踩过几次坑之后总结出三个非常实用的小习惯。第一个习惯先记录后动手。开始排查时先在记事本或终端里留下一个时间戳把故障现象原样抄一遍比如“浏览器打不开 www.example.com微信正常”。这看起来很简单但能帮你避免排查到一半忘掉最初的约束条件。很多问题的判断依据就是这些现象之间的细微差别。第二个习惯命令输出尽量留档。尤其是做安全自查时netstat、arp -a 和 route print 的输出都是定位异常的关键证据。把输出保存到文件或者直接截图留存既方便事后复盘也能在需要时跟同事讨论。第三个习惯不要一上来就重启。很多人一遇到网络问题第一反应是重启电脑、重启路由器、重装驱动其实这会破坏现场。换到安全视角也一样如果怀疑主机被植入恶意程序第一时间重启会导致内存里的恶意进程消失、可疑连接断掉留下不了证据。先跑一遍 netstat -ano 和 tasklist 这种基本命令把“现场”固定下来再决定怎么处理。4.4 一条好记的排查线索口诀把常用的排查顺序编成一个“口诀”实战中很有帮助先看网卡配置ipconfig再测本机回路ping 127.0.0.1网关通不通定内网ping 网关公网通不通定出口ping 公网IP域名解析靠 nslookup端口服务用 telnet 和 curl路径问题 tracert 查异常连接找 netstat局域网异常翻 arp方向不对看 route。这句话其实就是我平时排查所有网络问题的基本套路。你不需要每次都把整套命令跑完大多数时候跑到第三步“ping 网关”就能定位故障了。比如网关 ping 不通再做 tracert 也没意义直接去查交换机和网线就行。能少跑命令的时候反而说明你对问题层级有准确的判断。最后再分享一个小技巧。如果你觉得 tracert 每次输出太零散可以在 Windows 上用 pathping 命令把路径追踪和丢包统计结合在一起它会先做路由追踪再对每一跳发送一定数量的探测包做统计比单独跑 tracert 再跑 ping 高效得多。Linux 下更省事的做法是用 mtr 目标地址它把 traceroute 和 ping 的动态统计放在一个界面里刷新实时更新延迟和丢包率排查“高延迟”“间歇性丢包”这类问题时信息密度非常高。这两个命令本质上都是把前面提到的八组基础命令做了一层组合和封装我建议你先把基础的跑熟再借助它们提速。