简介：《Linux系统常用命令与操作详解》是一份面向Linux终端操作员、技术支持工程师及初学者的命令速查手册。内容按文件与目录管理、系统状态监控、进程控制、网络配置、权限修改、文本处理与压缩解压等场景归类，覆盖cd、ps、kill、chmod、tar、grep等高频命令及典型参数组合。文档为docx格式，压缩包共1个文件，大小约18KB，内容精炼、便于随身查阅。文中还特别补充了重定向、管道、通配符以及ctrl+c、tab补全等符号与快捷键用法，有助于理解shell工作方式并提升脚本编写与排错能力。目前已有319人学习使用，适合日常遇到具体操作问题时快速定位合适命令，也可作为系统学习Linux终端技能的入门参考。
1. Linux系统常用命令的核心矛盾：不是背不完，而是用不对
搜“Linux常用命令大全”的工程师，有相当一部分下载过一份按字母排序的命令表，真正登录服务器排查问题时，却往往从 ls 开始逐个试。这个标题表面上看是命令清单，实际要解决的是“定位、执行、验证”的操作链路：文件在哪、权限怎么改、进程是否异常、日志说明什么。命令本身并不难背，难的是把每一条输出变成下一步动作的依据。下面不再按字母序罗列，而是按排查主线的顺序，把 Linux 系统中出现频率最高的六十条常用命令重新过一遍。适合刚接触 Linux 的开发者，也适合准备运维面试的技术人；已经熟练的人重新审视边界条件和参数陷阱，同样能减少线上环境的误操作。
2. 文件与目录：Linux常用命令里最先要建立肌肉记忆的一组
2.1 从 ls -l 的输出反推整条权限链路
文件报错时，第一眼永远看 ls -l。执行下面的命令：
ls -l /etc/hostname # -rw-r--r-- 1 root root 32 Sep 14 09:21 /etc/hostname输出里第一段字符决定文件类型与权限。第一个字符-表示普通文件，d表示目录，l表示软链接，b和c分别对应块设备和字符设备；后面的九个字符每三位一组，依次是属主、属组、其他人的读、写、执行权限。数值32是文件字节数，不是行数，这一点对新手极具迷惑性。把一行的六列拆开念一遍之后，再遇到 Permission denied，就能立刻判断是属主不对、属组不对，还是缺少执行位。
除了基本展示，ls还有一些容易被忽略的参数。ls -lt在目录中按修改时间排序，发布版本出现问题时，可以快速找到刚刚被改动的文件；ls -a显示.开头的隐藏文件，排查环境变量加载问题时不至于把.bashrc和.profile漏掉。写脚本时则建议使用ls -1加管道配合 wc -l 统计文件数量，避免交互式终端的装饰性输出干扰统计结果。
2.2 cd、cp、mv、rm 的最小参数组合
这四条命令本身没有门槛，真正的临界点在一些混合参数上。下面这组是排查和部署中最高频的几种：
| 命令 | 参数组合 | 场景说明 |
|---|---|---|
cp -a | 复制目录并保留属主、权限、时间戳 | 迁移配置目录，避免二次 chown |
cp -u | 仅覆盖源目录中更新的文件 | 增量同步静态资源 |
mv -n | 不覆盖已存在的同名文件 | 合并多批文件时保护已有内容 |
rm -i | 删除前逐一确认 | 使用通配符删除一批文件时兜底 |
rm -rf | 递归强制删除 | 只应出现在明确限定的目录范围内 |
实际使用时要区分cp -a与cp -r。-r只做递归复制，新文件的属主和权限跟随当前执行用户重新生成；-a相当于-dR --preserve=all，会把原文件的属主、属组、权限、时间戳一并保留。直接把编译好的站点目录复制到另一台机器时，用-a可以省掉后续整页的 chmod 修复。mv在同一文件系统内只是改写目录项，不复制数据，所以能瞬间完成；一旦跨文件系统移动，实际复制内容后删除源文件，命令的耗时和 IO 消耗都会明显上涨，这也是判断数据是否跑在挂载点上的一个旁证。
2.3 用 find 把“文件在哪”变成一条可执行的清理任务
查找明确名称的文件，find比locate更可控，因为它可以按时间、大小、类型组合过滤，再用-delete或-exec直接接管后续动作。下面的命令用于清理 30 天前的日志：
find /var/log -type f -name '*.log' -mtime +30 -delete参数展开来说：-type f排除目录和软链接，避免误删目录导致路径结构变化；-name '*.log'使用单引号，防止 Shell 先行展开通配符；-mtime +30表示文件内容最后修改时间距今超过 30 天，无符号的30表示恰好位于第 30 天的边界，容易漏掉或误伤；-delete只在前面所有条件同时满足时执行删除。正式清理前把-delete改成-ls先跑一遍，配合 crontab 落盘输出，能避免批量删错再把备份拉回来的尴尬。
日志文件找不到名字时，先按最近修改时间过滤：
find /app/tomcat/logs -type f -mmin -60 -printf '%TY-%Tm-%Td %TH:%TM %p\n'-mmin -60查找 60 分钟内被修改过的文件，-printf允许自定义输出格式，先打印修改时间再打印完整路径，文件多时排序和过滤都更方便。磁盘打满场景下再补一个-size +500M，可以快速锁定超过 500MB 的临时文件，避免对文件系统做无差别全盘扫描。
2.4 tar 打包与解压中的乱码，问题在编码不在命令
“Linux 解压文件乱码”是搜索量相当高的一类问题。同一台机器上，zip 包偶尔解出一堆乱码，而 tar.gz 很少出现同类现象。原因不是命令用错，而是 Windows 压缩工具生成 zip 时普遍使用 GBK/GB18030 编码写入文件名，Linux 终端默认按 UTF-8 解码，两个编码不一致就显示为乱码。tar.gz 内部文件名的编码规则统一，因此几乎没有这种争议。处理办法是在解压入口直接指定编码：
unzip -O GBK 中文文件名.zip-O参数表示用指定字符集解析文件名，GBK 解出来的文件名就能正常落到磁盘里。部分发行版默认安装的 unzip 不支持-O，可以改用7z x -mcp=936解压，效果等价。如果乱码发生在 tar.gz 包内，通常需要先确认打包时是否经过某种文件名转码流程，这种场景比 zip 少见得多，处理优先级也可以放低。
提示：解压乱码不需要在解压后批量重命名，指定正确的入口编码一次解决。事后用脚本替换文件名，反而容易牵连正常的中文文件名。
3. 权限与用户管理：Linux常用命令从能用到敢用的分水岭
3.1 chmod 数字位：读、写、执行如何快速换算
权限的数字表示是三组八进制数的叠加，每一组允许的值及其含义如下表：
| 数字 | 权限位组合 | 含义 |
|---|---|---|
| 7 | rwx | 全部权限 |
| 6 | rw- | 读写，不能执行 |
| 5 | r-x | 读和执行，不能写 |
| 4 | r-- | 只读 |
| 0 | --- | 无权限 |
chmod 755 script.sh设置之后，属主拥有全部权限，属组和其他用户拥有读和执行权限。对目录而言，x的意义是能否进入目录，所以目录通常设置为 755，如果设置成 6，别人就无法 cd 进去。chmod 644 config.conf则是属主可读写、其他人只读的典型配置权限。数字看多了自然会形成条件反射，一旦某个文件的权限位第一位是7，就要停下来问自己：这个文件真的需要被随便写吗？
符号方式适合调试时做单点修改。chmod +x start.sh为所有身份增加执行位，是最常用的叠加动作；chmod -R g=u /opt/service把属组权限对齐到属主权限并递归应用，适合修复那些从 Windows 或 FTP 上传后权限混乱的目录。递归参数-R存在一处真正的风险：对/、/etc这类根级目录执行错误权限，会直接破坏系统可读性甚至让服务无法启动，所以递归修改的范围越小越好。
3.2 chown 调整属主与属组时，顺序决定结果
服务部署目录通常需要交给特定运行用户，一条最典型命令是这样的：
chown -R deploy:deploy /opt/service参数含义：-R递归修改目录内的所有文件，deploy:deploy中冒号前面是属主、后面是属组。如果只写deploy:，表示只改属主、保留原属组；只写:deploy则只改属组。这两种写法在回收旧目录时非常实用，因为服务只需要属于某个特定组，或者只需要由指定用户读取，就不必把原来的属组关系全部重写一遍。修改后可以用stat -c '%A %u %g %n' /opt/service快速查看权限位、uid、gid 和文件名，避免路径过深时靠猜。
遇到 Permission denied 时，先执行id deploy查看用户所属组是否包含目标目录的属组，再决定是用usermod -aG补组，还是该用chown修改归属。正常情况下不要选择chmod 777一步到位，它会让任何用户都能写、能执行，日志目录和脚本目录一旦放开写入，攻击面会显著增大。
3.3 Linux 新建用户时最容易被忽略的三步
“linux 新建用户”的关键不是输入这一行命令，而是把下面三条完整地走完：
useradd -m -s /bin/bash deploy passwd deploy usermod -aG sudo deploy第一行参数的含义：-m创建用户家目录/home/deploy，-s /bin/bash指定登录 Shell，避免用户创建后只能停留在默认的 nologin 状态。第二行给用户设置初始密码。第三行把用户追加进 sudo 组，这里的-aG必须齐全，-a表示 append，漏掉它会把用户从原有附属组中整体替换出去，随后出现“刚才还在 docker 组里，现在权限没了”的怪现象。这三条命令做完后，建议用groups deploy检查最终生效的组列表，把结果写进初始配置文档。
验证新建用户的登录状态，有两个常用入口：
grep deploy /etc/passwd sudo -l -U deploy/etc/passwd中每一行的最后一个字段是登录 Shell，若为/sbin/nologin，说明这个用户只能跑服务，不能交互登录。sudo -l -U deploy列出该用户被授予的 sudo 规则，当用户反馈“我已经在 sudo 组却仍没有 sudo 权限”时，用这条命令检查规则是否被某条更早的策略截断，比反复让用户重试更有效。
3.4 sudo 配置边界：不要随意给 ALL=(ALL:ALL) ALL
公司服务器上常见的做法是给运维组单独开一个 sudoers 文件：
%ops ALL=(ALL) NOPASSWD: /usr/bin/systemctl, /bin/journalctl这段规则的意思是：ops 组的用户可以在所有主机上，不需要密码执行 systemctl 和 journalctl，其他命令照常需要密码或不被允许。NOPASSWD只适合限定到少量命令的场景。直接在 sudoers 里写ALL=(ALL:ALL) ALL且配置 NOPASSWD，相当于取消掉所有交互确认，一次脚本误操作就可能导致服务目录被整体删除；更重要的是，回车确认本身是一种人为延迟，批量执行清理动作时，这道密码栏反而能让我停下来想清楚命令涉及的具体路径，在不可逆操作前插入一道保护。
脚本内部执行指定操作时，推荐使用sudo -u deploy先切到目标用户，再执行具体命令。这样部署脚本中不会出现多个 root 级的裸命令，归属和环境变量也会和运行服务的用户保持一致，定位问题的可观测性会明显好一些。
4. 进程与系统资源排查：运维常用命令的主战场
4.1 ps -ef 与管道：定位进程时最常用的组合
登录服务器后的第一件事通常是确认进程还活着。最经典的组合：
ps -ef | grep nginx | grep -v grepps -ef列出全部进程，展示 uid、pid、ppid 和启动命令；第一段管道交给grep nginx过滤；由于 grep 本身也会作为一条进程出现在结果里，第二个管道用grep -v grep把它剔除。最终得到的行里，第三列 PPID 是最关键的信息，而最后一列完整命令包含启动参数，便于确认进程是不是以错误的环境文件启动的。
生产环境里更推荐直接使用pgrep -a nginx或ps -C nginx -o pid,stat,cmd。pgrep -a输出 PID 和完整命令，不夹杂其他过滤条件；ps -C按命令名精确过滤，并可自定义输出列。二者都能天然避开 grep 自身混入结果的问题，也便于在监控脚本中直接取 PID 做二次判断。进程出现大量 ZOMBIE 状态时，重点去看 PPID，通常不是主进程故障，而是子进程退出后没被父进程正确回收。
4.2 用 free、df、du 分清三个“为什么变慢”
系统变慢时，三组命令的输出侧重点完全不同，下表总结最容易相互混淆的三组：
| 命令 | 关注内容 | 典型误区 |
|---|---|---|
free -h | 物理内存、交换分区、available | 看到 cached 就误认为内存不足 |
df -h | 文件系统容量与挂载点 | 只看容量不看 inode |
du -sh | 目录或文件实际占用空间 | 对整个根目录执行，IO 被拉到极限 |
free输出中真正需要看的是 available 一列。多数发行版上 cached 占用大量内存，这是页缓存的正常形态，系统需要时会自动回收，不必因此去杀进程；真正该警惕的是 available 已低于几个 GB，且同时观察到 swap 使用率上升。df -h查看容量后顺手执行一次df -i，哪怕空间还剩几百 GB，inode 耗尽时照样写不了文件，而这种情况在大量小日志目录的机器上并不少见。du -sh适合定位目录，从某个起点逐层计算字节数，是最吃元数据的操作之一，不要对全盘执行。
要定位当前目录下占用最大的前 5 个一级目录，标准写法是：
du -x --max-depth=1 /var | sort -k1 -h -r | head -5-x限制不跨越文件系统边界，避免挂载的 NFS 目录把结果拉偏；--max-depth=1只统计一层；sort -k1 -h按第一列的人类可读大小排序，-r反转成从大到小；最后的head -5只保留前五行。如果某个目录突然多出数 GB，再用lsof +L1检查被删除但仍在占用文件句柄的进程，这往往是空间没释放的幕后原因。
4.3 top 的交互快捷键与 systemctl 的边界
top界面里可以按P按 CPU 排序，按M按内存排序，按k再输入 PID 来终止进程，按q退出。交互式界面虽然方便，生产环境里手动 kill 进程仍然要非常谨慎：直接 kill 会绕过服务管理器的监控和自动拉起，被 supervisor 或 systemd 管辖的服务，接下来几秒大概率会被重新创建，反而留下“杀不掉”的假象。
先查服务状态，再决定干预路径，是更稳的流程：
systemctl status nginx --no-pager--no-pager关闭分页输出，适合 SSH 长连接与脚本内直接查看。如果服务处于 failed 状态，systemctl restart nginx会重新执行 service 文件中的标准动作，包括 EnvironmentFile 加载和环境变量注入；手动用二进制路径启动则完全不走这条路径，环境变量和目录权限都可能与预期不一致。所以凡是 systemd 托管的服务，优先考虑 restart 和 stop，而不是 kill；对 Docker 内的进程，则优先使用docker stop，让镜像的启动配置完整执行一遍。
4.4 journalctl 查看最近时间窗口的日志
定位服务问题的顺序应该是：先确认时间窗口，再确认服务 unit，最后才看具体报错。一条可直接复用的命令：
journalctl -u nginx --since "1 hour ago" --no-pager | tail -100-u nginx限定 unit，--since只输出最近一小时的记录，--no-pager避免交互式打断，tail -100保留最后 100 行，通常就足够覆盖一次异常前后发生的完整事件。如果输出为空，升高过滤等级再查看journalctl -u nginx -p err --since "1 hour ago" --no-pager，可能是当前时间窗口内确实没有 error 级别日志，也可能是 journald 对日志大小做了裁剪。两种原因处理方式不同，前者需要扩大时间窗口，后者需要在/etc/systemd/journald.conf里调高 SystemMaxUse 后重启 journald，操作之前先执行df -h /var/log确认磁盘有余量再动配置。
5. 把 Linux 常用命令串成自己的操作链：grep、别名与历史复用
5.1 grep -n 与上下文，是日志搜索里的第一优先级
搜日志最忌讳一屏输出全部命中。先记住一条命令：
grep -rn "error" /etc/nginx --include="*.conf"-r递归目录，-n同时输出行号，--include="*.conf"只扫指定后缀文件，避免二进制或缓存文件干扰。看到具体行之后，再加-C 3取前 3 行和后 3 行，就能直接基于上下文判断这是一条请求错误还是配置错误。要更进一步做统计，grep -c统计行数，grep -o只打印匹配部分，与 sort、uniq 组合在一起，就能把一段日志瞬间改造成计数报表。
5.2 把高频组合沉淀到 .bashrc，而不是反复搜手册
与其每次搜索“linux 命令大全”，不如把当天手敲超过三次的组合命令沉淀进~/.bashrc：
alias ll='ls -lahF' alias du1='du -h --max-depth=1 | sort -h' alias files='find . -type f -name'第一行把ls -lahF缩写成ll，第二行让du1直接呈现当前目录下占用最大的目录排序，第三行定义files "*.log"作为递归查找入口。保存后执行source ~/.bashrc即可生效，不需要重新登录。git 常用命令、docker 常用命令这些同属于 Linux 命令行生态的子集，也可以用同一套思路沉淀。最后再回来看这些别名里的固定路径，把它们换成$HOME/workspace这类变量，就得到真正适合自己工作机的常用命令集。
本文还有配套的精品资源，点击获取
