做运维这些年我面试过不少人也带过不少新人发现一个挺有意思的现象很多人简历上写着“熟悉Linux基础命令”结果到了生产环境一条grep管道命令能卡半小时面对服务器报错就只会重启。真正的基础命令不是背出来的是拿真金白银的线上故障喂出来的。今天这篇东西不整那些花里胡哨的“大全”就聊聊运维日常真正高频使用的基础命令每个命令我都会结合自己的实际场景讲清楚为什么这么用、坑在哪里。无论你是刚入行想做桌面运维、服务器运维还是准备转岗云计算运维的实习生这篇内容都值得花半小时看两遍然后照着在自己的虚拟机里敲一遍——纸上谈兵永远学不会运维。1. 先把“运维基础命令”这件事想明白1.1 基础命令和高级命令的边界在哪里很多人分不清“基础命令”和“高级命令”的边界总觉得会几条ls、cd就算入门了。我的理解是基础命令不是“简单命令”而是“你离开它就没法完成日常巡检、故障定位、服务器交付这三件事的命令”。它不一定多难但一定是高频出现、覆盖面广的那一批。比如ls谁都会敲但生产排查时你得会ls -lt /var/log/按时间排序找最新日志文件得会ls -lh看文件大小、ls -lrt倒序排列方便查看末尾文件。同理cd人人会用能“回退到上一次操作的目录”的cd -可能一半人不知道。这就是基础命令的价值——不是它有多高级而是你调用它解决问题时的熟练度和精准度。顺便说一句运维面试里那些“Linux常用命令大全”式的八股题问的往往就是这么细。我面试实习生时特别爱问df -h和df -i有什么区别什么时候该看哪一个能答上来的人说明他真是排查过磁盘告警的人不只是会背几个参数。1.2 弄懂命令优先级能查的别猜能看的别重启我给新人的第一条建议是搞清楚命令的“定位梯度”——有专门工具看的别用猜的能在线查的别先重启能缩小范围的别一层层翻。具体来说服务器正常运转时你的命令用于巡检和采集服务器出故障时你的命令用于定位和止血。两组场景下的命令使用逻辑完全不同。比如刚接手一台新服务器我会按以下顺序过一遍——uptime看负载、free -h看内存、df -h看磁盘、ss -lntp看端口监听、systemctl --failed看异常服务。这套动作像不像医院的“量血压、测体温、看血常规”这就是运维巡检的固定套路。别小看这套流程它能帮你快速判断一台机器是“健康”“亚健康”还是“病危”。不然你连内存该不该清、磁盘该不该扩都不知道上来就敲reboot那不是运维那是破坏分子。2. 文件与目录操作运维手上的“积木”2.1 高频命令的运行机制与实用参数文件和目录操作确实是Linux最基础的部分但深度挖掘后你会发现很多人的理解停留在“会用”而不是“用得好”。先说说ls。线上排查时最常用的形态是ls -lhtr按时间倒序看一个目录下最近哪些文件被改动过。比如怀疑某个应用在写日志、怀疑某个临时文件在被定时任务清理先用这一条命令排查基本心里就有数了。再配合ls -di可以查看目录的 inode 编号排查挂载点变更时非常有用。cp和mv是另一对容易出事的命令。先说mv很多新手以为mv只是“移动”实际上在同一个文件系统内它是“改名移动”速度极快跨文件系统则是“复制删除”。这导致一个线上比较常见的悲剧把一个大文件从/home下mv到/tmp下的不同分区时磁盘瞬间被占满或者移动中途报错。解决这类问题的标准姿势是rsync而不是mv因为rsync可以中断续传、保留权限和时间属性。cp最容易踩的坑就是覆盖文件后原文件的属主、权限和软链接状态发生了变化。例如你要备份一个配置文件cp nginx.conf nginx.conf.bak看起来没问题但如果/etc/nginx/nginx.conf本身是个软链接呢直接cp会把目标文件复制成一个新文件软链接关系就断了。正确的备份方式是cp -a保留所有属性或者干脆用cp -d保留链接属性。rm就不用多说了我见过太多人把rm -rf /opt/tomcat App敲成rm -rf /opt/tomcatApp直接删错也见过有人把备份目录的路径写错直接清空生产代码。遇到生产环境执行rm -rf我的个人底线是先ls一遍确认路径再在命令里明确写出完整的绝对路径或相对路径绝不使用带着通配符的简写。哪怕多花十秒钟也绝对不要把服务器搞挂了再花十个小时去恢复。2.2 解压文件乱码一个脏活的实际处理方案热搜里有“linux 解压文件乱码”这真是被 Windows 用户坑出来的一类问题。Windows 平台用 GBK 编码创建的中文文件名压缩包在 Linux 下用unzip解出来就是一堆乱码因为 Linux 默认按 UTF-8 解析文件名。低版本 unzip 没有好的解决办法但系统库里装了unzip新版本的话可以用unzip -O GBK file.zip指定编码。命令执行后文件名就能正确显示哪怕内容是中文的文件名也不会再是乱码。如果是 zip 包中有大量目录层级我习惯上先解压到一个隔离目录mkdir -p /tmp/zip_check unzip -O GBK file.zip -d /tmp/zip_check先看一眼文件结构再决定移动到哪里。直接在生产目录解压别人传过来的压缩包等于把自己的服务器安全交给对方里面万一有什么.sh脚本或者隐藏文件呢先隔离再检查最后移动。如果是tar.gz乱码那情况不太一样。tar处理的是字节流文件内容一般不会乱乱的是文件名此时可以借助convmv递归转换文件名编码convmv -f GBK -t UTF-8 --notest -r target_dir/建议转换前先不加--notest跑一遍模拟确认只改文件名不伤内容再正式执行。2.3 查找命令你真的用对了吗find是文件操作里的重型武器但我发现不少人只会用find / -name xxx.log把全盘扫一遍慢而且有时候还没权限。其实find的常用姿势非常多排查大文件用find / -xdev -type f -size 2G查找最近30分钟改动过的文件用find /data -mmin -30 -type f按属主、权限位、inode 数过滤也全都是顺手拈来的参数。还有一个被低估的命令是locate。如果你的机器上有 mlocate 或 plocate 数据库查找文件速度比find快出几个量级但它依赖updatedb定期更新数据库刚新生成的文件可能查不到。所以我的习惯是快速定位已知文件用locate精确匹配未知条件用find。3. 用户与权限管理运维的“门禁系统”3.1 创建用户时容易忽略的细节热搜里有“linux新建用户”这个操作看着简单写成useradd test一条命令就结束了但生产环境里远远不够。补充一个基本判断useradd和adduser在 CentOS/RHEL 系里基本是同一个东西在 Ubuntu/Debian 系里adduser是更友好的交互式脚本两者行为有差异。所以千万别在写跨发行版部署脚本时想当然地认为useradd带不带-m都一样。我创建业务账号时通常会这么做useradd -m -s /bin/bash -d /home/appuser appuser echo TemporaryPass_2025 | passwd --stdin appuser chage -d 0 appuser这三条命令的作用分别是创建一个家目录在/home/appuser、默认 shell 为 bash 的用户设置一个临时密码强制他第一次登录时修改密码。第三条chage -d 0很重要也别省不然密码会一直用下去安全审计一查一个准。提到默认 shell这里有个隐含常识如果是给应用使用的系统账号强烈建议把 shell 设置为/sbin/nologin也就是禁止这个账号直接 SSH 登录。很多新手理解不了“为什么不能直接登录”真到一台机器被入侵、攻击者拿到权限后疯狂横向扫描时你就会明白——业务系统账户能登录服务器的通道越少损失面就越小。3.2 权限排查不是只有 chmod 777权限问题是个大坑。搜索热词里出现了“linux中配置dns出现的问题”其实很多 DNS 相关报错不是配置写错了而是配置文件权限不对服务读到一半就放弃了。先说一个原则配置文件权限切忌一刀切 777。我看到太多人遇到“权限够不到”的问题顺手就chmod -R 777 /某某目录当时是爽了后患却是无穷的。任何一个隐藏的后门脚本、一行被篡改的配置都能在你毫无感知的情况下运行。权限最小化才是该有的安全底线。拿/etc/resolv.conf来说正常状态下属主是 root权限一般是 644。但如果你修改完 DNS 后忘记恢复属主或者手滑给成 666系统解析域名时可能就会出问题看起来像是“DNS 配置没生效”的样子实际是权限位让 NetworkManager 或 systemd-resolved 认为文件不受保护拒绝使用或直接重写。排查权限问题的基本思路是用ls -l看属主属组用getfacl查看 ACL 权限再用id确认当前用户属于哪些组。很多时候“文件明明可读但程序读不了”的诡异问题本质上是父目录没有x执行权限导致用户无法穿越目录。这个点非常隐蔽我在排查 nginx 403 时遇到过好几次。4. 进程与服务管理从“会看”到“会治”4.1 系统负载应该怎么读top和uptime是查看系统负载最常用的命令。但要理解的是load average这个值不是你服务器的“CPU使用率”而是“正在运行和不可中断的进程数量平均值”。一个直观的理解方式如果把 CPU 比作一条高速公路负载数字就是路上正在跑的车加出口排队等着出去的车它同时反映了“占用”和“等待”。单看负载高没有意义要结合 CPU 核数看。比如八核机器负载 8 和双核机器负载 8完全是两个概念。新人在这一块特别容易焦虑看到负载 20 就紧张得不行但如果你的机器是 64 核呢那可能只用了三分之一的算力。判断负载是否正常的经验公式很简单负载长期高于 CPU 核心数的 70%才需要重点排查。负载高但 CPU使用率不高时更可能是磁盘 I/O 或不可中断睡眠进程D 状态导致的要结合iostat -x 1或pidstat -d 1确认。这里推荐一个压箱底的排查命令组合top -c进入交互界面后按下P按 CPU 排序、按M按内存排序必要时按K杀进程。另一个非常好用的是pidstatsysstat 包提供可以精确看到每个进程的 CPU、内存、上下文切换和线程级信息。它是top的“单帧快照版”定向分析时比top好用太多。4.2 systemctl 与服务自启配置现在的发行版基本都切到 systemd 了systemctl成了服务管理的绝对核心。日常巡检我基本固定用这几条systemctl status vsftpd systemctl list-units --typeservice --staterunning systemctl is-enabled crondsystemctl list-units --typeservice --staterunning是所有运行中服务的列表适合一台机器刚接手时做盘点。is-enabled则用来确认服务是否开机自启。运维面试里经常问“如何把一个脚本设置为开机自启”很多人背了答案却分不清/etc/rc.d/rc.local、systemd unit、cronreboot三种方式的区别。我的建议是能用 systemd unit 就不用 rc.local。unit 文件可以精确控制启动顺序、依赖关系、自动重启还能在意外退出时被系统自动拉起。下面是一个 nginx 的 unit 示例结构生产上可以按这个思路自行修改[Unit] Descriptionnginx - high performance web server Afternetwork.target [Service] Typeforking PIDFile/run/nginx.pid ExecStart/usr/sbin/nginx ExecReload/usr/sbin/nginx -s reload ExecStop/usr/sbin/nginx -s quit Restarton-failure [Install] WantedBymulti-user.target写完之后依次执行systemctl daemon-reload、systemctl enable nginx、systemctl start nginx。很多新手漏了第一步改完 unit 直接 start然后发现改动没生效白白折腾半天。4.3 排查占用与清理进程的注意点排查端口占用旧习惯是用netstat -lntp。新版本系统我强烈建议换成ss -lntp原因是netstat在很多发行版里已经不再默认安装ss是 iproute2 套件的一部分性能更好、输出更快参数基本一一对应。比如查某个端口被哪个进程占用ss -lntp | grep 8080需要说明的是如果你不是 root 用户ss默认不会显示进程名和 PID要用sudo ss -lntp才能看到。这个细节在线上排查时特别坑新手经常用普通用户跑完命令后跑来问我“怎么看不到进程名”其实就是少了个sudo。杀进程方面我的顺序是先看进程 PID 和父进程 PPID确认不是暴力杀进程导致僵尸进程再用kill -15SIGTERM给进程优雅退出的机会不行再kill -9。很多人一上来就是kill -9 PID这样造成的资源占用残留和中间状态数据错误往往比进程本身的问题更难定位。另外要养成习惯杀完进程后ps -ef | grep 进程名检查一下是否真的退出特别是对于守护进程和自动拉起的服务别杀完就走人。5. 网络排查与连通性测试看透“通不通”5.1 一条命令快速判断网络状态网络排查是运维日常工作的高频需求。搜索词里赫然出现“telnet命令怎么用”“telnet ip 端口 命令”这种简单但高频的问题反而是很多人在生产环境里不得不临时翻文档的痛点。先说ping。ping只能确认目标主机是否通、延迟是多少但这里有个极大的误区——ping通不代表业务端口可连。防火墙策略可以允许 ICMP 但拒绝 TCP 端口主机可以通但某个应用没有监听这些都是很常见的场景。所以ping只作为第一层探测之后必须测端口。测试端口连通性标准工具是telnet ip port。比如telnet 192.168.1.10 3306如果端口开放你会看到类似 “Connected to 192.168.1.10” 的提示如果连接被拒绝则会在终端直接反馈失败如果连接超时大概率是被防火强拦截或网段不通。Ctrl ]可以进入 telnet 的交互模式输入quit退出。但注意很多精简系统没有安装 telnet 客户端。这时可以用nc -vz ip port测端口nc -vz -w 3 192.168.1.10 3306加-w 3的意思是限制超时时间为 3 秒避免长时间挂死。还要提醒一点telnet 和 nc 测试成功只能证明 TCP 三次握手成功并不代表应用层协议正确。真正要验证 MySQL 是否能响应业务请求还得用专业的客户端工具去连接一次。5.2 DNS问题解析失败怎么定位DNS 解析是另一个高频问题。搜索词里“linux中配置dns出现的问题”实际上包含了很多场景服务器解析不了外部域名、内部域名解析慢、刚改完 DNS 不生效等。我提供一个标准定位流程。第一步使用nslookup或dig确认解析结果dig www.example.comdig的输出比nslookup更全可以直接看到查询耗时、解析链路上每一级服务器的响应。想指定特定 DNS 服务器测试时直接写dig 223.5.5.5 www.example.com这个操作的意义在于判断问题出在“本地 DNS 服务器”还是“系统配置”还是“公网解析”。如果把解析请求发给 223.5.5.5 或 8.8.8.8 都正常但nslookup用默认配置失败那问题大概率在/etc/resolv.conf或 systemd-resolved。第二步检查/etc/resolv.conf内容cat /etc/resolv.conf强调一个细节现在很多系统默认由 systemd-resolved 或 NetworkManager 管理这个文件你手动改了之后可能一重启就被覆盖。所以如果想让改动持久生效应该去改网络配置文件例如nmcli conn mod ...或/etc/sysconfig/network-scripts/ifcfg-*而不是只改/etc/resolv.conf。对这个问题我在工作中见过很多次——同事手工改了 DNS结果服务器一重启又变回原来的查了一下午最后发现是 systemd-resolved 在“作祟”。第三步若ping域名不通但pingIP 通基本能确定为 DNS 解析问题若 IP 通了但业务仍异常再按“连不上、连上但响应慢、连接被重置”的路径往下走。这类问题不要上来就怀疑网络先用命令把链路切成“域名解析—端口连通—应用协议”三段每一段有对应工具定位效率会高很多。6. 文本处理与编辑器运维的“手术刀”6.1 vim的三境界我始终认为vim 是运维必备的基础命令它不是“选装的编辑器”而是“没有图形界面时你唯一的救星”。搜索引擎的热词里频繁出现“vim命令”说明很多人对它又怕又爱。第一境界会改文件。也就是vim 文件名、i进入插入、改完按EscZZ保存退出。这个境界只满足“改配置”的需求但效率不高因为每一步都要按一堆键。第二境界会跳转和搜索。用/快速定位关键词用G跳到末尾用dd删除当前行、yy复制、p黏贴这些操作组合起来工作效率提升非常明显。第三境界多文件操作和批处理。把 vim 当脚本编辑器用在文件内批量替换文本时用:%s/old/new/g对比文件时用vimdiff file1 file2。这里强烈推荐vimdiff。线上排查配置差异时比如比较 Nginx 主配置和备份配置之间的差异如果只有一台机器一个文件还好一旦涉及多台服务器的配置同步vimdiff比diff更直观能高亮显示差异而且可以直接在比对界面里逐行修正。这是我每天都要用的工具。新人最怕的是 vim 打开文件后不知道怎么退出网上段子堆成山。这里汇总一句不想保存改动直接退出用:q!保存退出用:wq或ZZ强制保存只读文件用:w!在你有权限的前提下。记不住就挂张便签在显示器边上敲久了肌肉记忆就有了。6.2 grep、sed、awk把它们当“管道三兄弟”grep、sed、awk是所有运维的基本功但基本功和基本功之间差距巨大。有人用grep只能搜关键词有人能用一条管道链把几万行日志里的异常情况在十秒内整理成表格。先说grep它不只能搜文字还能搜上下文。排查日志时最有用的是这三个参数grep -n ERROR app.log # 显示行号 grep -A 5 Exception app.log # 命中后额外显示后5行 grep -B 5 Exception app.log # 命中后额外显示前5行配合管道就演变成了运维最常用的大招tail -f app.log | grep ERROR这条命令的含义是动态追踪日志文件新增内容同时只过滤错误行。定位线上问题时用这个组合观察错误有没有继续出现是判断“故障还在持续”还是“故障已停止”的快捷路径。再说sed。它的核心操作是“流式编辑”适合处理大的日志文件因为它是按行读取不会把整个文件加载到内存几十 GB 的文件也扛得住。我自己最常用的场景是数据抽取和脱敏sed -n /2025-01-01 10:00/,/2025-01-01 11:00/p access.log hour.log这条命令把指定时间段的日志全部提取出来在做小范围时间窗口分析时非常高效。最后说awk。它的强大之处在于列操作。比如 nginx 访问日志默认格式里第 9 列是 HTTP 状态码第 10 列是响应大小第 7 列是请求路径。要统计昨天一天内返回 500 的请求数量用一条awk就能搞定awk $9 500 {count} END {print count} access.log再配合排序命令找出访问量最高的 IPawk {print $1} access.log | sort | uniq -c | sort -rn | head -20这条链路的含义是第一列取 IP排序后去重统计出现次数再按次数倒序排列取前 20 个。看起来轻巧但它已经是“统计 TOP N”的标准玩法了做安全分析、CC 攻击判断都用得上。6.3 容器化时代containerd 命令的运维必备属性搜索词里莫名其妙出现“containerd命令”说明容器化已经渗透到普通运维的日常工作里了。现在很多生产集群已经不再用 Docker CLI 直接操作底层运行时换成了 containerd配套命令是crictl或ctr。如果你所在环境用 Kubernetes那么crictl基本是标配。基础排查常用这三条crictl ps -a # 查看所有容器含退出状态 crictl logs container_id # 查看容器日志 crictl exec -it container_id sh # 进入容器交互执行命令有一个很坑的细节crictl ps只显示由容器运行时管理的“容器”视角而不是 Kubernetes 的 pod 视角。排障时往往要先kubectl get pod -o wide拿到节点名称和 container ID再登录对应节点用crictl搭理容器本身。这个过渡经常让新人一头雾水实质上就是“控制面”和“数据面”视角的差异。如果你还没到用 Kubernetes 的阶段只是用 Docker 跑几个服务那docker ps -a、docker logs -f、docker exec -it三件套一定要熟练到条件反射。做容器云的面试官只要问“线上容器不断重启你怎么排查”考核的就是这一套思维链——先看状态、再看日志、后用 exec 登进去看资源配置和进程状态。7. 常用问题速查把基础命令变成“条件反射”7.1 十三个高频小问题排查清单整理一个我自己平时给团队新人做培训的速查表。这里面的问题没有一个是冷门偏门全是生产环境里我踩过或带人排查过的高频场景。场景首选命令排查要点磁盘空间满了df -h先看哪个分区满再看大文件inode耗尽df -i大量小文件占满inodels -l不直观查看大文件分布du -sh * | sort -rh从当前目录逐层往下找服务启动失败systemctl status 服务名、journalctl -xe排日志看错误行端口被占用ss -lntp | grep 端口拿到 PID 和进程名谁占用了内存top -c后按M结合ps aux --sort-%mem网卡流量异常iftop或sar -n DEV 1分析是外网攻击还是内网跑批域名解析异常dig、nslookup、cat /etc/resolv.conf先确认解析再看配置SSH 登录慢sshd -T、journalctl -u sshd检查 DNS 反查、GSSAPI 认证文件找不到locate或find / -xdev -name一个速度快一个结果准确程序没日志ls -l检查目录权限父目录没有 x 权限导致更新失败时间不同步timedatectl、chronyc sources看 NTP 源和漂移值刚改配置没生效systemctl daemon-reload服务必须先重载再启动这张表不是让你背的而是建议你结合自己机器的情况把每一条都亲手验证一遍。哪个环节不通就顺手把它弄通这套动作本身就是一次很好的服务器复盘。7.2 配置完服务后马上要做的一件小事这一小节分享一个我的习惯每次修改完服务配置文件systemctl restart 服务名之前先把nginx -t、sshd -t、php-fpm -t这类语法检查跑一遍然后再重启重启结束后再看一眼服务状态和最新日志。这个流程看起来有点“强迫症”但它是最基本的保命动作。我在线上执行过太多次配置变更深知“重启才报错”的代价——明明只是局部改动结果服务起不来了业务直接中断影响面被动扩大。先做语法检查等于在上生产前加了道防线。排查服务器问题也同理第一步永远是“观察事实”而不是“猜测原因”。用命令确认现状用日志寻找佐证用最小代价验证假设。这一套方法论比背 100 个命令参数都重要。7.3 日志排查从开始到结束的一句话思路日志排查不教你特别复杂的门道只给一句话思路先确认你能不能拿到日志再确认你要找的是哪一个关键字最后用时间和行号把相关片段提取出来分析。日常最常用的就是tail -n 1000 -f app.log | grep ERROR如果日志文件被 logrotate 处理过可能需要找.log.1、.log.gz等历史文件ls -lhtr /var/log/app/ zcat app.log.gz | grep ERROR注意zcat可以读取 gzip 压缩的历史日志而无需解压这一点在处理轮转日志时特别实用。新人往往卡在这一步找不到昨天的日志就以为丢了其实是没注意到压缩包。日志系统一般会配套journalctl遇到 systemd 管理的服务journalctl -u nginx --since 2025-01-01 00:00:00 --until 2025-01-01 01:00:00 -p err-p err表示只输出 error 及以上级别的日志用于缩小搜索范围。当然如果你对服务运作机制足够熟悉也可以直接用strace去跟踪进程的系统调用但这已经偏离“基础命令”讨论范围了。基础运维阶段用上面的思路解决 90% 的日志排查问题绰绰有余。8. 装备一台“练习服务器”的完整建议8.1 虚拟机安装Linux系统和环境准备光看不练等于零。建议在本地用虚拟机安装一个 Linux 系统CentOS Stream 或者 Ubuntu Server 都行作为日常实验环境。如果机器资源足够装个带图形界面的发行版也可以操作上会友好一些。具体流程我可以帮你梳理一遍。去官网下载 ISO 镜像后VMware、VirtualBox 或开源的 KVM 都可以。给虚拟机分配至少 2 核 CPU、4GB 内存、50GB 磁盘。安装系统时区分“带图形”和“最小化安装”如果目标是运维方向建议选“最小化安装”理由很简单——生产环境全是命令行你早晚得习惯。安装完成后立刻做三件事一是配好 yum 或 apt 源把系统更新到最新二是新建一个普通用户并加入wheel或sudo组日常使用该用户操作而不是 root三是关闭防火墙或放行所需端口避免学习时被自己的机器挡住。这一套动作本身就是一次迷你运维演练反复做几遍会形成肌肉记忆。8.2 推荐一条从零开始的修炼路线有了实验机接下来怎么学我的建议是别按教材顺序学而是“按问题学”。第一周学会基本的目录与文件操作、用户与权限管理然后尝试自己写一个“一键部署 Nginx 静态网站”的部署脚本第二周把 Nginx 日志配置为 JSON 格式用 awk 和 grep 做一次访问量统计第三周学会使用 systemd 管理自己写的服务程序并配置开机自启第四周做一次故障复盘——故意把 DNS 配置写错、把端口占用再练习用命令定位和恢复。这样学的好处是每个阶段要用的命令都是“被问题逼出来的”印象会非常深刻。我自己当年带实习生也是这套路执行力合格的实习生四周下来基本能独立接手一台测试服务器的日常运维。如果你以后想走云计算运维、SRE 方向Linux 基础命令只是起点后面还有脚本自动化、容器化、监控告警、CI/CD 等超长链条。但地基不牢上面盖多高都心虚。基础命令这一关值得你多花时间打扎实。最后再分享一个小技巧随手整理自己的命令速查笔记。我个人习惯是按场景分类记录比如“磁盘排查”“网络排查”“权限问题”每个场景列出自己实测过、踩过坑的命令组合。这份笔记既能在紧急故障时帮你快速找回思路也能在跳槽或面试前帮你系统复习。不管什么方向这些底层能力都是越磨越亮的。