企业官网建设流程全解析

说实话，我在各种场合给新人讲Linux，遇到最多的问题不是“命令记不住”，而是“不知道学了命令往哪用”。其实Linux的命令行操作，特别是文件操作、文本处理、高效搜索和压缩解压这四块，就是一套完整的日常工作流。你掌握了这几个能力，基本就具备了独立维护一台Linux服务器的基础底气。今天这篇东西，我想从一个常年折腾Linux的人的角度，把这些最常用、也最容易踩坑的操作一次性讲透，思路、命令、参数背后的原因都会讲到，希望能帮你真正把这些工具变成肌肉记忆。 这篇文章适合刚接触Linux、准备转运维或后端开发、以及用了很久Linux却总觉得“只会皮毛”的朋友。我不会去罗列那种“linux常用命令大全”，而是用实际场景带出命令，告诉你每个命令解决什么问题、为什么那样写、有哪些坑必须躲开。内容围绕文件操作、文本处理、高效搜索和压缩工具展开，最后补上系统管理里绕不开的权限、服务、日志与定时任务，尽量做到一篇能直接“抄作业”。

1. 整体思路与内容架构：为什么这四个能力必须一起学

先说个很多人没想明白的问题：文件操作、文本处理、搜索、压缩，这四件事看起来是四个独立技能，实际上在真实运维和开发场景里是密不可分的。你排查一个线上故障，流程往往是：先搜日志文件（搜索），然后从日志里抽关键词（文本处理），发现问题后备份或归档相关目录（压缩），最后把处理脚本或配置放到指定位置（文件操作）。四步环环相扣，缺一个都会让你卡在原地。

我见过不少人，grep、tar、find这些命令单个拿出来都认识，但一遇到真实任务就不知道组合起来怎么用。比如磁盘满了，他要先ls看目录，再手动一层层翻，翻了半天才用du找到大文件。而熟悉这套体系的人一条命令就搞定：du -sh /* 先盘根目录，再用 find /var -type f -size +500M 直接锁目标。差别不在命令数量，在于脑子里有没有把“搜索定位”和“文件操作”串成一条线。

所以这篇内容的架构不是按命令字母排序，而是按任务链条来组织：

• 先讲文件操作，这是所有后续动作的地基；
• 再讲文本处理三剑客 grep、sed、awk，这是处理日志和配置的利器；
• 然后讲搜索能力，从find到ripgrep，覆盖不同场景；
• 接着是打包压缩，讲透tar和各类压缩算法的取舍；
• 最后落到系统管理，把权限、服务、日志、定时任务这些日常巡检必备的东西补齐。

这套顺序我建议新人照着学，不要上来就背awk的几十种写法，先跟着任务走，自然就知道每个命令该什么时候用。等任务链条熟练了，再回头逐个命令深入研究，效率高得多。

还要提醒一句：学习这个事，环境比记忆重要。别只在脑子里过，一定要开个虚拟机或云服务器，一边看文章一边敲命令。Linux命令不敲个十遍八遍，根本谈不上掌握。

2. 文件操作的底层逻辑与高频命令

2.1 从ls和stat开始，真正看懂文件和目录

很多人在Windows时代养成的习惯是“看图标认文件”，到了Linux这招完全失效。Linux里一切皆文件，目录是文件，设备是文件，甚至进程信息也在文件里。所以第一个要建立的观念就是：用信息而不是图标来认识文件。

ls -l 大概是Unix-like系统里最经典的命令，但多数人只会看权限那一列。我建议你把 ls -l 的输出逐字段拆开看：文件类型、权限、硬链接数、属主、属组、大小、最后修改时间、文件名。其中文件类型那一列，- 代表普通文件，d 是目录，l 是软链接，b/c 是块设备或字符设备。这条命令配合 stat 文件路径，你还能看到更详细的inode、块数量、访问时间和变更时间。

我实际干活时还有一个习惯，就是给 ls 加别名。把 ls 默认设置成 ls -lh --color=auto，这样每个文件的大小直接显示成人类可读的K、M、G，目录一眼区分出来。如果你追求更强效果，还可以装 exa 或 eza 来替代 ls，输出里直接显示git状态和文件类型图标，用起来非常爽。

2.2 文件复制、移动与删除，别让rm教你做人

cp、mv、rm 是文件操作的三件套，但这里面的坑比很多人想象的多。

先讲cp。默认的 cp 在复制目录时必须加 -r（递归），不然直接报错“omitting directory”。复制时要保留权限、时间戳、属主之类的元数据，必须用 -p；要保留软链接本身而不是跟随链接复制目标文件，用 -a（等于 -dR --preserve=all）；要增量同步两个目录，最稳妥的其实是 rsync，而不是cp。rsync 的增量传输和断点续传能力是cp完全不具备的，远程用 rsync -avz，本地也能用 rsync -a，比cp放心很多。

mv 相对简单，但有个细节：mv 跨文件系统时本质是“复制+删除”，耗时可能远超预期，而且如果中途断掉，源文件可能还在但目标不完整。移动超大目录时，建议先用 du 估算一下体量，再用 rsync 做迁移，最后确认无误再删原目录。

rm 就不用我多说了，Linux新人的必修课就是被 rm -rf 教育一次。我的经验是：不要在root用户下随意敲 rm -rf，不要写 “rm -rf /路径/*” 这种带通配符的命令，宁可简单粗暴也不要加上 -f 强制标志。生产环境删文件前，先 ls 一下确认路径，再执行删除。更重要的一点是，能 mv 到 /tmp 的，就别急着 rm，给自己留条后路。真有重要文件误删了，立刻停止对所在分区的写入，用 extundelete、xfs_undelete 这类工具还有机会恢复，但一旦有新的写入覆盖了inode，神仙也救不回来。

2.3 快速定位大文件，用du和df组合拳救急

磁盘告警是Linux运维最常遇到的故障，处理流程其实很简单。df -h 看整体使用率，df -i 查inode占用；然后用 du -sh /目录/* 逐级定位，或者直接 find / -xdev -type f -size +1G -exec ls -lh {} ; 一次性找出超过1G的大文件。

这里有个经验要share：根分区满的时候，du -sh 可能会因为某些目录无权限而跳过，所以排查时要加上 sudo，并且注意用 -x 参数避免扫描到挂载的其他分区，不然结果会误导你。比如你把 /data 单独挂了一块盘，根分区满的时候去 du /data 就不解决问题。

还有一类磁盘满的隐藏原因：文件被你删了，但进程还占用着句柄，空间没有释放。这种时候df依然是满的，但你du找不到大文件。解决办法是 lsof | grep deleted，找到还在占用已删除文件的进程，重启或kill掉那个进程，空间才会真正回来。这个坑我踩过好几次，每次都能让新人眼前一亮。

3. 文本处理三板斧：grep、sed、awk的正确打开方式

3.1 grep不只是搜索，它还是日志分析的入门钥匙

grep 是所有人最早接触的文本处理命令，但很多人只会基础用法 grep "关键词" 文件，远远不够。我日常使用频率最高的几个扩展：

• grep -E 打开扩展正则，可以写 | 或、() 分组、+ 量词，比默认的基本正则强很多。
• grep -r 递归搜目录，配合 --include 或 --exclude 指定文件类型，比如 grep -r --include="*.log" "ERROR" /var/log。
• grep -A/-B/-C 显示匹配行后几行、前几行或前后几行，排查报错时上下文信息才是关键。
• grep -o 只输出匹配到的那部分，配合正则做数据提取特别好用。
• grep -l 只列文件名，在海量日志里找哪些文件有问题时用。

grep 处理文本时有个常见问题：遇到二进制文件会提示Binary file matches，如果想彻底忽略二进制文件，加 -I 参数。搜索时不想区分大小写就加 -i，想反选就加 -v。把这些组合起来，你已经能解决80%的日志分析需求，比如搜出所有ERROR行、同时排除健康检查的假报错、输出上下文10行、再统计数量。

3.2 sed做流式编辑，批量替换的杀器

sed 的核心能力是“不会打开文件也能修改文件”，特别适合在shell脚本里做批量替换。最基本的场景：sed -i 's/旧文本/新文本/g' 文件路径。这个命令你必须知道 -i 表示直接修改原文件，不加会只输出不写入；严谨一点还可以用 -i.bak，这样原文件会备份成 文件.bak，防止替换写错救不回来。

sed 的寻址能力也很强。你可以按行号操作：sed -n '20,30p' 文件，只打印20到30行；也可以按模式操作：sed -n '/ERROR/,/END/p' 文件，从匹配到ERROR的那行开始打印到END那一行。生产环境里我经常用 sed 批量修改nginx配置里的端口或PHP版本号，一条命令扫完几十个站点配置，比手动vim一个个改效率高一个量级。

sed 还有个高级用法是把多行合并：sed ':a;N;$!ba;s/\n/ /g' 文件，把整个文件合成一行。这个在分析跨行日志时特别有用，比如错误堆栈通常占好几行，你直接按日志关键字提取会漏掉堆栈尾部，先用这招合并再grep，就能完整抓到。

3.3 awk按列处理，统计类需求的终极方案

awk 的命令设计得很有智慧：把每一行按分隔符拆成字段，然后按你给的模式-动作规则来处理。最常见的用法是 awk -F ':' '{print $1}' /etc/passwd，按冒号拆分，打印第一列用户名。日志分析里awk几乎是统计利器，比如统计nginx日志里访问量最大的IP：

awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -10

这条命令的意思很简单：取出每行第一个字段（IP），排序后统计重复次数，再按次数倒序排，取前10。你没看错，一行命令就把“谁在疯狂请求我的服务”查出来了。

awk 还能做条件筛选，比如找出磁盘占用超过30%的分区：df -h | awk 'NR>1 {if ($5+0 > 30) print $0}'，这里的 $5+0 是把百分比字符串转成数字再比较，是避免踩坑的关键写法。awk内置的 BEGIN、END 块也能用来做合计，比如统计一个文件里所有数字的总和：awk '{sum+=$1} END {print sum}' 文件。做报表、做监控数据汇总，awk都是我最先掏出来的工具。

3.4 管道和重定向：让命令协同工作

说文本处理就不能不提管道，| 这个符号看似简单，它却是Unix哲学的精髓：每个命令只做一件事，组合起来做大事。我在上面那条 awk|sort|uniq|sort|head 的链子里，5个命令各干一件小事，组合后等于一个完整的统计查询。这就是shell pipeline的威力。

重定向同样是基础中的基础。> 是覆盖写，>> 是追加写，2> 是重定向错误输出，>& 是把标准输出和错误输出合并。我在写定时任务脚本时经常这么用：脚本 执行 >> /var/log/cron.log 2>&1，把所有输出都落到日志文件里，方便事后排查。新手最容易犯的错是分不清 > 和 >>，写覆盖了原本想追加的日志，结果半小时后才发现日志只留了最后一条；所以默认情况下我习惯写 >>，明确要清空旧文件时才用 >。

4. 高效搜索的进阶组合：找文件、找内容、找线索

4.1 find的隐藏实力：按时间、大小、权限精细定位

find 在很多人印象里只是“找文件名”，其实它的筛选条件远不止这些。按时间找是排查问题的利器：find /opt -mtime -7 文件，找最近7天内改过的文件；排查日志轮转是否正常，可以 find /var/log -newermt "2024-01-01" ! -newermt "2024-02-01" 找特定时间范围的文件。按大小找也常用：find / -size +1G 找大文件，或者 find / -size -10M 找小文件。

还有一类需求是找权限异常的文件：find / -perm -002 找其他用户可写的文件，这在安全排查里很有价值。find 的 -exec 参数能把找到的文件交给后续命令处理，注意结尾的 {} ; 这个固定写法，意思是把查到的每个文件名替换到 {} 位置，而且支持批量操作：find /tmp -type f -name ".log" -exec rm {} ;。如果你觉得 -exec 效率不够高，可以配合 xargs：find /tmp -type f -name ".log" -print0 | xargs -0 rm -f，-print0 和 -0 配对，是为了处理文件名里有空格的情况，这个细节很多人不知道。

4.2 locate、which、type：不同场景用不同的搜索工具

find 功能全面但速度慢，因为它每次都是实时扫描。如果只是想按文件名快速定位，系统有 locate 命令，它依赖预建的数据库，秒出结果，刚创建的文件可能查不到，记得先 updatedb 更新库。大多数发行版的mlocate或plocate包都自带这个机制。

找可执行程序用 which，它按PATH变量依次查找，返回第一个匹配的路径；type 比 which 更全，它能区分命令是内建命令、外部命令、别名还是函数，这对排查“为什么我输这个命令行为不一样”特别有帮助。我在现场排查脚本问题时，常发现用户改过别名或函数名，导致执行结果和预期差很远，这时一条 type 命令就让真相大白。

4.3 全书搜索内容的正确姿势：从grep -r到ripgrep

grep -r 虽然能全目录搜内容，但遇到大项目时性能很拉胯，而且把隐藏目录、二进制文件、.git目录都扫一遍，噪音太大。我现在的个人偏好是：能用 ripgrep（rg）就不用 grep -r。rg 默认就是递归搜索，自动忽略.gitignore里的文件和二进制文件，支持并行搜索，在几GB的代码仓库里搜索关键词几乎是秒出。它的语法和grep保持兼容，比如 rg "pattern" 目录。

如果你还在用老派方法找代码里的关键字，我建议尽快把 rg 装上，用一次就知道差距有多大。拿实际体验举例，一个几十万行代码的旧项目，grep -r 找“TODO”要等好几秒，rg 一闪就出结果，还能显示匹配的行号和上下文，配合 -l 只看文件名，效率不是同一个量级。

4.4 正则表达式的实用入门，别被“.*”吓退

搜索进阶绕不开正则。我教人时经常说：正则就四类字符。字面字符匹配自己，元字符有特殊含义，字符类用方括号 [abc] 表示匹配任意一个，分组用圆括号 () 表示整体。最常用的元字符：. 匹配任意单个字符，* 表示前一个字符出现0次或多次，+ 表示1次或多次，? 表示0次或1次，^ 匹配行首，$ 匹配行尾。

进阶一点，{n,m} 表示重复次数，比如 [0-9]{1,3} 匹配一到三位数字；\d 匹配数字，\w 匹配字母数字下划线。实操里最有价值的正则案例我认为是提取IP：grep -oE "([0-9]{1,3}.){3}[0-9]{1,3}" 文件，这个正则把所有IPv4地址都抓出来。正则这东西光看书没有用，就是多练，你用它提取几回数据、做过几次日志清洗，自然就熟了。

5. 打包压缩与解压的实战避坑

5.1 tar命令拆解：打包和压缩是两件事

很多新人以为tar就是压缩，其实tar的本职是打包，把多个文件合成一个档案文件，压缩是它调用外部压缩工具的结果。tar 参数里最经典的是 tar -czvf 文件名.tar.gz 目录。这五个字母的含义：c 创建档案，z 用gzip压缩，v 显示过程，f 指定文件名。v在实际脚本里不建议加，不利于日志排查。

对应地，解压命令是 tar -xzvf 文件名.tar.gz。这里x是解包，其余参数和打包一致。但有件事必须提醒：很多人以为解压不需要指定 -z/-j/-J，其实tar能自动检测压缩格式，新版tar里 xvf 就能解gz、bz2、xz格式，加上 z/j/J 反而有可能在特定环境卡住。不过兼容起见，多数人还是习惯把对应参数写完整。

tar打包时还有个细节：默认会保存路径信息。你用 tar -czf /tmp/backup.tar.gz /home/user 打包，解包时会还原成 /home/user 目录，这是预期行为；如果想解压到别的地方，先 cd 到目标目录再加 -xzf。打包时想把路径剥掉，可以加 -C 先切换目录：tar -czf /tmp/backup.tar.gz -C /home/user .，这个点号代表当前目录下所有内容。

5.2 gzip、bzip2、xz，压缩率与速度的真实取舍

tar 本身不压缩，压缩靠外部程序，常见三种：gzip、bzip2、xz。三者的核心区别在压缩率、压缩速度和CPU占用。gzip速度最快，压缩后文件也最大，日常归档日志用gzip最合适；bzip2压缩率中等，速度偏慢，现在用得越来越少；xz压缩率最高，经常能把纯文本日志压到原体积的十分之一以下，但压缩时CPU占用极高，极大文件不太建议用xz。

下面这张对比表可以帮你快速决策：

除了这两个，还有一个 zstd 压缩工具，压缩率接近xz，但速度能比xz快一个数量级，而且支持多线程。新一点的tar版本已经支持 --zstd 参数，如果你处理的数据量很大，强烈建议试一下：tar --zstd -cf archive.tar.zst 目录。

5.3 zip与unzip：和Windows互通的标准

Linux上遇到zip文件是家常便饭，毕竟和同事、客户交换文件最常见的就是zip格式。zip命令打包目录要加 -r：zip -r archive.zip 目录。解压用 unzip，最常用的参数：unzip archive.zip 解压到当前目录，unzip archive.zip -d 目标目录，unzip -l archive.zip 先看看压缩包里面有什么再决定是否解压。

还有一个冷门但是实用的技巧：不要用unzip解压带中文文件名的zip包时不加处理，很多zip包是Windows下压缩的，中文文件名编码是GBK，在纯UTF-8的Linux环境下解压出来会乱码。解决办法是装 unar 工具，它自动识别编码，或者用 unzip -O GBK 强制指定编码。这个问题做运维交接时很常见，常被归为“环境问题”然后不当回事，其实一条参数就能解决。

5.4 解压文件乱码、损坏提示，这些坑怎么排查

解压异常的场景我整理过几种，新手尤其容易栽在这里：

• 解压提示 cannot open: No such file or directory：多半是压缩包路径写错或文件名含特殊字符，先用 ls -b 看真实的文件名再操作。
• tar: This does not look like a tar archive：一般是文件格式不对，可能文件是zip但你用tar解，或者文件没下载完。先 file 文件名，看一眼真实类型再说。
• 文件名乱码：纯zip包常见，用 unar 或 unzip -O 解决。
• 解压后文件权限不对：tar包默认保留权限信息，解压出来的目录权限可能是包的拥有者设定的。如果你是普通用户解压root打包的文件，可能会因无权写入而失败，先用 -O 选项强制解压到当前目录，或改用 sudo 解压后 chown 改属主。
• 磁盘空间不足导致解压失败：大压缩包解压前一定先 df -h 确认空间。xz压缩率很高的包，解压后体积可能膨胀十几倍，务必留足余量。

6. 系统管理的日常巡检与权限控制

6.1 用户与组的管理，创建、修改、删除一条龙

Linux系统管理绕不开用户管理，几十人用同一台机器时尤其重要。useradd 创建用户时，我建议加上 -m -s /bin/bash 参数，-m 是自动创建家目录，-s 指定登录shell，不加的话可能登不进系统或没有任何初始环境。用户建好之后立刻设密码：passwd 用户名，这一条命令要求你输入两遍密码。

用户组的管理也常被忽略。用户能访问哪些文件，取决于它的用户主组和附加组。usermod -aG docker 用户名 这条命令是把用户加进docker组，注意必须带 -a（append），不带的话会把用户从其他组清空，后果很严重。删用户用 userdel -r 用户名，-r 是把家目录和邮件文件一并删除；如果你只是想停用某个账号，用 usermod -L 用户名 锁定比删除更稳妥。

6.2 权限的本质：读、写、执行的数字表达

Linux权限模型说穿了就三组rwx：属主权限、属组权限、其他人权限。r=4、w=2、x=1，组合相加就得到常见数字。755 是属主可读写执行、组可读执行、其他人可读执行，这是目录的默认理想权限；644 是文件常用权限，属主读写，其他人只读。要给脚本加执行权限：chmod +x script.sh，要递归改目录：chmod -R 755 目录。

但我要多说一句，现在的安全意识下，chmod 777 应该尽量避免。它意味着任何人都能改你的文件，一个脚本被恶意篡改后，你在不知情情况下执行，后果不堪设想。处理共享写需求时，更合适的做法是把相关用户加进同一组，然后设置chmod 775 或 2770 这样的权限，配合setgid位，让新创建文件自动继承组属主。这个细节在很多运维面试里都会出现，但实际工作中照样一堆人在用777偷懒。

6.3 systemctl管理服务和journalctl查日志

现代Linux发行版几乎都采用 systemd 管理服务，systemctl 命令是日常必须掌握的。常见操作：systemctl start/stop/restart 服务名，systemctl enable 服务名 设置开机自启，systemctl status 服务名 查看服务状态。服务状态里的 active (running)、active (exited)、failed 分别代表运行中、一次性任务成功退出、启动失败。

日志排查用 journalctl。journalctl -u 服务名 查看指定服务的全部日志，journalctl -u nginx -f 实时跟随最新日志，journalctl --since "1 hour ago" 只看最近一小时的日志。配合grep还能快速过滤：journalctl -u mysqld --since today | grep -i error。每次排查故障，我基本都是 systemctl status 看状态，然后 journalctl 拉日志，最快五分钟定位问题。不过要注意journald日志本身也占磁盘空间，日志量大时要在 /etc/systemd/journald.conf 里设置 SystemMaxUse 限制，不然根分区早晚被日志填满。

6.4 定时任务crontab，别再半夜爬起来手动跑脚本

crontab -e 编辑当前用户的定时任务，格式是“分 时 日 月 周 命令”。比如每天凌晨3点备份数据库：

0 3 * * * /opt/scripts/backup.sh >> /var/log/backup.log 2>&1

五个星号的位置分别代表分钟(0-59)、小时(0-23)、日(1-31)、月(1-12)、周(0-7)，全星号就是每分每秒都执行。常见的坑是环境变量问题：cron执行脚本时的环境和你手动终端不同，PATH都不一样，所以脚本里要写绝对路径，必要时在脚本开头 export PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin。另外crontab里必须把输出重定向到日志文件，否则脚本大量输出会塞爆系统邮件，而且你根本看不到执行结果。我常年习惯是写一个通用模板，把所有cron任务都带上时间戳日志：

* * * * * /usr/bin/python3 /opt/scripts/task.py >> /var/log/task_$(date +\%Y\%m\%d).log 2>&1

注意百分号在crontab里有特殊含义，要用反斜杠转义，这也是新手容易踩的坑。

7. 常见问题与故障排查技巧实录

7.1 命令找不到、权限不够、执行格式错误，这些报错一表看懂

随手整理一张高频报错速查表，都是我实际工作中碰到的：

7.2 定位故障的通用方法论：先看状态，再看日志，再动手

遇到任何疑似系统问题，我的排查顺序几乎是固定的。第一步看现象，用几个只读命令收集事实：uptime 看负载，free -h 看内存，df -h 看磁盘，ps aux 看进程。这里有个教训，很多新手一上来就重启服务，重启完问题消失了但根因没找到，过几天又复发，所以要耐得住性子先把数据看全。

第二步查日志。系统级问题去 /var/log/messages 或 /var/log/syslog，服务级问题用 journalctl -u 服务名，应用自带的日志目录也要扫一眼。看日志不要只用grep抓关键字，把出现关键字前后30行都看一遍，上下文才告诉你完整故事。第三步才根据定位结果干活，改配置、清磁盘、调参数，每一步都做好记录，方便回溯。

7.3 两个我踩过好几次的典型坑：误删文件与日志爆盘

先讲误删。我刚开始管服务器时，root用户下一条 rm -rf /opt/app/temp/* 的命令，本想清理临时目录，结果因为路径里多了个空格或者写错字母，把 /opt/app 整个清掉了。那天晚上我用了整整四个小时尝试恢复文件，好在后来发现还有一份快照，不然就是生产事故了。从此我给自己立下规矩：root下禁止用rm删除目录，一律用 mv 到 /tmp 下观察几天，确认不需要再清空 /tmp；若确需rm，先 echo 列出要删的路径，确认三次再执行。

再说日志爆盘。这还是发生在接管一台跑了好几年的老服务器时，某天监控告警根分区使用率97%，我du排查发现 /var/log/journal 占了三个多G，但系统服务运行正常。查资料才知道journald默认没有限制日志总大小，会一直涨到占满磁盘。解决办法是在 /etc/systemd/journald.conf 里设置 SystemMaxUse=500M，然后 systemctl restart systemd-journald。从那以后，我接手的每一台机器，第一件事就是检查journald配置，这条经验帮我避掉了后面好几次磁盘告警。

写在最后的一个小经验

如果你现在正处于“命令记了不少，但实际用起来还是卡壳”的阶段，我建议你先别急着继续背新命令，而是打开一台真实服务器，给自己布置几个具体任务。比如：把一个/var/log下超过100M的日志文件压缩归档；统计nginx日志里访问量前十的IP；写一条crontab每天凌晨备份指定目录并保留最近7天的备份。这些任务不复杂，但都要你把文件操作、文本处理、搜索、压缩和系统管理串起来用。等你发现这些任务已经能一气呵成搞定，那种熟练度才算真正长在了自己身上。Linux命令行的学习没有捷径，唯一的捷径就是多敲、多错、多总结，这一点我到现在也还在践行。