1. 为什么全栈工程师的第一课永远是Linux指令
很多人刚入行的时候会有一个误区，觉得全栈工程师就是前端写写页面、后端调调接口，把框架玩溜了就算入门了。我带过不少新人，也跟不少同行交流过，发现一个很普遍的现象：大家花大量时间研究框架源码、设计模式、分布式架构，但真正到了服务器上，连一个日志文件都定位不到，服务挂了不知道怎么排查，部署脚本写出来跑不通只能干瞪眼。这些问题的根源，往往不在框架层面，而在于对Linux系统常用指令的掌握不够扎实。
Linux指令这个东西，说起来好像很简单，不就是ls、cd、cat这些吗？但真正在工作中用起来，你会发现它的深度远超想象。同样一个日志分析需求，有人用grep加awk三行命令搞定，有人打开文件一行行翻半小时还没找到关键信息。同样一个磁盘满了的告警，有人五分钟定位到大文件并清理完毕，有人折腾一上午还在问“哪个目录占的空间最多”。差距就在指令的熟练度和组合能力上。
这篇文章面向的是正在走全栈路线、或者准备往全栈方向发展的工程师。不管你现在是前端想往后端扩展，还是后端想补全运维部署能力，Linux常用指令都是绕不过去的基本功。我会从实际工作场景出发，把最常用的指令按功能分类拆解清楚，每个指令不仅告诉你“怎么用”，还会解释“为什么这么用”、“什么场景下用”、“有哪些坑要避开”。文章里涉及的所有操作都是我在实际项目和日常运维中反复验证过的，你可以直接抄作业。
需要提前说明的是，这篇文章不会试图覆盖Linux指令的全部内容，那样写出来就是一本手册了。我聚焦的是全栈工程师在日常开发、部署、排查问题中最常打交道的那些指令，把它们讲透、讲深，让你看完就能上手用。如果你已经有一定基础，可以重点看每个指令下面的“实操心得”和“常见坑”部分，那些是文档里不会写的经验。
2. 文件与目录操作：每天都要打交道的核心指令
2.1 ls与cd：看似简单，用好了效率翻倍
ls和cd大概是所有人学Linux时最先接触的两个指令，但恰恰是这两个最基础的指令，很多人用了几年都没用明白。先说说ls，大部分人最常用的就是直接敲ls看当前目录有什么文件。但实际工作中，我几乎不会单独用ls，而是习惯性地带上几个参数。
ls -alh是我个人最常用的组合。-a显示隐藏文件，这个很重要，很多配置文件比如.env、.gitignore都是隐藏的，不加-a根本看不到。-l用长格式显示，能看到权限、所有者、文件大小、修改时间这些关键信息。-h把文件大小变成人类可读的格式，比如4.0K、1.2M，而不是一串数字让你自己换算。这三个参数组合在一起，基本上一次就能把目录里的情况看个大概。
还有一个很实用的参数是-t，按修改时间排序，最新的文件排在最前面。当你刚部署完一个服务，想确认哪个文件是刚生成的，ls -alht就特别管用。反过来-tr是按时间倒序，最旧的排前面，找历史文件的时候用得上。
cd指令本身没什么好说的，但有几个快捷方式值得记住。cd -可以回到上一个所在的目录，这个在兩個目录之间频繁切换的时候特别方便。cd ~回到用户主目录，cd ..回到上级目录，这些大家都知道。但cd后面直接跟一个不存在的路径时，不同shell的行为可能不一样，有些会报错停在原地，有些会跳到最近匹配的目录，这个要注意一下自己用的shell类型。
实操心得：我习惯在
.bashrc或者.zshrc里配置alias ll='ls -alht'，这样每次敲ll就能看到按时间排序的详细列表，省去每次打一长串参数的麻烦。类似的别名可以按自己的习惯配置，能省不少时间。
2.2 find与locate：快速定位文件的两种思路
文件找不到了怎么办？这是日常开发中高频出现的问题。find和locate是两个最常用的文件查找指令，但它们的底层逻辑完全不同，适用的场景也不一样。
find是实时遍历目录树来查找，所以它总能找到最新的文件状态，但速度相对较慢，尤其是在大目录下。基本用法是find 路径 -name "文件名"，比如find /var/log -name "*.log"就是查找/var/log下所有.log结尾的文件。find的强大之处在于它支持非常多的过滤条件，可以按文件大小、修改时间、权限、类型等组合查找。
举几个我实际工作中常用的例子。查找最近24小时内修改过的文件：find /app -mtime -1 -type f。查找大于100M的文件：find / -size +100M -type f。查找所有空目录：find /data -type d -empty。这些组合在实际排查问题时非常管用，比如磁盘满了要找大文件，或者清理项目里的空目录。
locate则是基于预先建立的文件索引数据库来查找，速度极快，几乎瞬间返回结果。但它的缺点是索引不是实时更新的，新建的文件可能搜不到，需要先执行updatedb更新索引。所以locate适合用来快速定位那些已经存在一段时间的文件，比如系统配置文件、已安装的软件路径等。我通常用locate来快速找某个命令的安装位置，比如locate nginx.conf，比find / -name nginx.conf快太多了。
注意：
find在根目录下执行时最好加上-maxdepth限制搜索深度，或者用2>/dev/null屏蔽权限报错信息，否则会刷屏一大堆“Permission denied”，既影响阅读又浪费时间。
2.3 cp、mv、rm：文件操作的三个基本动作
cp、mv、rm这三个指令看起来简单，但用不好造成的后果可能是灾难性的。我先说rm，因为这是最容易出事的指令。rm -rf删库跑路的段子大家都听过，但实际工作中真的有人因为路径写错或者变量为空导致误删。我的习惯是，执行rm -rf之前一定先ls一下目标路径，确认没问题再删。另外，在脚本里用rm的时候，变量一定要加引号并且做非空判断，比如rm -rf "${TARGET_DIR:?}"，这样如果变量为空，脚本会直接报错退出而不是删掉根目录。
cp的常用参数是-r递归复制目录，-p保留文件属性（权限、时间戳等），-a相当于-rp的组合。复制大文件的时候可以加-v看进度，虽然输出有点多，但至少知道复制到哪了。跨文件系统复制大量小文件时，rsync通常比cp更合适，因为它支持断点续传和增量同步，不过这是另一个话题了。
mv除了移动文件，还有一个很常用的功能是重命名。mv old_name new_name就是重命名操作。但要注意，如果new_name已经存在，mv会直接覆盖，不会有任何提示。所以重命名之前最好确认一下目标文件是否存在，或者用mv -i开启交互模式，覆盖前会询问。
2.4 权限管理：chmod与chown的正确打开方式
Linux的权限系统是很多新人的噩梦，但其实理解了“用户-组-其他”这个三层模型之后，就没那么复杂了。chmod用来修改文件权限，chown用来修改文件所有者和所属组。
权限的数字表示法大家应该都见过，755、644这些。简单回顾一下：r是4，w是2，x是1，三个数字分别对应所有者、所属组、其他用户的权限之和。755就是所有者有读写执行权限（4+2+1=7），组用户和其他用户有读和执行权限（4+1=5）。644就是所有者读写（4+2=6），组和其他只读（4）。
但实际工作中，我更推荐用符号模式来修改权限，因为更直观。比如chmod u+x script.sh给所有者加上执行权限，chmod go-w file.txt去掉组和其他用户的写权限。符号模式的好处是你不需要计算数字，而且可以精确控制只修改某一类用户的权限，不会影响其他权限位。
chown最常用的场景是部署应用时，把文件的所有者改成运行服务的用户。比如chown -R appuser:appgroup /app，把/app目录及其下所有文件的所有者和组都改成appuser和appgroup。这里-R是递归的意思，改目录权限时几乎都要加。
实操心得：修改权限时遵循“最小权限原则”，能给644就不给755，能给755就不给777。特别是Web目录，千万不要图省事直接
chmod -R 777，这等于把整个目录对所有人开放，安全隐患极大。正确的做法是目录给755，文件给644，需要写入的特定目录单独给写权限。
3. 文本处理三剑客：grep、sed、awk的实战用法
3.1 grep：日志排查的第一把利器
grep是我在日常工作中使用频率最高的指令，没有之一。看日志、找配置、过滤进程，到处都有它的身影。基本用法是grep "关键词" 文件名，但真正好用的是它的各种参数组合。
grep -n显示行号，这个在定位问题的时候特别重要，知道行号才能快速跳到对应位置。grep -i忽略大小写，搜索的时候不用纠结大小写问题。grep -r递归搜索目录，在项目里找某个函数调用或者配置项的时候很方便。grep -v是反向匹配，排除包含某个关键词的行，比如grep -v "DEBUG" app.log就是排除所有包含DEBUG的行。
grep -c统计匹配行数，grep -l只显示包含匹配内容的文件名，grep -w匹配整个单词而不是部分匹配。这些参数可以组合使用，比如grep -rn "TODO" --include="*.py"就是在所有Python文件中递归搜索TODO并显示行号。
还有一个很实用的技巧是结合管道使用。比如查看某个进程是否在运行：ps aux | grep nginx。但这里有个坑，grep本身也会出现在结果里，因为ps aux的输出包含了grep nginx这个进程。解决办法是用grep -v grep排除掉，或者用更优雅的写法ps aux | grep "[n]ginx"，利用正则表达式的字符类让grep不匹配自己。
注意：
grep默认使用基本正则表达式，如果要使用更强大的扩展正则，需要加-E参数或者直接用egrep。比如grep -E "error|fail|exception" app.log可以同时匹配多个关键词，比写多个grep管道要简洁得多。
3.2 sed：流式编辑器的精准替换
sed最常用的功能就是替换文本，格式是sed 's/原内容/新内容/'。但默认情况下它只替换每行第一个匹配项，要替换所有匹配需要加g标志：sed 's/old/new/g'。这个g就是global的意思，不加的话只替换第一个。
sed -i是直接修改文件内容，这个参数要慎用，因为它是原地修改，改错了没法撤销。我的习惯是先用不带-i的命令预览一下替换结果，确认没问题再加-i执行。如果确实需要直接修改，可以先备份：sed -i.bak 's/old/new/g' file.txt，这样会生成一个file.txt.bak的备份文件。
sed还可以按行号操作，比如sed -n '10,20p' file.txt只打印第10到20行，相当于head -20 file.txt | tail -11，但更简洁。sed '5d' file.txt删除第5行，sed '/pattern/d'删除包含特定模式的行。这些在快速处理配置文件的时候特别管用。
实际工作中一个很常见的场景是批量修改配置文件。比如把多个服务器配置文件里的某个IP地址统一替换掉：sed -i 's/192.168.1.100/192.168.1.200/g' *.conf。这种操作比一个个打开文件手动改要快得多，而且不容易出错。
3.3 awk：按列处理文本的瑞士军刀
awk是三个工具里功能最强大的，它本质上是一门完整的文本处理编程语言。但对于全栈工程师来说，不需要掌握它的全部功能，只要会用最常用的按列处理就够了。
awk '{print $1}'打印第一列，$2是第二列，以此类推。$0表示整行。默认情况下awk以空格或Tab分隔列，但可以用-F指定分隔符。比如处理CSV文件：awk -F',' '{print $2}' data.csv就是打印CSV的第二列。
awk还支持条件过滤，格式是awk '条件 {动作}'。比如awk '$3 > 100 {print $1, $3}'就是打印第三列大于100的行的第一列和第三列。这个在分析日志的时候特别有用，比如统计响应时间超过1秒的请求：awk '$NF > 1 {print $0}' access.log。
awk内置了很多有用的变量，NR是当前行号，NF是当前行的字段数，FS是字段分隔符。比如awk 'NR > 1'跳过第一行（通常用于跳过CSV表头），awk '{print NF}'打印每行的字段数。这些变量在写复杂一点的文本处理逻辑时非常方便。
实操心得：
grep、sed、awk这三个工具经常组合使用，形成强大的文本处理管道。比如分析Nginx访问日志，找出访问量最大的前10个IP：awk '{print $1}' access.log | sort | uniq -c | sort -rn | head -10。这一条命令就完成了提取IP、排序、去重计数、按次数倒序排列、取前10的全部操作。类似的组合在实际工作中会反复用到，建议多练几遍形成肌肉记忆。
4. 系统监控与进程管理：让服务稳定运行的关键指令
4.1 top与htop：实时掌握系统资源状态
top是Linux系统自带的实时监控工具，能显示CPU、内存、进程等关键信息。但说实话，top的界面对于新手来说不太友好，信息密密麻麻的，而且交互操作也不够直观。所以我更推荐用htop，它是top的增强版，界面更清晰，支持鼠标操作，还能横向滚动查看完整的命令行参数。
htop最上面是CPU和内存的使用率条，用不同颜色区分用户空间、系统空间、nice值等。下面是进程列表，默认按CPU使用率排序。你可以按F6选择排序字段，按F4搜索进程，按F9发送信号给进程。这些快捷键用熟了之后，排查性能问题会快很多。
如果服务器上没有htop，用top也完全可以。top里面按P按CPU排序，按M按内存排序，按1展开显示每个CPU核心的使用率。top -b -n 1可以以批处理模式输出一次快照，适合在脚本里收集系统状态。
看top的时候要重点关注几个指标：load average（系统负载）、%CPU（CPU使用率）、%MEM（内存使用率）、RES（进程实际占用的物理内存）。load average有三个值，分别代表1分钟、5分钟、15分钟的平均负载。一般来说，这个值不应该超过CPU核心数，超过了就说明系统有压力了。
4.2 ps与kill：进程查看与终止
ps是查看进程状态的基本指令，但它的参数风格有点混乱，有BSD风格（不加横线）和UNIX风格（加横线）两种。我常用的组合是ps aux和ps -ef，两者功能差不多，看个人习惯。ps aux的输出包括用户、PID、CPU占用、内存占用、启动时间、命令等。
ps aux | grep 关键词是最常用的进程查找方式，比如ps aux | grep java找所有Java进程。但前面说过，grep本身会出现在结果里，所以更准确的写法是ps aux | grep "[j]ava"。
找到进程之后，如果需要终止它，就用kill指令。kill PID发送TERM信号（信号编号15），这是优雅终止，进程有机会做一些清理工作。如果进程不响应TERM信号，可以用kill -9 PID发送KILL信号强制终止。但-9是最后的手段，因为强制终止可能导致数据丢失或者资源未释放。
还有一个很实用的指令是pkill，可以按进程名直接终止，不用先查PID。比如pkill -f "python app.py"终止所有命令行匹配这个模式的进程。-f表示匹配完整的命令行，不加的话只匹配进程名。
注意：在生产环境执行
kill之前，一定要确认PID对应的确实是你要终止的进程。我见过有人把kill的PID写错，结果把数据库进程给杀了。稳妥的做法是先用ps -p PID确认一下这个PID是什么进程，确认无误再执行kill。
4.3 df与du：磁盘空间排查的标准流程
磁盘满了是运维中最常见的问题之一，df和du是排查这个问题的两个核心指令。df -h查看各个挂载点的磁盘使用情况，-h让容量以人类可读的格式显示。输出里要重点关注Use%这一列，超过80%就要留意了，超过90%就要赶紧处理。
但df只能告诉你哪个分区满了，不能告诉你具体是哪个目录或文件占的空间。这时候就需要du出场了。du -sh /path查看指定目录的总大小，du -sh /*查看根目录下每个一级目录的大小。找到大目录之后再逐层深入，直到定位到具体的大文件。
du的常用参数还有-a显示所有文件而不仅仅是目录，--max-depth=1限制递归深度。比如du -h --max-depth=1 /var就是查看/var下每个子目录的大小，不继续往下递归。这个在快速定位大目录的时候很有用。
一个很常见的坑是，删除了文件但磁盘空间没有释放。这是因为还有进程持有这个文件的句柄。解决办法是找到持有该文件的进程并重启它，或者用lsof | grep deleted找到被删除但仍在使用的文件。这个坑我在实际工作中遇到过好几次，第一次遇到的时候完全懵了，明明du看目录大小已经降下来了，但df显示磁盘还是满的，后来才知道是进程句柄的问题。
4.4 网络排查：netstat、ss与curl
网络问题排查是全栈工程师必须掌握的技能。netstat和ss都是查看网络连接状态的工具，ss是netstat的现代替代品，速度更快，输出也更清晰。ss -tulnp是我最常用的组合：-t显示TCP连接，-u显示UDP连接，-l只显示监听状态的端口，-n不解析服务名（直接显示端口号），-p显示对应的进程。
这个命令在排查“端口被占用”或者“服务没起来”的时候特别管用。比如你启动了一个Web服务，但访问不了，先用ss -tulnp | grep 8080看看8080端口有没有在监听。如果没有，说明服务没启动成功；如果有但访问不了，可能是防火墙的问题。
curl是测试HTTP接口的万能工具。curl -I URL只获取响应头，用来快速检查服务是否可达。curl -X POST -H "Content-Type: application/json" -d '{"key":"value"}' URL发送POST请求。curl -o file.zip URL下载文件。curl -v URL显示详细的请求和响应过程，排查接口问题的时候特别有用。
实操心得：排查网络问题时，我通常按照“从外到内”的顺序：先用
curl或ping确认网络是否通，再用ss确认端口是否监听，然后看服务日志确认请求是否到达，最后检查应用配置。这个顺序能帮你快速缩小问题范围，避免盲目猜测。
5. 压缩打包与远程传输：部署环节的必备技能
5.1 tar与zip：打包压缩的两种主流方案
tar是Linux下最常用的打包工具，它本身只负责打包，压缩是通过调用其他压缩工具实现的。最常用的组合是tar -czvf打包成gzip格式，tar -xzvf解压gzip格式。参数含义：-c创建归档，-x解压归档，-z用gzip压缩/解压，-v显示过程，-f指定文件名。
打包：tar -czvf backup.tar.gz /app/data，把/app/data目录打包成backup.tar.gz。解压：tar -xzvf backup.tar.gz -C /target/dir，解压到指定目录。-C参数指定解压的目标目录，不加的话解压到当前目录。
tar还支持排除特定文件，用--exclude参数。比如打包项目但排除node_modules和.git目录：tar -czvf project.tar.gz --exclude='node_modules' --exclude='.git' /app/project。这个在部署的时候特别有用，可以避免把不必要的文件打包进去。
zip和unzip是另一种常见的压缩格式，在跨平台场景下更常用，因为Windows原生支持zip格式。zip -r archive.zip /path/to/dir递归压缩目录，unzip archive.zip -d /target/dir解压到指定目录。zip的优点是可以在不解压的情况下查看内容：unzip -l archive.zip。
5.2 scp与rsync：文件传输的两种选择
scp是基于SSH的文件传输工具，用法很简单：scp file.txt user@host:/remote/path上传文件，scp user@host:/remote/path/file.txt .下载文件。传目录加-r参数。scp的优点是简单直接，几乎所有Linux系统都自带。
但scp的缺点也很明显：不支持断点续传，传输大文件时如果网络中断就得从头再来；不支持增量同步，每次都是全量传输。所以对于大文件或者需要频繁同步的场景，rsync是更好的选择。
rsync的核心优势是增量传输，它只传输源和目标之间有差异的部分。基本用法：rsync -avz /local/path/ user@host:/remote/path/。参数含义：-a归档模式（保留权限、时间戳等），-v显示详细过程，-z传输时压缩。注意源路径末尾的斜杠，/local/path/表示同步目录内容，/local/path表示同步目录本身。
rsync还有一个很实用的参数是--delete，删除目标目录中源目录没有的文件，保持两边完全一致。这个在部署静态资源的时候很有用，但用的时候要小心，确保源目录是正确的，否则可能误删目标目录的文件。
注意：
rsync的--delete参数一定要配合--dry-run先预览一下，确认要删除的文件列表没问题再实际执行。我见过有人因为源目录路径写错，导致--delete把目标目录的重要文件全删了。--dry-run会模拟执行并输出将要进行的操作，但不实际执行，是一个很好的安全检查手段。
5.3 远程连接与文件编辑：ssh与vim基础
ssh是远程登录Linux服务器的标准工具，ssh user@host就能登录到远程服务器。ssh -p 端口号 user@host指定非默认端口。ssh -i 密钥文件 user@host使用密钥认证。这些基本用法大家应该都熟悉。
但ssh还有一个很实用的功能是端口转发，可以把远程服务器的端口映射到本地。比如远程服务器上有一个只监听本地回环地址的数据库服务，你可以用ssh -L 3306:localhost:3306 user@host把远程的3306端口映射到本地的3306端口，然后本地就能直接连接了。这个在开发调试的时候特别方便。
登录到远程服务器之后，编辑文件最常用的工具就是vim。vim的学习曲线比较陡，但掌握基本操作之后效率很高。至少需要掌握：i进入插入模式，Esc退出插入模式，:w保存，:q退出，:wq保存并退出，:q!不保存强制退出。搜索用/关键词，按n跳到下一个匹配。跳转到指定行用:行号。
vim的配置也很重要，默认配置用起来不太顺手。我通常会在~/.vimrc里配置行号显示、自动缩进、搜索高亮等。这些配置能显著提升编辑效率，具体配置内容可以根据自己的习惯调整。
6. 常见问题与排查技巧实录
6.1 指令执行报错“Permission denied”怎么处理
这是最常见的报错之一，原因通常有三种：一是当前用户没有执行该操作的权限，二是文件本身没有执行权限，三是SELinux或AppArmor等安全模块的限制。
排查思路：先用ls -l查看文件权限，确认当前用户是否有相应的读/写/执行权限。如果没有，用chmod或chown修改。如果是执行脚本报这个错，检查脚本文件是否有x权限，没有的话chmod +x script.sh。如果权限没问题但还是报错，可能是SELinux在拦截，用getenforce查看SELinux状态，如果是Enforcing，可以临时用setenforce 0设为宽容模式测试一下，但生产环境不建议直接关闭，应该配置正确的SELinux策略。
还有一种情况是用sudo执行时报这个错，那可能是sudoers配置的问题，需要检查/etc/sudoers文件（用visudo命令编辑，不要直接改）。
6.2 磁盘空间没满但服务写文件失败
这个问题比较隐蔽，df -h看磁盘还有空间，但服务就是写不了文件。可能的原因有几个：一是inode用完了，用df -i查看inode使用率，如果IUse%是100%，说明inode耗尽，通常是大量小文件导致的；二是磁盘配额限制，用quota -v查看；三是文件系统只读挂载，用mount | grep ro查看是否有分区被挂载为只读。
inode耗尽的情况我遇到过几次，通常是因为某个目录下生成了海量的小文件，比如日志目录没有做轮转，或者临时目录没有清理。解决办法是找到并清理这些小文件，然后配置日志轮转或者定时清理任务。
6.3 服务端口被占用怎么快速定位
启动服务时报“Address already in use”，说明端口被占用了。用ss -tulnp | grep 端口号找到占用该端口的进程PID，然后用ps -p PID -f查看是什么进程。确认可以终止的话，用kill PID终止它，然后重新启动你的服务。
如果不想终止占用端口的进程，可以修改你的服务配置，换一个端口。但要注意，换端口之后相关的防火墙规则、反向代理配置、客户端配置都要同步修改，否则会出现服务起来了但访问不了的情况。
6.4 常见问题速查表
| 问题现象 | 可能原因 | 排查指令 | 解决方案 |
|---|---|---|---|
| Permission denied | 权限不足 | ls -l、getenforce | chmod/chown，调整SELinux策略 |
| 磁盘满但df显示有空间 | inode耗尽 | df -i | 清理小文件，配置日志轮转 |
| 端口被占用 | 其他进程占用 | ss -tulnp | grep 端口 | kill占用进程或换端口 |
| 文件删除后空间未释放 | 进程持有句柄 | lsof | grep deleted | 重启持有句柄的进程 |
| 命令找不到 | PATH未包含 | echo $PATH | 添加路径到PATH或用绝对路径 |
| 中文乱码 | 编码不一致 | locale | 设置LANG和LC_ALL环境变量 |
实操心得：遇到问题的时候，第一反应不应该是搜索“XX报错怎么解决”，而是先看日志。大部分问题的答案都在日志里，关键是要知道日志在哪、怎么看。系统日志通常在
/var/log/下，应用日志的位置取决于具体应用的配置。养成看日志的习惯，排查问题的效率会高很多。
7. 指令组合与效率提升的实战思路
7.1 管道与重定向：让指令协同工作
Linux指令的真正威力在于组合使用。管道|把前一个指令的输出作为后一个指令的输入，重定向>和>>把输出写入文件。这两个机制让简单的指令可以组合出非常强大的功能。
举一个实际工作中的例子：分析Nginx访问日志，找出访问量最大的前10个IP，并统计每个IP的访问次数。命令是：awk '{print $1}' access.log | sort | uniq -c | sort -rn | head -10。这一条命令做了五件事：提取第一列（IP）、排序、去重计数、按计数倒序排列、取前10条。如果用其他方式，可能要写一个脚本才能完成。
重定向方面，>覆盖写入，>>追加写入，2>重定向错误输出，&>同时重定向标准输出和错误输出。command > output.log 2>&1把标准输出和错误输出都写入同一个文件，这个在写定时任务的时候特别常用，因为定时任务不会在终端显示输出，必须重定向到文件才能看到执行结果。
7.2 历史指令与快捷键：提升操作速度
history查看历史指令，!编号重新执行指定编号的指令，!!重新执行上一条指令，!关键词执行最近一条以该关键词开头的指令。这些在重复执行某些操作的时候能省不少时间。
快捷键方面，Ctrl+R反向搜索历史指令，输入关键词就能找到之前执行过的相关指令，比用history | grep快得多。Ctrl+C终止当前指令，Ctrl+Z挂起当前指令，Ctrl+L清屏，Ctrl+A跳到行首，Ctrl+E跳到行尾，Ctrl+U删除光标前的内容，Ctrl+K删除光标后的内容。这些快捷键用熟了之后，敲指令的速度会有明显提升。
7.3 写一个实用的日常巡检脚本
把常用的巡检指令组合成一个脚本，每天定时执行，能帮你提前发现很多潜在问题。下面是一个简单的巡检脚本示例，你可以根据自己的需求调整：
#!/bin/bash # 日常巡检脚本 echo "===== 系统负载 =====" uptime echo "===== 内存使用 =====" free -h echo "===== 磁盘使用 =====" df -h | grep -v tmpfs echo "===== inode使用 =====" df -i | grep -v tmpfs echo "===== CPU占用前5的进程 =====" ps aux --sort=-%cpu | head -6 echo "===== 内存占用前5的进程 =====" ps aux --sort=-%mem | head -6 echo "===== 监听端口 =====" ss -tulnp echo "===== 最近登录记录 =====" last | head -10这个脚本覆盖了系统负载、内存、磁盘、inode、CPU和内存占用最高的进程、监听端口、登录记录等关键信息。把它加到crontab里每天执行一次，输出重定向到文件，定期查看就能对服务器的健康状况有一个全面的了解。
实操心得：巡检脚本的输出不要只看“有没有报错”，更要关注趋势。比如磁盘使用率是不是在持续增长，内存占用是不是越来越高，某个进程的CPU占用是不是一直居高不下。趋势比单次快照更能说明问题，很多故障在发生之前都有征兆，就看你能不能提前发现。
7.4 从指令到脚本：自动化思维的培养
掌握单个指令只是第一步，真正的效率提升来自于把重复的操作自动化。我刚开始工作的时候，每次部署都是手动执行一系列指令，不仅慢而且容易出错。后来把这些指令写成了部署脚本，一键完成打包、上传、解压、重启服务等操作，效率提升了好几倍，而且再也不会漏掉某个步骤。
写脚本的时候要注意几点：一是加错误处理，每个关键步骤后面检查返回值，失败就退出并输出错误信息；二是加日志输出，记录每一步的执行情况，方便排查问题；三是加参数校验，确保传入的参数合法；四是加注释，过一段时间回来看还能看懂。
脚本不需要写得很复杂，从最简单的开始，把最常用的几条指令串起来就是一个脚本。随着经验的积累，脚本会越来越完善，最终形成一套适合自己的工具集。这个过程本身就是全栈工程师成长的一部分。
8. 我个人在实际操作中的体会
Linux指令这个东西，看再多的教程也不如自己动手敲一遍。我刚开始学的时候，看视频觉得都会了，一上手就发现各种问题。后来逼着自己每天在服务器上练，遇到问题就查、就问、就试，慢慢就形成了肌肉记忆。现在敲指令基本不用想，手指自己就知道该敲什么。
另外，不要追求记住所有指令的所有参数，那是不现实的。重要的是知道“有这么个指令能解决这类问题”，具体参数用的时候查一下man或者--help就行。我到现在也经常查手册，这很正常。关键是要建立起“遇到什么问题该用什么指令”的直觉，这个直觉只能通过大量的实践来培养。
还有一点，指令的熟练度直接影响到排查问题的速度。线上出故障的时候，每一分钟都很宝贵，指令敲得快一点、准一点，就能早一点定位问题、恢复服务。这种能力在关键时刻的价值是无法估量的。所以平时多练，关键时刻才能不慌。
------(含面试题)常见的锁策略,CAS,synchronized原理)
