GreedyAbyss在Linux这个圈子里，有一类搜索词永远不会过时："linux常用命令大全""linux删除文件夹命令""telnet命令怎么用"。我见过不少同事，工位贴满了命令速查表，可一遇到线上问题，CPU打满、端口不通、磁盘写满，还是会愣在原地，不知道该先敲哪一条。问题不出在记性差，而是大家习惯按命令名称去背，没有按业务场景去组织。命令是手段，业务目标是终点。下面这些内容，就是要把高频命令按真实业务场景重新编排一遍，覆盖用户管理、日志排查、文件传输、网络诊断、代码发布、容器运维这几类最常遇到的场景。没有基础的新手可以照着敲，有经验的运维也可以当成分自己的排错清单来对照。
1. 别背命令大全，先把业务场景拆出来
1.1 场景驱动记忆，命令才会长在脑子里
很多人学Linux的方式是打开一张命令大全，从a到z背一遍，过两周全忘光。我自己带过不少新人，发现一个规律：凡是能记住命令的人，几乎都不是靠背，而是因为在真实场景里反复用了。比如"删除文件夹"这个动作，如果你只知道rm -rf，那你永远不知道为什么要先确认目录、为什么要加--preserve-root，直到你亲眼见过有人把环境删没了。场景化的本质是给命令绑定一个"触发条件"：遇到什么现象、产生什么疑问、需要满足什么目标，自然就想到了对应的命令组合。这不是玄学，而是大脑记忆的特点，把知识挂在场景下面，比按字母顺序排列牢固得多。
举个例子，同样是查看文件，/var/log下是为了找错误，/etc下是为了确认配置，/home下是为了管理用户目录；目标不同，命令组合完全不同。所以我在带新人时总会先问一句：你现在到底想解决什么问题？这句话比任何命令速查表都管用。当你把思维切换成"场景-目标-命令"三层，很多命令不用背也能融会贯通。我自己处理线上问题时也很少追着命令手册翻，而是按业务动作去想下一步该做什么，命令自然而然就浮出来了。
1.2 从高频搜索词反推大家都卡在哪
我把高频搜索词整理了一下，发现它们其实可以归到几大类业务场景里，下面这张表能看清楚我为什么这么分类。
| 业务场景 | 高频命令关键词 |
|---|---|
| 服务部署与用户管理 | linux新建用户、linux安装docker、linux安装nginx、linux系统安装python |
| 日志排查与故障定位 | history命令详解、linux查看cache版本、tail、grep、journalctl |
| 文件传输与备份 | linux scp命令、zip命令、tar命令、linux删除文件夹命令、linux find用法 |
| 网络诊断 | telnet命令怎么用、重置网口命令、ss、netstat、curl |
| 代码发布与文本处理 | git命令、vim命令、grep、awk、sed |
| 容器与集群 | containerd命令、docker命令 |
你看，这些词没有一个真正在问你"命令怎么拼写"，他们几乎全是在问"我遇到了什么场景该怎么办"。所以后面每一章，我都会按照这个场景分类展开，每个命令都讲清楚适用于什么业务动作、怎么敲、敲完怎么确认结果。建议你先把最近自己遇到过的Linux操作问题写下来，对照这张表看看卡在哪一类，再去针对性补课。这比从头到尾背命令大全高效得多。相信我，这样过一遍之后，你再去写自己的速查笔记，心里就踏实多了。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 服务部署与用户管理：从零拉起一台业务机
2.1 新建用户不能只敲useradd
新拿一台业务机，第一件事往往不是装软件，而是建一个专用账号。很多新手直接useradd testuser，然后发现没有home目录、sudo也用不了，就卡住了。正确的流程是useradd -m -s /bin/bash testuser，-m表示创建home目录，-s指定登录shell；然后passwd testuser设置密码；再用usermod -aG wheel testuser或usermod -aG sudo testuser把用户加入sudo组。不同发行版管理员组名不同，CentOS/RHEL是wheel，Ubuntu是sudo，忘了这一步后面授权全是坑。创建完账号后验证登录时，su - testuser切换过去，cd ~回到用户家目录，cd -在上次目录间切换，这些都是常用的目录操作，顺手就能熟悉一遍。
我自己的习惯是：应用服务一律用专用用户启动，坚决不用root跑业务。原因很简单，root一旦操作失误或者程序被入侵，影响面是整个系统；而专用用户能极大缩小风险。另外配合visudo编辑/etc/sudoers，可以限制某个用户只能执行特定的命令，比如只允许重启nginx：testuser ALL=(ALL) NOPASSWD: /usr/bin/systemctl restart nginx。这种细分授权在日常运维里既方便又安全，建议早点养成习惯。说到这里提一句，很多真实生产事故都源于"图省事用root起服务"，等被安全扫描扫出来再改权限，成本会高很多。
2.2 删除文件夹：rm -rf前的三道保险
"linux删除文件夹命令"应该是搜索量最稳的关键词之一，但搜索量高不代表操作简单，恰恰说明这个命令危险。我见过不止一次，有人想删/tmp/backup，手一抖敲成rm -rf /tmp/backup/，多一个空格或者路径错了，轻则误删数据，重则把系统文件一起带走。所以在生产环境我给自己定了三道保险：第一，先执行ls -ld确认路径；第二，尽量用mv把目录挪到/tmp，比如mv /data/old_dir /tmp/old_dir_20240115，观察一段时间确认无误再删；第三，真要用rm，就写完整路径并在当前目录下敲，不用相对路径加通配符。
还有一个小细节：如果只想删目录里的内容而保留目录本身，用rm -rf /data/xxx/*，这里通配符的位置非常关键；如果删错不想让数据立刻被覆盖，就别继续往同一块磁盘写数据，找工具去恢复也只是碰运气。总之我记得最牢的一次教训就是：rm是Linux里最不能靠肌肉记忆的命令，每个按键都要过脑子。我甚至建议你在.bashrc里加一行alias rm='rm -i'，给危险操作加一层确认，虽然偶尔烦人，但关键时刻能救命。
2.3 systemctl、ps、kill：管好服务进程
部署完服务，日常操作绕不开systemctl。start、stop、restart、status、enable、disable这六个子命令是最常用的，其中enable决定开机是否自启。很多人刚接触systemd，会直接去改/etc/rc.local，建议早点切换到systemctl的写法，因为它是当前主流发行版的默认初始化系统，日志、依赖、资源限制都能统一管理。排查服务异常时，systemctl status nginx会直接输出最近日志片段，比先tail日志再猜原因高效不少。如果你不知道该服务是不是systemd管理的，systemctl list-units | grep 服务名 能快速确认。
进程管理方面，ps aux和ps -ef都是老牌命令，区别在于ps aux是BSD风格，ps -ef是Unix风格，日常场景输出差别不大，你可以按习惯选。看到进程PID之后，配合kill使用，但记住一条原则：kill默认发的是TERM信号(15)，给进程体面退出的机会；kill -9是最后手段，直接让内核杀掉进程，可能丢失数据或留下脏状态。我先用systemctl restart，不行再kill -15，还不行才kill -9，顺序不能反。踩过几次坑之后，我现在凡是要杀进程，都会先ps -ef | grep 关键字确认PID没错，再动手。你要记住，杀错进程的后果往往比不杀更严重。
3. 日志排查与故障定位：先找证据，再谈修复
3.1 tail与grep组合：让日志开口说话
线上出问题第一反应是看日志，最常用的命令就是tail。tail -f app.log实时跟踪输出，tail -n 500查看最后500行，这两个要刻进脑子里。但只看tail不够，日志文件可能几万行，没法人肉扫，这时候grep就是主力。grep 'ERROR' app.log查错误关键字，grep -i忽略大小写，grep -E支持正则，grep -v反选剔除干扰行。我实际排障时最常用的组合是tail -n 1000 app.log | grep -E 'ERROR|Exception'，先锁错误再定位上下文。如果日志量特别大，还可以用grep -n把行号打出来，然后去那个行号附近看上下文。
有一个特别容易踩的坑：用tail -f管道接grep，比如tail -f app.log | grep ERROR，在部分环境下会因为管道缓冲导致输出延迟，grep结果要过一会儿才刷出来。你以为你在看实时日志，其实是在被缓冲机制骗。想要实时过滤，我一般用tail -n 500 -f app.log，然后直接靠眼睛扫描，或者用less app.log，进去之后按Shift+G到末尾，再按F进入跟踪模式，兼顾过滤和翻页。这些细节不踩一次坑真的很难意识到，所以说运维的经验基本是拿生产事故换出来的。
3.2 journalctl：systemd统一日志的正确打开方式
如果服务是用systemd管理的，那journalctl有时比tail还好用。它的核心价值在于跨进程收集日志、有统一的时间索引，还能按unit过滤。例如journalctl -u nginx --since "1 hour ago"查看nginx最近一小时的日志，journalctl -u nginx -f实时跟踪，journalctl -p err -b查看本次开机以来的错误级日志。我排查"某服务为什么没起来"时，习惯直接journalctl -u 服务名 -n 100 --no-pager，一眼看全局，不用在两个日志文件之间来回切。
注意一个陷阱：journald默认日志可能存在内存里，重启就丢了，如果你要留痕，需要修改/etc/systemd/journald.conf里的Storage=persistent，然后重启systemd-journald服务。这个配置在生产审计场合很关键，很多人排查了半天发现"日志怎么没了"，其实就是默认配置的问题。另外一个常用参数是--since和--until，可以精确圈定时间窗口，比如配合故障工单里的时间点，很快能定位到对应日志段。我记得有次线上告警，我直接用journalctl --since "昨天 22:30" --until "昨天 22:35" -u gateway，几分钟就锁定了问题提交，比翻原始日志文件快得多。
3.3 history命令详解：查清楚到底谁动了服务器
为什么热词里一直有"history命令详解"？因为排查"服务器怎么变的"这种事，history是最直观的线索。history直接列出当前用户的历史命令，history 20看最近20条，!1234重新执行编号1234那条命令。如果再配合一个环境变量HISTTIMEFORMAT="%F %T "，history输出就会带时间戳，这对事故复盘特别有用。我在自己管理的机器上，都会在/etc/profile.d/里放一个脚本设置这个变量，让所有用户的历史记录都带上时间。这样任何一次操作都能精确到秒，追查问题时特别有用。
但实话实说，history默认存在当前用户home目录下的.bash_history里，用户只要执行history -c或者unset HISTFILE，记录就没了。所以真正的审计场景，靠history远远不够，建议配合系统日志或sudo日志，比如用auditd监控关键目录和命令，或者把bash历史通过PROMPT_COMMAND实时写到syslog。我说的直白一点：history适合日常自查，不适合当安全证据。你把这两者的边界搞清楚，在业务现场就不会被history误导了。我自己处理过一次同事误删文件的事故，最后靠的就不是history，而是auditd审计日志。
3.4 系统资源与cache查看：free、df、du、file、-d判断
"linux查看cache版本"这个热词有点歧义，我猜大部分人实际想问的是查看系统里缓存占用，或者是某个应用缓存目录里有什么。先讲系统层面，free -h显示内存，里面的cache列是内核用来缓存磁盘读写的页面缓存，Linux认为空闲内存闲着不如拿去加速文件访问，所以你看free输出时别被"used特别高"吓到，先看available，那才代表真正