1. 先聊聊我为什么要整理这份命令清单干这行久了你会发现一个特别真实的现象每天敲得最多的命令往往不是那些花里胡哨的骚操作而是来回就那几十条。我电脑的终端历史记录里翻来覆去出现的就是ls、cd、grep、docker ps、git status这些基础货但恰恰是这些基础货用不对的时候最容易卡壳。入行前几年我特别迷信“背命令”恨不得把 Linux 常用命令大全全文背下来。后来发现完全没必要因为工具太多了今天用 Docker明天调 HDFS后天写 MATLAB 脚本你不可能每一条命令都记在脑子里。真正高效的思路是把高频命令按场景整理成自己的速查笔记用到的时候三秒钟查出来比死记硬背靠谱得多。这也是我做这份“个人使用-常用命令”清单的初衷。这份清单不是什么系统教程看起来更像是我在命令行世界里摸爬滚打多年后沉淀下来的“口袋笔记本”。内容包括 Linux 基础操作、Git 版本控制、容器编排、服务调试、数据处理等日常高频场景每一类都附带了我在实际项目中踩过的坑和总结出来的命令用法。无论你是刚入行的运维新人、转行做后端开发的程序员还是天天跟集群打交道的数仓工程师按图索骥都能省下不少查文档的时间。1.1 从“记不住”到“记笔记”的转变很多人有个误区觉得记不住命令就是技术不行。我见过工作七八年的老开发照样会为了一条tar解压参数去翻手册。命令行这东西本质上就是工具的“操作面板”面板上按钮那么多谁能全部记住呢我自己总结了一套整理命令笔记的方法。不是把网上的“Linux 常用命令大全”复制粘贴过来就完事那样存了也不会看。我的做法是每遇到一个场景就先把解决当前问题的命令记录下来后面再遇到同类问题时去翻笔记顺手把命令跑一遍如果发现更好用的参数就补上去。这样积累下来的笔记每条命令都带着真实的上下文下次用的时候一眼就能看懂。1.2 这份清单适合谁如果你还处在复制粘贴命令、跑完不知道什么意思的阶段这份清单能帮你建立一条清晰的“场景-命令”映射关系。比如你看到“查看端口是否被占用”就能想到netstat -tunlp | grep或ss -tunlp看到“容器日志一直刷屏”就能想到docker logs -f --tail这类组合。如果你是老手这部分内容可能大部分你都见过但其中关于排查思路和参数细节的说明说不定也能帮你查漏补缺。毕竟命令行工具更新迭代很快很多新参数和技巧平时不专门去研究是真的不知道。2. Linux 基础命令用得最频繁的高频场景Linux 命令是整份清单的地基。无论你后续用 Docker、K8s 还是 Git最终都要落在操作系统这个层面上。我按日常使用频率排个序把真正高频的操作分成三类系统状态查看、文件处理和日志追踪、权限与进程管理。2.1 系统状态查看与网络定位查 IP 是最高频的操作之一但很多人只知道ifconfig这台机器没装 net-tools 就直接抓瞎。我现在的习惯是优先用ip addr系统自带输出格式也干净。如果只是想看某个网卡的 IP可以加ip addr show eth0或者在后面接| grep inet过滤一下只留 IP 信息。# 查看所有网卡 IP ip addr # 只查看 eth0 的 IP 地址 ip addr show eth0 | grep inet说到网络排查ping和telnet属于连通性测试的入门命令但项目里经常碰到“外网能通、内网端口就是连不上”的情况。这时候我一般先用telnet 目标IP 端口测端口通不通再用nc -vz 目标IP 端口做一次快速探测。如果端口不通接下来就要上traceroute一步步看数据包在哪一跳断了。举一个我自己的例子。有次排查一个服务间调用超时两台机器 ping 是通的但业务端口怎么都连不上。我先在客户端机器上执行telnet 10.0.0.8 8080提示 Connection refused确认是目标端口没有监听再上服务器执行ss -tunlp | grep 8080发现那个进程压根没起来最后查出来是启动脚本里一个环境变量写错了。整个过程五分钟搞定靠的就是这条排查链路。2.2 文件处理和日志追踪日志是后端和运维排查问题的救命稻草。Linux 下查看日志最核心的两条命令就是tail和grep组合起来用能解决 80% 的日志排查需求。# 实时跟踪日志输出 tail -f app.log # 跟踪日志并从最后 200 行开始显示 tail -200f app.log # 从日志中过滤关键字并显示前后 5 行 grep -n -C 5 ERROR app.logtail -f是实时跟踪日志文件新增内容的利器配合grep做关键字过滤基本能替代专门的日志平台做快速定位。grep -C 5这个参数很容易被人忽略它的意思是把命中关键字的上下文各 5 行也打印出来排查问题的时候能少走很多弯路。文件操作方面du -sh *查看目录占用空间大小、df -h查看磁盘剩余空间都是日常必备。大目录定位也别一个个找了直接du -h --max-depth1 | sort -hr一层层往深处看磁盘满的问题基本十分钟内定位到。2.3 权限与进程管理线上环境最怕一个字乱。文件权限不对导致服务起不来是新手和老手都会踩的坑。我后来养成了一个习惯修完配置先ls -l看一眼权限和属主属组确认没问题再重启服务。进程管理里ps -ef | grep java是排查进程是否存在的标准姿势但ps -ef输出信息太全看起来费劲。我一般会配合grep -v grep把 grep 自身进程过滤掉或者用pgrep -f java直接拿 PID。如果想知道某个 PID 对应的完整启动命令可以看/proc/PID/cmdline# 查看某个进程的完整启动命令 cat /proc/12345/cmdline | tr \0 # 显示进程的 CPU 和内存占用排行 top -o %CPUtop 命令跟 Windows 的任务管理器差不多但功能强很多。top -o %CPU可以按 CPU 占用率排序一眼就能看到是哪个进程在“吃”资源。动态刷新界面里按P键按 CPU 排序按M键按内存排序这两个快捷键比鼠标点来点去快多了。3. Git 命令版本控制里的日常操作流Git 是我日常接触频率仅次于 Linux 命令的工具。一个人折腾项目还好一旦进团队协作分支管理、代码合并、冲突解决这些动作天天都在发生。我整理 Git 常用命令时没有按文档顺序罗列而是按照“日常开发流程”来组织这样更贴近真实使用场景。3.1 工作区、暂存区、提交区的三区概念理解 Git关键是理解它的三区模型工作区你正在编辑的文件、暂存区准备提交的内容、版本库已提交的历史。很多命令操作理解不了都是因为对这三区的关系不清楚。日常开发中最常用的流程是# 查看当前仓库状态 git status # 将文件加入暂存区 git add . # 提交到版本库 git commit -m 本次修改说明 # 推送到远程仓库 git push origin main这三步走下来一个完整的本地修改-提交-推送流程就完成了。但实际工作中往往没这么顺。我经常会碰到把不该提交的文件加进了暂存区的情况这时候需要用git reset HEAD 文件名把文件从暂存区撤回来工作区的内容保持不变。# 从暂存区撤出不改动工作区文件 git reset HEAD 文件名 # 撤销工作区的修改危险操作慎用 git checkout -- 文件名git checkout -- 文件名这条命令必须提醒一句它是把工作区的文件还原成暂存区或版本库里的内容一旦执行你本地改的东西就没了。用之前先git status看清楚确认这个文件确实不想要了再执行。3.2 分支操作与合并冲突团队协作里分支管理是门必修课。我从早期一锅粥地直接在 main 上改代码到后来老老实实按 feature 分支开发踩过不少坑。现在我的习惯是每开发一个功能就拉一个分支功能完成后再合并回主分支。# 查看本地和远程全部分支 git branch -a # 基于当前分支新建并切换 git checkout -b feature/optimize-api # 拉取远程最新代码并合并到当前分支 git pull origin main # 合并指定分支到当前分支 git merge feature/optimize-api合并冲突是团队协作里最让人头疼的事。以前我一看到CONFLICT就慌后来总结出一个思路不要慌着删别人的代码先把冲突段落里的、、标记看懂左边是当前分支的内容右边是合并进来的分支的内容然后逐段选择保留哪部分。# 查看冲突文件列表 git status # 解决冲突后标记为已解决 git add 冲突文件 # 继续完成合并 git commit解决完冲突一定要在本地编译跑一遍确认没有问题再 push。线上环境因为合并没有验证导致代码互相覆盖的问题我见过不止一次。3.3 撤销与历史修改的兜底方案Git 给了你犯错的机会但也要求你足够熟悉撤销的几种方式。我自己的经验是撤销命令一定要分清场景不然很容易把整个历史搞乱。如果只是提交信息写错了用git commit --amend -m 新的提交信息可以修改最近一次提交的信息。如果代码已经提交但还没推送到远程想回退到上一个提交用git reset --soft HEAD~1这样文件会保留在工作区只是撤销了 commit。如果代码已经推送到远程并且团队其他人可能已经拉取过千万不要用 reset要用git revert生成一个反向提交。# 修改最近一次提交信息 git commit --amend -m 改好的提交说明 # 回退到上一个提交保留工作区修改 git reset --soft HEAD~1 # 生成一个新的反向提交安全地回退 git revert HEADrevert和reset的区别简单理解就是reset 是回到过去会改写历史revert 是沿着历史继续往前新增一个提交来抵消之前的内容。回到过去这件事只有你自己一个人开发时才适合干团队协作场景下一律用 revert这是我在生产环境里学到的教训。4. Docker 与 K8s容器环境下的常用命令容器化普及之后Linux 命令的使用场景开始和容器命令深度绑定。本地开发环境、测试环境、生产环境到处都在跑容器。我整理这部分命令时重点放在“快”上一个容器诊断问题怎么用最少的命令链快速定位。4.1 Docker 镜像与容器的生命周期管理Docker 的核心概念就两个镜像Image和容器Container。镜像好比是模板容器是模板运行起来的实例。我日常最常用的 Docker 命令基本围绕这两个对象展开。# 查看运行中的容器 docker ps # 查看所有容器包含已停止的 docker ps -a # 进入运行中容器的交互式终端 docker exec -it 容器ID /bin/bash # 停止、启动、重启容器 docker stop 容器ID docker start 容器ID docker restart 容器ID # 构建镜像 docker build -t 镜像名:标签 .调试容器内部问题的时候docker exec -it 容器ID /bin/bash是我的首选命令。进去之后先看进程、看网络、看文件基本跟操作一台普通 Linux 机器一样。如果容器里没有 bash就换成/bin/sh更轻量一些。查看容器日志也是高频操作。Docker 日志的统一出口是标准输出所以应用里console.log或者System.out.println的输出都能直接通过docker logs拿到# 查看容器最近 200 行日志 docker logs --tail 200 容器ID # 实时跟踪容器日志 docker logs -f 容器ID4.2 Kubernetes 的基本操作到了 K8s 环境你会发现原来 docker ps 能看的东西现在都打散到了多个命名空间和多个 Pod 里。K8s 的命令体系比 Docker 复杂不少但核心思路是一致的先看资源状态再进 Pod 排查。# 查看当前命名空间下的 Pod kubectl get pods # 查看所有命名空间下的 Pod kubectl get pods -A # 查看 Pod 详细信息事件、状态、调度情况 kubectl describe pod Pod名称 # 进入 Pod 内部进行排查 kubectl exec -it Pod名称 -- /bin/bash # 查看 Pod 日志 kubectl logs -f Pod名称K8s 排查问题我一般遵循“三层递进”的顺序第一层kubectl get pods看状态发现 Pod 没 Running 或者一直 CrashLoopBackOff就进入第二层kubectl describe pod看事件里面有镜像拉取失败、资源不足、健康检查失败这些具体原因第三层才是kubectl logs看应用日志。很多人一上来就 logs结果日志里什么都没有反而浪费时间。4.3 资源查看与端口占用排查容器环境的资源排查和物理机略有不同。Docker 这边docker stats能实时看到每个容器的 CPU 和内存占用效果类似宿主机上的 top 命令# 实时查看所有容器的资源占用 docker stats # 查看容器的端口映射 docker port 容器ID遇到端口冲突的时候我一般会在宿主机上先用ss -tunlp | grep 端口号确认端口被哪个进程占用再docker ps看看是不是有容器的端口映射和宿主机已有进程冲突了。有一次排查线上服务启动失败就是这个原因新容器映射的 8080 端口被宿主机上一个残留的 Java 进程占着容器的端口根本绑不上得先处理掉旧进程再重启容器。K8s 环境里查端口被谁占用要麻烦一些通常要看 Service、Endpoint 和 Pod 的对应关系。kubectl get svc -A看服务kubectl get endpoints -A看后端的实际 IP 和端口一层层对上。大部分时候问题出在 Service 选择器selector写错了导致 Endpoint 里没有对应的 Pod。5. Nginx、Vim、GDB服务配置与调试工具这三样工具在传统运维和后端开发场景里出现的频率非常高。Nginx 是流量入口的第一道关卡Vim 是服务器上改配置的必备编辑器GDB 则是排查 C/C 程序崩溃和性能问题的利器。把它们放在一起因为都和服务端“调、试、改”相关。5.1 Nginx 配置校验与热重载Nginx 是一个高性能的 Web 服务器和反向代理服务器。很多人配置 Nginx 的时候写完配置文件直接重启服务结果语法有误服务直接挂掉线上访问瞬间中断。我自己的习惯是改完配置先做语法检查再优雅重启。# 检查 Nginx 配置语法 nginx -t # 热重载配置不中断服务 nginx -s reload # 查看 Nginx 版本号 nginx -vnginx -t会告诉你配置文件有没有语法错误、引用的文件路径是否存在。nginx -s reload是平滑加载新配置加载过程中已建立的连接不会被中断特别适合线上环境。很多新手分不清 restart 和 reload 的区别restart 是把 Nginx 进程杀掉再重新启动存在短暂的服务不可用窗口reload 是重新加载配置文件不中断现有的 worker 进程生产环境优先选 reload。5.2 Vim 的高效编辑模式服务器上没有图形界面改配置基本靠 Vim。很多人第一次进 Vim 不知道怎么退出这种“进得去出不来”的尴尬是每届菜鸟都躲不过的坎。Vim 的核心是模式切换普通模式、插入模式和命令模式。# 打开文件 vim /etc/nginx/nginx.conf # 按 i 进入插入模式开始编辑 # 编辑完按 Esc 回到普通模式 # 输入 :wq 保存并退出让我梳理一条最短的 Vim 命令链路打开文件 → 输入/搜索关键字例如搜索 server_name → 按n跳到下一个匹配 → 按i进入编辑模式修改 → 按Esc→ 输入:wq保存退出。这套流程能覆盖 80% 的服务器文件修改场景。Vim 里还有一个非常有用的可视模式按v进入移动光标选中文本再按y复制、d删除。剪切粘贴不再依赖鼠标效率非常高。刚上手的时候可能会觉得别扭但坚持两周你会发现自己已经离不开它了。5.3 GDB 调试的基础流程GDB 是 Linux 下调试 C/C 程序的神器。平时写代码我不怎么用 GDB但程序一崩溃尤其是出现 core dump 的时候GDB 就是救命稻草。调试之前编译的时候要加-g选项保留调试信息否则 GDB 看不到函数名和行号。# 调试可执行程序 gdb ./app # 带参数调试 gdb --args ./app --configapp.conf # 分析 core dump 文件 gdb ./app core # 在 GDB 内部常用的命令 # b main 在 main 函数打断点 # run 运行程序 # bt 查看函数调用栈 # info locals 查看当前函数的局部变量 # quit 退出 GDB程序崩溃后最常用的操作是bt查看崩溃时的函数调用栈能直接定位到是哪个函数在什么调用链路上出的问题。这个过程好比是交通事故现场勘查先看痕迹再还原事故发生的过程。配合info registers查看寄存器的值很多内存相关的崩溃原因都能顺藤摸瓜查出来。6. 开发环境与数据链路HDFS、Conda、ADB、MATLAB这一部分更像是一个开发者和数据处理工程师的“工作台”。HDFS 是大数据生态的存储底座Conda 是 Python 环境管理的绝佳工具ADB 是 Android 开发调试的连接桥MATLAB 则是算法研究和数据仿真的重武器。这几样东西看着杂但它们有一个共同点日常操作高度依赖命令行。6.1 HDFS 文件操作HDFS 全称 Hadoop Distributed File System是分布式文件系统。它的命令风格模仿了 Linux 文件系统命令但前缀是hdfs dfs或hadoop fs。# 查看目录下的文件列表 hdfs dfs -ls /data # 创建目录 hdfs dfs -mkdir -p /data/warehouse # 上传本地文件到 HDFS hdfs dfs -put local.txt /data/ # 下载 HDFS 文件到本地 hdfs dfs -get /data/result.txt ./ # 查看文件内容 hdfs dfs -cat /data/result.txt | head -100HDFS 命令和 Linux 命令最大的区别在于路径是 HDFS 命名空间里的路径不是本地路径。写脚本的时候最容易踩的坑就是路径写错。我一般先hdfs dfs -ls /看一眼根目录结构然后再往下走。还有一个要注意的hdfs dfs -mkdir -p才会自动创建多级父目录不加-p时父目录不存在会报错。6.2 Conda 环境管理玩 Python 项目最怕的就是环境依赖冲突。不同项目依赖不同版本的包如果全装在一个 Python 环境里一段时间后就是一团乱麻。Conda 解决的就是这个问题为每个项目创建独立的环境互不干扰。# 创建指定 Python 版本的环境 conda create -n myenv python3.9 # 激活环境 conda activate myenv # 退出当前环境 conda deactivate # 查看所有环境 conda env list # 导出当前环境配置 conda env export environment.ymlconda env export environment.yml这条命令特别适合团队协作。新建机器时只需要conda env create -f environment.yml就能复现一模一样的 Python 环境省去了手动安装依赖包的繁琐步骤。我踩过的一个坑是 Conda 和系统自带的 Python 混用。在激活 Conda 环境后终端输入的python应该是环境里的 Python但有时候 shell 的 PATH 优先级不对又把系统的 Python 找出来了。解决办法是在激活环境后先执行which python确认清楚再用避免装包装错到系统 Python 里。6.3 ADB 调试与 MATLAB 脚本化ADBAndroid Debug Bridge是 Android 开发和测试人员的标配工具。我平时用 ADB 最多的是抓取 Android 设备的日志和安装调试包。# 查看连接设备 adb devices # 安装应用 adb install app.apk # 抓取设备日志并过滤关键字 adb logcat | grep AndroidRuntime # 进入设备 shell adb shell # 从设备拉取文件到本地 adb pull /sdcard/test.mp4 ./MATLAB 的命令行使用分两种场景交互式命令行直接跑和脚本文件批量跑。交互式命令行适合快速验证算法脚本文件适合完整的流程处理。MATLAB 命令的常用习惯是加分号抑制输出分号是“这条命令不打印结果”在脚本里能避免刷屏。# 清除变量和命令窗口 clear; clc; # 查看变量的详细信息 whos # 运行脚本 run(myscript.m) # 显示绘图窗口 plot(x, y); grid on; xlabel(X轴); ylabel(Y轴);写 MATLAB 脚本时我养成了一个习惯所有关键代码片段都用%%分节这样可以在编辑器里按“节”运行调试效率会高很多。这个习惯和写 Python 时用 Jupyter Notebook 的 cell 是一个逻辑。7. 常见问题与排查技巧实录命令行用得越多遇到的报错就越五花八门。这里把我这些年踩过的一些典型坑和排查技巧整理成清单希望对你有用。7.1 命令找不到怎么办最常见的报错就是command not found。遇到这个先不要慌大多数情况是命令没装或者没有加入 PATH。# 查看某条命令是否存在 which nginx # 或者 type nginx # 临时加入 PATH export PATH/usr/local/nginx/sbin:$PATH # 永久加入 PATH写入 profile 文件 echo export PATH/usr/local/nginx/sbin:$PATH ~/.bashrc source ~/.bashrc排查思路是先用which看命令是否存在如果存在但没有执行成功基本就是 PATH 的问题如果which没输出说明命令没装先yum install或apt install。这里有一个小技巧很多命令安装后bin 目录不在默认 PATH 里比如 Nginx 安装后默认在/usr/local/nginx/sbin如果不把这个目录加进 PATH直接敲nginx就会 command not found。7.2 端口被占用的快速定位端口被占用是开发调试里最普遍的问题之一。启动服务时报“Address already in use”十有八九是之前的进程没有彻底退出或者端口被其他服务占用了。# 查看谁占用了端口 ss -tunlp | grep 8080 # 或者 netstat -tunlp | grep 8080 # 直接杀掉占用端口的进程 kill -9 $(ss -tunlp | grep 8080 | awk {print $7} | cut -d -f2 | cut -d/ -f1)这里我把kill -9的复合命令也写出来了但我要多嘴提醒一句kill -9是强制杀死进程生产环境慎用因为进程可能正在处理请求或者写数据直接被干掉的后果是数据损坏或服务不可恢复。更稳的做法是先kill PID默认 SIGTERM给进程一个优雅退出的机会没有效果再考虑kill -9。这条经验是真实事故换来的有次我直接用kill -9杀掉了一个正在写索引的进程结果索引文件损坏花了半天才重建干净。7.3 用 alias 收纳高频命令命令行高手和新手一个很明显的区别就是高手会定义一堆自己的 alias。把一长串命令缩成一个简短的关键词不仅敲起来快还不容易记错。# 常用缩写 alias llls -lh alias lals -a alias grepgrep --colorauto alias qexit # 工程化缩写 alias gpgit pull alias gcgit commit -m alias dpsdocker ps alias kkubectl这些 alias 写在~/.bashrc或~/.zshrc里保存后执行source立即生效。用 alias 最有成就感的一次是我把一条特别长的 K8s 日志查询命令浓缩成了klog后来每次排查问题都靠它一步到位团队同事看到了还专门找我抄配置。7.4 一份可以抄作业的命令速查表最后我把高频命令整理成一个速查表方便你直接抄到自己的笔记里。场景命令说明查看 IPip addr替代过时的 ifconfig实时看日志tail -f app.log跟踪文件新增内容过滤关键字grep -n ERROR app.log带行号输出查看端口ss -tunlp显示监听端口和进程磁盘占用df -h查看磁盘剩余空间目录大小du -sh *查看当前目录各子目录大小修改文件vim 文件名服务器上最常用的编辑器Git 提交git add . git commit -m msg暂存并提交Git 撤销git revert HEAD安全回退到上一个提交Docker 查看docker ps查看运行中的容器Docker 日志docker logs -f 容器ID跟踪容器日志输出K8s 看状态kubectl get pods -A查看所有 PodK8s 观察详情kubectl describe pod查看 Pod 事件HDFS 上传hdfs dfs -put 本地文件 /目录上传到 HDFSConda 建环境conda create -n env python3.9创建 Python 环境这张表远不是全部但已经覆盖了日常工作中 80% 以上的高频操作。剩下的 20%靠的是遇到具体问题时的搜索能力以及把答案沉淀到笔记里的习惯。8. 最后再分享一点我的个人习惯命令行这条路我最大的心得就是不要试图背下所有命令而是要建立一套“遇到问题 → 快速定位 → 解决 → 记录”的闭环。记录这件事以前我用文本文件后来改用 Markdown 笔记现在直接维护一个自己的速查脚本仓库。每次遇到新的问题我先搜索、再实践跑通了就顺手把命令整理进笔记里加一行注释说明是解决什么问题的。一年下来这份“个人使用-常用命令”清单已经积累了几百条条目涉及 Linux、Git、Docker、K8s、Nginx、HDFS、Conda、ADB、MATLAB 等各式各样的工具。另一件让我受益很深的事是所有命令我都尽量在本地虚拟机里先跑一遍确认无误后再到生产环境操作。命令行工具本身不会犯错犯错的是人敲错参数、选错目录、搞错环境这类低级错误谁也避免不了。多一层验证就少一次事故。最后一个小技巧把最常用的命令做成一页纸速查表打印出来贴在显示器旁边。别小看这种“原始”的方式在终端里折腾半天查命令的时间远比你抬头看一眼纸条多得多。你的命令行功底不是看你会多少命令而是看你在关键时刻能不能又快又准地用对那一条命令。