软件测试工程师必学Linux技能：日志排查与系统定位实战

记得刚带测试团队那会儿，每次面试新人我都会问一句：“在Linux服务器上看日志，你一般怎么操作？”不少候选人简历里写着“熟悉Linux”，真到现场，要么盯着屏幕半天不知道从哪个文件看起，要么只会tail -f加Ctrl+C，一问grep的上下文参数就卡壳。

这几年移动互联网和云原生技术普及之后，测试工程师面对的早就不只是“点一点界面、填一填表单”那么简单了。被测系统跑在Linux服务器上，测试环境由我们自己搭建，Bug需要靠日志定位，性能问题需要从系统指标里找线索，自动化用例需要在流水线上执行。可以说，Linux操作能力直接决定了测试工程师的排查效率和职业天花板。这篇文章我就结合自己多年的一线经验，把软件测试工程师真正用得上、用得好、能解决问题的Linux技能，从头到尾梳理一遍。不讲空洞的理论，全部是工作中能直接落地的操作和思路，适合刚入门的新人，也适合想要系统补强Linux短板的功能测试和自动化测试工程师。

1. 为什么软件测试工程师绕不开Linux

1.1 测试工作的每个环节都有Linux的影子

很多人以为Linux是开发或者运维的事，测试只要会写用例、会点系统就行。这个认知在十年前也许还能混过去，现在基本行不通了。我随便列几个测试日常场景，你看看是不是都离不开Linux：

测试环境部署。被测系统不管是微服务架构还是单体应用，绝大多数跑在Linux服务器上。测试人员拿到一个迭代版本，第一件事就是往测试环境部署。部署过程免不了要解压安装包、修改配置文件、启动服务、查看启动日志、确认进程存活。这一整套动作，全部是Linux操作。

Bug定位与复现。功能测试发现一个Bug，不是提交个缺陷单就完了。负责任的测试至少要判断这个Bug是前端问题还是后端问题。怎么看？抓接口请求、看后端日志、查数据库数据。后端服务在Linux服务器上，日志文件在Linux系统里，数据库连接也要通过Linux环境去操作。不会Linux，你连Bug发生在哪一层都说不清楚。

测试数据准备。功能测试需要各种状态的测试数据，比如订单要造出“已支付”“已发货”“已退款”各种状态，用户要准备不同权限级别的账号。直接在界面上一条条造效率太低，更常见的做法是连到数据库直接插入记录，或者通过批量脚本调用接口生成。连数据库要会Linux下的客户端工具，跑批量脚本要会执行命令行。

性能测试与监控。做压力测试的时候，除了看被测系统的响应时间，还要观察服务器的CPU、内存、磁盘IO、网络带宽这些系统资源指标。不会用top、free、vmstat，你连性能瓶颈在哪儿都不知道，只能干瞪眼等开发来查。

CI/CD与自动化执行。现在稍微成熟一点的团队，自动化测试都会接入持续集成流水线。用例脚本跑在Linux构建机上，定时任务用crontab配置，执行结果以日志文件形式输出。测试人员至少要会查看流水线日志、手动触发任务、修改一些简单的脚本配置。

所以你看，Linux并不是测试工程师的“加分项”，而是实打实的“刚需”。它不是某个特定岗位的专属技能，而是整个软件研发链条里测试环节的基础工具。

1.2 测试工程师学Linux与运维工程师有什么不同

这就要说一个很关键的问题：测试工程师学Linux，千万不要照搬运维工程师或者系统管理员的学习路径。

运维工程师需要掌握用户管理、权限体系、防火墙策略、服务配置、内核参数调优、磁盘阵列、负载均衡，甚至要会写复杂的Shell脚本做自动化运维。这些东西对测试来说，绝大部分在实际工作中根本用不上。你要是按运维的路径去学，学两个月可能还在折腾防火墙规则，而测试工作需要的日志排查能力反而没练到，典型的“学了一堆用不上的，用得上的一堆没学”。

测试工程师学Linux，核心目标只有一个：能独立完成测试环境的管理和被测系统的排查。说得更直白一点，就是“出了任何环境问题，你能自己动手查明白、解决掉”。

所以测试学Linux要把握三个原则：

任务驱动。不要孤立地背命令，而是想清楚“我要做什么”。比如我要看应用日志的最新输出，那就学tail -f；我要在日志里找报错信息，那就学grep；我要看某个端口被谁占了，那就学lsof和netstat。每个命令都和一个具体任务绑定，记得牢，用得上。

够用就好。掌握高频命令的常用参数，优先级远高于把所有命令的所有参数都背下来。命令是工具，不是考试大纲。我用了十几年Linux，sed的高级用法到现在还是偶尔查手册，但这完全不影响日常工作。

动手为主。Linux操作没有捷径，光看不练等于白学。你可以在自己电脑上装个虚拟机，或者买一台便宜的云服务器，把日常测试工作的场景搬到上面去练。练的次数多了，手指比脑子记得还快。

2. 测试工程师必须吃透的核心命令与操作

这一章我按测试工作的实际需求，把最常用、最重要的Linux技能分类拆解。每一类我都会先讲清楚“什么时候用”，再讲“怎么用”，最后补充一些实际操作中的心得。这里列出来的命令，是测试工程师使用频率最高的那部分，建议收藏下来反复练。

2.1 日志追踪三板斧：tail、grep、less

日志是测试人员最好的朋友，也是最常打交道的文件。测试环境出了问题，第一反应就应该是去看日志。Linux下看日志，主要靠下面这几个命令。

tail。查看文件末尾内容。测试中最常用的场景是实时跟踪日志输出，比如你刚触发了一个操作，想看系统即时打印了什么信息。

# 实时跟踪日志，Ctrl+C退出 tail -f /opt/app/logs/backend.log # 查看最后200行日志 tail -200 /opt/app/logs/backend.log

-f参数非常实用，但有个小坑：如果日志文件被轮转（就是被重命名并新建了一个同名的文件），tail -f会追踪旧文件，看不到新内容。这时候用tail -F（大写），它会根据文件名重新打开文件，自动跟随新文件。

grep。在日志文件里搜索关键字。测试中最经典的用法，就是在几万行日志里快速定位到某条报错。

# 在日志里搜索“ERROR”关键字，并显示行号 grep -n "ERROR" /opt/app/logs/backend.log # 搜索关键字，同时显示匹配行的前后各10行（上下文） grep -10 "NullPointerException" /opt/app/logs/backend.log # 在日志中搜索“timeout”，忽略大小写 grep -i "timeout" /opt/app/logs/backend.log

grep -10这个用法对于测试来说太重要了。光看报错那一行往往不够，报错的前后几行才是定位问题的关键上下文。我习惯的做法是：先用grep -n找到报错出现的行号，再用sed -n '100,130p'精确查看某一段内容，双管齐下非常高效。

less。分页查看大文件。日志文件动辄几百MB，直接用编辑器打开会卡死。less可以轻松打开，而且支持搜索和翻页。

# 打开日志文件 less /opt/app/logs/backend.log # 在less中按 / 输入关键字，回车搜索；按 n 跳到下一个匹配 # 按 G 跳到文件末尾，按 g 跳到文件开头 # 按 q 退出

实际操作中最爽的组合拳是：tail -200先看最新的日志有没有异常，然后grep -10 'Exception'搜索所有异常位置，最后less +行号精准跳转到某个异常位置，查看完整的上下文内容。

2.2 进程与端口管理：ps、lsof、kill、systemctl

被测系统起不来，或者端口被占用，是测试环境最常见的故障类型。这时候就要靠进程和端口管理命令。

ps。查看进程状态。最常用的场景是“确认被测系统还在不在”、“这个服务是谁在跑”。

# 查看所有进程，按关键词过滤（测试最常用） ps -ef | grep java ps -ef | grep nginx # 看某个进程的详细信息 ps -ef | grep 8080

注意grep本身也是一个进程，所以用ps -ef | grep java的时候，匹配结果里会有一个grep java的进程，这是正常的，别误判。

lsof。查看端口占用情况。“启动服务时提示端口被占用”这个报错，测试环境里太常见了。

# 查看8080端口被哪个进程占用 lsof -i:8080 # 查看某个进程打开的文件和端口 lsof -p 12345

lsof -i:8080的输出里，PID那一列就是占用端口的进程ID。拿到PID之后，配合ps -ef | grep PID就能看到是哪个程序。如果是残留的旧进程，直接kill -9 PID干掉。

kill。结束进程。

# 结束单个进程 kill 12345 # 强制结束（遇到“杀不死”的进程时使用） kill -9 12345 # 按名称结束所有相关进程（慎用） pkill -9 java

kill -9是强制终止，不给你善后的机会。业务进程能不用就不用，先试普通kill，让它有机会保存状态、清理资源。只有普通kill没反应的时候才上-9。

systemctl。管理系统服务。现在很多测试环境里的中间件（MySQL、Redis、Nginx）是用systemd管理的。

# 启动/停止/重启服务 systemctl start mysqld systemctl stop mysqld systemctl restart nginx # 查看服务状态 systemctl status mysqld

用systemctl管理服务的好处是，它会把服务的启动日志、运行状态、错误信息都收集起来。systemctl status输出的内容，比你自己去翻日志还要直观。

2.3 磁盘与内存检查：df、du、free、top、load average

性能测试、稳定性测试，以及测试环境“莫名其妙变慢”的场景，都需要看系统资源。

df。查看磁盘空间。

# 查看磁盘整体使用情况 df -h # 查看特定目录所在磁盘 df -h /opt

磁盘满了是最容易被忽略的环境问题。日志文件疯狂增长、临时文件堆积，都可能把磁盘塞满。磁盘满了之后，服务可能报“No space left on device”，数据库可能直接拒绝写入。测试环境出问题，先df -h看一眼，成本最低。

du。查看目录占用的磁盘空间。

# 查看当前目录下各个子目录的大小 du -sh * # 查看指定目录的总大小 du -sh /opt/app/logs

用磁盘的时候，测试最好养成定期清理的习惯。自动化测试跑久了会生成大量报告、截图、日志，时间长了非常惊人。我见过一个测试环境的/tmp目录里堆了几个月的自动化截图，占了几个GB的磁盘空间。

free。查看内存使用情况。

# 查看内存信息（-h表示人类可读的单位） free -h

要注意的是，Linux里的free输出，used内存看起来很高不代表内存不够，因为Linux会把空闲内存用作文件缓存（buff/cache），用到的时候会自动释放。真正需要关注的数值是available，这才是估算可用内存的关键。

top。实时查看系统负载和进程资源占用。

# 打开top面板，每秒刷新一次 top

进入top之后，按P按CPU占用排序，按M按内存占用排序，按q退出。性能测试的时候，top是观察被测系统压力的利器。如果发现某个Java进程CPU使用率飙到几百甚至上千，多半是代码死循环或者频繁GC，要赶紧截图下来发给开发。

另外要关注load average。top第一行最后的三个数字，分别代表1分钟、5分钟、15分钟的平均负载。如果这三个数远高于CPU核心数，说明系统已经超负荷运转了。性能测试报告里，这个是必写的重要指标。

2.4 用户权限与文件操作：chmod、chown、ln、sudo

测试环境部署过程中，权限问题是绕不开的坑。服务启动不了，很多情况下根本不是程序的问题，而是Linux权限设置不对。

chmod。修改文件权限。

# 给文件添加执行权限（通常是脚本文件） chmod +x start.sh # 设置更具体的权限：属主读写执行，属组读写，其他人读 chmod 764 start.sh

chmod 764里的数字，相信很多新手会搞混。其实记一个最简单的心法就行：r（读）=4，w（写）=2，x（执行）=1。第一个数字是属主权限，第二个是属组权限，第三个是其他人权限。7=4+2+1就是读写执行全开，4=只读。

chown。修改文件属主和属组。这个命令在部署应用时特别常用，因为很多应用要求运行用户对文件有所有权。

# 把文件属主改为app用户，属组改为app组 chown app:app /opt/app/config.yml # 递归修改目录下所有文件 chown -R app:app /opt/app

ln。创建链接文件。这个命令测试日常用得不算多，但理解了它的概念，遇到问题就不会发懵。

# 创建软链接（类似于Windows的快捷方式） ln -s /opt/app/current /home/test/project

软链接的意义在于，你可以把一份部署好的版本链接到一个固定路径。每次部署新版本，改一下链接指向就行，引用路径不用变。很多测试环境的部署脚本都用这个思路管理多版本。

sudo。临时用管理员权限执行命令。

# 以root权限执行命令 sudo systemctl restart mysqld sudo rm -rf /opt/app/logs/old.log

sudo用起来要格外小心，尤其是sudo rm -rf后面跟的路径，一定要反复确认。我见过不止一次，有人本想清理日志目录，结果路径少打一个字符，把整个应用目录都删干净了。

2.5 网络排查工具：ping、telnet、curl、netstat

接口测不通、页面打不开、数据库连不上，这类网络问题测试工作中经常碰到。排查的思路是先分清是哪一层的问题，再对症下药。

ping。检查网络连通性。最简单的判断“两台机器之间能不能通”的方式。

# 测试到某个IP的连通性 ping -c 3 192.168.1.100

telnet。检查某个IP的某个端口是否开放。比ping更细一层，能确认目标端口能不能连上。

# 测试某IP的8080端口是否可连接 telnet 192.168.1.100 8080

连上了会显示连接成功，连不上会卡住直到超时。这个命令特别适合用来判断“我的服务起来了，但为什么别人访问不了”——先telnet一下，如果端口不通，问题多半出在网络或者服务监听配置上。

curl。发送HTTP请求。这是测试工程师最强大的网络排查工具，用它可以直接验证接口是否正常返回。

# 发送GET请求，显示响应内容 curl http://localhost:8080/api/health # 查看请求和响应的完整细节（包括Header） curl -v http://localhost:8080/api/health # 发送POST请求，携带JSON数据 curl -X POST -H "Content-Type: application/json" -d '{"username":"test","password":"123456"}' http://localhost:8080/api/login

接口报错，开发说没问题，你拿curl直接打一发，返回结果甩过去，这比口头描述一百遍都管用。

netstat。查看网络连接和端口监听情况。常用场景是“服务起来了，但端口没监听”。

# 查看所有监听中的端口 netstat -tlnp # 查看80端口的情况 netstat -tlnp | grep 80

-t表示TCP，-l表示监听中的连接，-n表示显示数字端口，-p表示显示进程信息。这一条组合拳，能把当前机器上所有监听端口和对应进程一次性全列出来，排查环境问题太好用了。

3. 测试工作实战场景复盘

命令学了一堆，关键还得会串联使用。我挑三个测试工作中特别典型的场景，完整复盘一下排查过程和操作思路，这些场景我自己都亲身经历过，照着走一遍，你就能体会到Linux技能在测试工作中的威力。

3.1 场景一：被测服务启动失败，如何一步步定位

现象：测试环境某后端服务部署新版本之后，systemctl start提示启动失败，服务一直起不来。

新手最常见的反应是：重启一次不行，再重启一次；还不行，找开发帮忙。其实自己动手，几分钟就能定位到问题。

第一步：看服务状态

systemctl status backend-service

这一步先确认服务的当前状态，以及systemd记录的最近日志。很多时候，问题原因就藏在状态输出的最后几行里，比如“配置文件语法错误”“端口被占用”“目录不存在”等关键信息。

第二步：看专项日志

如果状态信息不够明确，就去应用日志里翻启动日志：

tail -100 /opt/app/backend-service/logs/startup.log

重点看有没有异常堆栈。常见的启动失败原因，比如数据库连不上，日志里会有Connection refused；配置文件读不到，会有FileNotFoundException；端口被占用，会有Address already in use。

第三步：验证网络依赖

启动日志里如果提示连不上数据库，先别急着甩锅给DBA，自己先测一下连通性：

telnet 127.0.0.1 3306

如果telnet显示无法连接，可能是数据库服务挂了，也可能是数据库端口配置错了。再检查一下数据库服务本身：

systemctl status mysqld

发现MySQL进程确实没在运行，启动MySQL确认服务起来之后，再回头启动应用。到这里，问题大概率已经解决了。

第四步：检查端口冲突

如果日志提示Address already in use，说明8080端口被别的进程占了：

lsof -i:8080

看到PID之后，用ps -ef确认是不是残留的旧进程。如果是旧版本的服务进程，kill -9干掉，重新启动新版本，问题解决。

这个排查过程总共不到十分钟，全是用Linux命令完成的。你想想，如果不会这些，光是报个“服务起不来”，让开发远程看，来回沟通的时间成本，可能一下午就过去了。

3.2 场景二：接口偶发超时，如何从日志和系统状态找到根因

现象：某个查询接口，大多数时候响应正常，但每过一段时间就出现一次超时。功能上查不出规律，开发表示“代码跑了这么久没见有问题”。

这种偶发问题，靠点界面是无法复现和定位的，必须从服务器端找证据。

第一步：在应用日志里搜索超时记录

grep -n "timeout" /opt/app/backend-service/logs/error.log

搜到超时时间点后，记录下这些时间点。

第二步：顺着时间点查系统资源

找到超时时间段对应的系统状态。可以用vmstat定时采样系统资源：

vmstat 1 30

这个命令每1秒输出一次系统状态，连续输出30次。重点看cs（上下文切换）和wa（IO等待）。如果wa飙高，说明磁盘IO吃紧，很可能是大文件读写或者日志刷盘导致的瓶颈。

第三步：定位IO大户

用top按磁盘等待排序：

top # 按W（大写）按IO等待时间排序

如果发现某个Java进程的IO等待特别高，用lsof -p PID看看它打开了哪些文件。很可能有个大日志文件或者临时文件正在被频繁读写。

第四步：结合日志和系统指标下结论

把搜索到超时时间点和vmstat采样的数据对比，如果超时时间点恰好和IO等待峰值重合，那基本可以判断根因是磁盘IO瓶颈。你再看看被测系统是不是把日志级别调成了DEBUG，日志量暴涨导致磁盘IO成为瓶颈。把日志级别调回INFO，超时问题自然消失。

这种排查思路，就是测试工程师在Linux环境下的“侦探工作”——所有结论都基于命令输出的客观数据，而不是拍脑袋。你交付给开发的不是一个“偶尔超时”的模糊反馈，而是一份带着时间点、性能指标、日志证据的完整报告。

3.3 场景三：批量准备测试数据，用循环加命令快速完成

功能测试经常需要造数据，“给100个用户每人生成一笔已支付的订单”这种需求，全靠界面操作能累死人。Linux下的Shell脚本能力，这时候能派上大用场。

第一步：编写批量插入脚本

假设数据库是MySQL，可以直接用一条Shell循环拼接SQL并执行：

for i in $(seq 1 100) do mysql -u tester -ptest123 -h 127.0.0.1 testdb \ -e "INSERT INTO orders (user_id, status, amount, create_time) VALUES ($i, 'PAID', 99.00, NOW());" done

seq 1 100生成1到100的序列，循环体里通过mysql -e执行插入语句。100条订单数据几秒钟就造好了。

第二步：批量调用接口造数据

如果被测系统提供创建订单的接口，用curl批量调用更贴近真实请求：

for i in $(seq 1 100) do curl -s -X POST http://localhost:8080/api/orders \ -H "Content-Type: application/json" \ -d "{\"userId\":$i,\"amount\":99.00,\"status\":\"PAID\"}" echo "created order $i" done

-s参数让curl安静模式（不显示进度条），echo输出进度方便观察。跑完之后，tail查看接口日志，确认100个请求都成功了。

第三步：用循环清空脏数据

测试结束，要把造的数据清理干净，一条命令搞定：

mysql -u tester -ptest123 -h 127.0.0.1 testdb \ -e "DELETE FROM orders WHERE amount = 99.00;"

你写脚本的能力不一定要求达到专业运维的程度，但能基于循环、变量、管道组合出自己需要的小工具，测试效率会有质的飞跃。

4. 常见问题排查与避坑技巧实录

这一章我把自己踩过的、带过的团队踩过的一些高频坑整理出来，做成一个“问题——原因——解决”的速查表。出现同类问题的时候，直接对照排查就能少走弯路。

下面展开讲几个最典型的坑，每一个都值得多写几句。

权限类问题的第三个维度。很多测试新人会困惑：明明文件权限看起来是对的，为什么服务还是起不来？这时候很可能忽略了文件属主这个维度。ls -l的输出第二列就是属主和属组。如果文件属主是root，而服务是以app用户启动的，即使权限是rw-r--r--，app用户也无权修改这个文件。解决方法是chown app:app把属主换过来。

crontab的坑。定时执行自动化测试脚本，结果到点没跑。排查思路：先crontab -l看任务是否配置正确；再看任务脚本有没有执行权限；三看crontab服务的运行状态；四看任务执行的日志记录。很多人的crontab执行不了，是因为在crontab里用了相对路径或者调用了环境变量，而crontab执行时的环境和你手动执行时不一样。最好的做法是在脚本里写绝对路径，并且在脚本开头显式设置所需的环境变量。

进程残留的坑。测试环境里最常遇到的“端口被占用”，十有八九是之前部署服务时，旧进程没被杀干净。有一种情况特别容易漏：你执行了kill -9 PID，再去lsof -i:8080看，端口还是被占着。这是因为进程虽然被杀了，但网络连接还处在TIME_WAIT状态。这种情况下等一会儿连接自动释放就行，也可以用netstat -tlnp | grep 8080确认监听状态。

“为什么我改了配置没生效”的经典陷阱。有三种可能：改错了文件、改完没重启服务、服务启动时读取的是别的目录下的配置文件。排查第一步是cat确认文件内容是否改对了；第二步systemctl restart完整重启；第三步用ps -ef确认进程启动时的参数里指向的配置文件路径。最常见的就是同一个应用在不同的部署目录里各有一份配置文件，你改了A目录的，服务实际跑的是B目录的。

5. 如何真正练会Linux：一套可落地的学习路径

看再多的命令讲解，不如亲手敲一遍。我见过不少测试新人，资料收藏了几百页，真到服务器上还是两眼一抹黑。原因很简单：知识没有经过实践转化成肌肉记忆。下面我分享一套自己总结的、可落地的练习路径。

5.1 先在虚拟机或云主机上搭一个练习环境

学习Linux一定要有一个可以随便折腾的环境。我的建议是：在自己的电脑上装一个虚拟机软件，装一个最小化的Linux发行版，或者买一台便宜的云服务器。成本不高，但可以随意操作，不怕弄坏。

练习环境里优先做这几件事：

一是安装常用的中间件。自己动手装MySQL、Redis、Nginx。安装过程能帮你熟悉包管理器、文件目录结构、服务管理命令。装完之后用systemctl管理它们，用netstat查看监听端口，用lsof确认服务进程，一套流程下来，服务管理相关的命令都会了。

二是制造故障再排查。自己故意制造问题，用命令排查。比如把Nginx停掉，然后模拟“无法访问网站”的排查流程；把MySQL的端口改掉，然后用应用连不上数据库的方式排查；写一个脚本往磁盘里塞满垃圾文件，再模拟磁盘满的故障。这样练过几轮，排查经验就沉淀下来了。

5.2 把日常测试工作当成Linux的练习题

在有真实环境的情况下，刻意用Linux命令去替代一些操作习惯。

部署测试包时，不依赖别人帮你部署，自己解压、改配置、启动、看日志，走完全流程。

发现Bug时，先用curl手动复现一遍接口问题，再用grep从日志里找到对应的异常堆栈，把日志片段贴到缺陷单里。

准备测试数据时，优先尝试用命令行的方式去完成，哪怕一开始慢一点，熟练之后效率会非常可观。

查看系统状态时，养成交替使用top、free、df的习惯，让这些命令变成下意识反应。

5.3 建立自己的命令速查手册

不要照搬网上的命令大全，那个太宽泛，你记不住也用不上。我的做法是：建一个自己的文档，按“我平时会遇到的问题”分类记录。比如“服务起不来怎么排查”“磁盘满了怎么清理”“接口连不上怎么验证”。每条记录里写下自己实际用过的命令和当时的结果。这个手册越用越厚，慢慢就变成你自己的最强资料库。

还有一个小技巧：善用history命令查看自己敲过的命令历史，配合!符号可以快速重复执行某条历史命令。比如你之前敲过一个很长的构建命令，!make就可以直接再次执行以make开头的最近一条命令。这些细节操作，用顺手了真的能省出大量时间。

写在最后的一点经验

我带过的测试新人里，成长最快的往往不是基础最好的，而是遇到问题愿意自己动手查的。Linux操作这件事，说难也难，命令多、坑多；说简单也简单，核心就那么几十个命令，反复用、反复练，慢慢就内化成自己的本能反应。

最后分享一个我自己的习惯。每次在测试环境排查完一个棘手问题，我会顺手在工位上记一句话：这个问题是怎么发现的、用了哪些命令、最关键的线索是什么。一年下来翻翻记录，你会发现绝大多数环境问题就那么几类，而你已经积累出自己的一套快速排查路径了。希望这篇内容能帮你在测试工程师这条路上走得更顺，敲命令的时候少一点犹豫，多一点自信。