写这篇东西的起因很简单：之前带过几个刚转 Python 开发的同事，代码写得挺溜，一到服务器上就卡壳。不是不会写程序，是不会用 Linux 命令。程序在自己电脑上跑得好好的，一部署到 Linux 服务器上就出各种幺蛾子——找不到路径、权限不够、进程莫名其妙挂掉、日志不会看、端口被占也搞不清楚。回头看，其实不是业务逻辑的问题，就是 Linux 基础不扎实。这篇文章就把我这些年做 Python 开发时真正高频用到的 Linux 命令梳理一遍，不整那些一年用不上一次的花哨参数，全部是日常工作里实实在在能派上用场的操作。
Python 程序员跟 Linux 打交道是绕不开的。线上服务器基本都是 Linux，CI/CD 跑在 Linux 上，容器、数据库、消息队列这些基础设施也基本都在 Linux 上。掌握这些命令不是为了当运维，是为了让开发过程更顺畅、出问题时能自己快速定位。这篇内容适合刚入门或者工作一两年的 Python 开发者，也适合准备运维方向面试的朋友。下面我按实际场景来拆，每个场景配命令、配用法、配我在实践中踩过的坑。
1. 先想清楚：Python程序员到底需要哪些Linux命令
1.1 命令的本质是解决问题，不是背字典
很多初学者学 Linux 命令是照着命令大全从头背到尾，今天背了 ls 明天背 cp，背完就忘。我自己的经验是，命令不需要也根本没法全记住，关键是要形成一个“场景到命令”的映射感。遇到什么事，能想到该用哪类工具，具体参数忘了就man查一下或者搜一下，这才是真实的工作方式。
对 Python 程序员来说，最常遇到的场景其实就那几个：文件在哪里、文件里面写了什么、程序跑起来没有、程序为什么挂了、服务通不通、资源够不够。把这六个问题解决了，日常工作就顺了一大半。剩下的都是用的时候现查。我见过有同事在服务器上习惯性敲dir，显然是把 Windows 的习惯带过来了。每次遇到这种情况我都建议他们先放下“背命令”的念头，转而去理解“我这个操作是要达成什么目的”。
1.2 Python开发者的三个高频Linux场景
第一个场景是开发调试。你 SSH 到一台服务器或者容器里，要拉代码、装依赖、改配置、跑脚本。这个过程涉及的命令就是目录切换、文件查看、文本编辑、Python 虚拟环境激活、pip 安装。这个场景贵在“快”，每天要重复几十次，能敲少一个字都是效率。
第二个场景是线上排障。程序部署上去之后崩了，或者跑着跑着把 CPU 打满了，你要去看进程还在不在，看日志报了什么错，看端口有没有监听，看内存到底够不够。这个场景贵在“准”，你要能在最短时间内把问题范围缩小到某个模块甚至某一行。
第三个场景是部署与自动化。把服务配置成开机自启、定时跑脚本、批量同步文件、远程拷贝产物。这个场景贵在“稳”，一套配置写好之后要能长期可靠运行，不能今天能用明天就不能用。
下面的章节就按这三个场景展开，把每类命令的选型逻辑和实操要点讲透。
2. 高频文件操作与导航命令
2.1 看文件和找文件：ls、find、tree
进到一台新服务器上，第一件事永远是搞清楚“我在哪、这里有什么”。pwd看当前路径，ls看目录内容，这是最基本的。我习惯上来先执行ls -lh，-l显示详细信息、-h把文件大小转成人类易读的 K、M、G 单位，比裸的ls好用太多。如果目录层级很深，显示全部文件可以加-a把隐藏文件也带出来。Python 项目的虚拟环境目录.venv、配置文件.env都是隐藏文件，不带-a看不到。
找文件是另一个高频需求。你记得项目里有个config.py但忘了在哪个子目录，可以用find . -name "config.py"在当前目录递归搜索。这个命令很强大，但要注意范围，直接在根目录/跑find会扫很久，最好先切到疑似目录再搜。还有个比 find 用起来更顺手的命令是tree，它能以树状结构打印目录层级，新接手一个项目时看一眼tree -L 2就能快速摸清项目结构。不过部分精简版系统不带 tree，需要自己装一下。
搜索还可以更灵活。find . -name "*.py" -mtime -1能找出最近一天内修改过的 Python 文件，排查“我明明改了代码为什么没生效”这类问题特别有用。find . -size +100M能找出超过 100MB 的大文件，清理磁盘时必备。
2.2 看文件内容的四个工具
看文件内容有四个常用命令：cat、less、head、tail。cat适合看小文件，整个文件内容直接打到屏幕上。less适合看大文件，支持上下翻页、搜索、跳转，按/输入关键词就能搜索，按q退出。我几乎不用cat看大文件，因为日志文件动辄几百 MB，cat一次全打到终端会让终端直接卡死，如果误对超大文件执行了cat，按Ctrl+C可能都无法中断，只能关掉终端窗口。
head -n 20看文件头 20 行，tail -n 20看文件末尾 20 行，tail -f则是实时跟踪文件追加的内容。tail -f是排查线上问题的神器，比如你有个 Python 服务在写日志，执行tail -f app.log就能实时看到每一条新日志。配合后面的 grep 使用，效果立竿见影。这里有个技巧：tail -f在跟踪完问题后按Ctrl+C退出即可，不会影响服务本身。
2.3 复制、移动、删除与打包
文件操作里最容易出事故的就是删除。rm -rf这个组合是网上流传最广的“删库跑路”段子，现实中我也见过同事在服务器上误删了整个项目目录。我的建议是：在服务器上非必要不用rm -rf，非要删东西的时候先ls确认路径再操作，或者干脆用mv 文件 /tmp/把要删的文件移动到临时目录，观察几天确认没问题再清理。移动比删除安全得多，这个习惯能救你很多次。
复制和移动本身没什么复杂的，cp -r source_dir dest_dir递归复制目录，mv old_name new_name重命名。真正要留意的是跨服务器复制，这个放到后面的网络章节详细讲。打包解包也是高频操作：tar -czvf archive.tar.gz dir/打包并压缩，tar -xzvf archive.tar.gz解压。看到-c是 create（创建）、-x是 extract（解压）、-z是 gzip 压缩、-v是 verbose（显示过程）、-f指定文件名。你不需要死记，但遇到.tar.gz、.zip结尾的安装包要能解压。Python 源码安装、模型文件分发、日志归档都会用到 tar。
3. Python开发环境与依赖管理
3.1 Python版本与虚拟环境管理
Python 程序员上到 Linux 服务器，第一关就是 Python 环境。很多服务器自带的是 Python 3.6 或者 3.8，而你的项目要求 3.10 甚至 3.11，版本不对直接跑不起来。这时候我推荐用pyenv管理 Python 版本，它让你能在同一台机器上安装多个 Python 版本，并且随时切换。
pyenv install 3.11.9 pyenv global 3.11.9 # 或者在某个项目目录下使用指定版本 pyenv local 3.11.9pyenv local会在当前目录生成一个.python-version文件，团队协作时大家进到项目目录自动切到约定版本，非常省心。
虚拟环境是另一个必须养成的习惯。Python 项目的依赖互相之间很容易冲突，这个项目要 Django 4，那个项目要 Django 3，不隔离的话天天打架。在 Linux 上创建虚拟环境就一行命令：
python3 -m venv .venv source .venv/bin/activate激活之后你敲python用的就是虚拟环境里的解释器，pip安装的包也只会进到当前虚拟环境，不会污染系统环境。这里有一个特别容易踩的坑：每次新开一个终端窗口，虚拟环境都要重新激活一次。很多人在本地 Windows 上用的是 IDE 自动加载虚拟环境，到了服务器上手动操作就总忘记这步，然后看到ModuleNotFoundError就开始怀疑人生。解决办法是把激活命令写进项目的启动脚本里，或者用direnv这类工具在进入目录时自动加载环境。
3.2 包安装的常见姿势与坑
装 Python 包的命令本身很简单：pip install requests。但有几个问题非常常见。第一个是权限问题，直接pip install装在系统级路径时提示Permission denied，解决方案是不要用 sudo 去强装，而是创建虚拟环境再装，虚拟环境装包不需要管理员权限，也避免破坏系统 Python。
第二个问题是下载速度慢，国内网络尤其明显。解决方式是换镜像源：
pip install -i https://pypi.tuna.tsinghua.edu.cn/simple requests或者全局配置一次，在~/.pip/pip.conf里写入：
[global] index-url = https://pypi.tuna.tsinghua.edu.cn/simple第三个问题是装到一半报错，常见原因是缺少编译依赖。比如装pandas、numpy这类含 C 扩展的包在某些环境下会尝试源码编译，需要系统里有 gcc 和相关头文件。这时候别硬刚，先看报错信息里有没有gcc、python3-dev这类提示，缺什么装什么。
最近一两年我身边越来越多人在用uv替代 pip，它的核心优势是快，极快地解析依赖并进行并行安装。uv pip install可以直接在现有虚拟环境里安装，也能配合uv venv创建环境。如果你频繁在新机器上部署 Python 项目，值得试一下。日常开发里养成把依赖写成requirements.txt或pyproject.toml的习惯，配合pip freeze > requirements.txt导出版本，部署时才不会出现“在我电脑上能跑”的尴尬。
3.3 让程序在后台跑起来：nohup
Python 服务跑起来最常遇到的问题是：直接在终端执行python app.py，一关终端窗口程序就死了。原因是终端关闭时会给进程发送 SIGHUP 信号，进程默认就退出了。最简单的解决方案是nohup：
nohup python app.py > app.log 2>&1 &拆开解释，nohup让进程忽略挂断信号，> app.log把标准输出重定向到日志文件，2>&1把错误输出也合并到同一个日志文件，最后的&让命令在后台运行。这样关掉终端，程序也不会停。
比 nohup 更规范的做法是用systemd把 Python 服务注册成系统服务。在/etc/systemd/system/myapp.service里写配置文件，设置 ExecStart、WorkingDirectory、Environment，之后就能用systemctl start myapp、systemctl status myapp、systemctl enable myapp管理服务的生命周期，还能实现开机自启和崩溃自动重启。上生产环境的服务我基本都用 systemd，因为它有完整的日志管理、重启策略和依赖关系处理。下面是基本配置：
[Unit] Description=My Python Service After=network.target [Service] Type=simple User=www-data WorkingDirectory=/opt/myapp ExecStart=/opt/myapp/.venv/bin/python app.py Restart=always RestartSec=5 Environment=PYTHONUNBUFFERED=1 [Install] WantedBy=multi-user.target注意 ExecStart 里用的是虚拟环境的 Python 绝对路径，不是裸的python，这样能确保跑的是项目对应版本的解释器，而且不依赖 PATH 环境变量。
4. 文本处理三剑客：grep、sed、awk
4.1 grep：日志里捞关键信息
排查 Python 程序问题，第一步永远是看日志。但日志文件那么大，不可能从头翻到尾，这时候grep就派上用场了。grep "Traceback" app.log能瞬间把报错信息所在的全部行抽出来，grep -n "ERROR" app.log还会带上行号，定位代码位置非常方便。
grep的高频用法我整理一下：
grep "关键词" 文件 # 基本搜索 grep -i "关键词" 文件 # 忽略大小写 grep -n "关键词" 文件 # 显示行号 grep -r "关键词" 目录 # 递归搜索目录下所有文件 grep -A 5 -B 5 "关键词" 文件 # 显示匹配行前后各5行-A和-B这两个参数特别适合看异常堆栈。Python 的Traceback往往有好几行上下文，只抓匹配行可能看不到关键的错误原因。我有一次排查线上接口超时，就是在日志里先grep "Timeout"找到时间点，再用-A 10看到完整的调用链，一下就定位到是某个第三方 SDK 内部超时设置太短，而不是我们业务代码的问题。
4.2 sed：批量替换与修改
刚上服务器时我喜欢用 vim 手动改文件，但文件多了或者替换内容重复时，手动改效率太低。sed就是做流式文本替换的工具。最经典的用法是把文件里的旧字符串全部替换成新字符串：
sed -i 's/old_string/new_string/g' config.py-i表示直接修改原文件，s是替换命令，g表示全局替换（不加 g 的话每行只替换第一个匹配）。比如你有个配置文件的数据库密码要改，或者把代码里所有的localhost改成服务器的实际 IP，一行命令就能搞定，不用打开编辑器一个个找。
前面 grep 的-A-B只能看匹配行的上下文，如果要精确地从某一行提取内容，sed -n '10,20p' app.log能打印第 10 到第 20 行。这个用法在排查“日志写到第几行就断了”的时候特别有用。sed还有很多高级玩法，但日常开发掌握这几个就是够用的状态。初期不用硬背，知道“存在一个能批量改文本的工具”，等真遇到场景时查一下具体参数，比自己硬扛高效得多。
4.3 awk：按列处理与统计
第三个工具是awk，它的强项是处理“按列组织的文本”。比如日志里记录的是2024-01-15 10:23:45 INFO 请求耗时 123ms，你想统计所有请求耗时的平均值，awk就是直接的答案：
awk '{print $NF}' app.log | awk '{sum+=$1} END {print sum/NR}'更实用的场景是直接提取某一列数据。awk '{print $1}' access.log打印第一列，awk -F',' '{print $2}' data.csv按逗号分隔并打印第二列。Python 程序员写爬虫或者处理数据集时，经常需要快速查看 CSV 文件的某列内容，不用启动 pandas，一条 awk 就解决了。
awk 还能做条件过滤：
awk '$3 > 1000 {print $1, $3}' app.log这行的意思是：如果第三列的数值大于 1000，就打印第一列和第三列。配合日志里的耗时字段，可以快速找出所有慢请求的来源 IP。我发现很多 Python 开发者习惯什么问题都用 Python 脚本解决，当然没问题，但在服务器上临时排查时，敲一条 awk 显然比写个 py 脚本再执行要快得多。不要把 awk 当洪水猛兽，它就是“命令行里的表格工具”，核心价值是让你不用打开文件编辑器和写脚本，就能快速提取信息。
5. 进程管理、系统监控与日志排查
5.1 看进程和资源：ps、top、free、df
程序跑起来之后，下一步就是监控它好不好。ps是查看进程状态的最常用命令，我习惯用ps aux查看所有进程的详细信息，输出里包含用户、PID、CPU 占用、内存占用、启动命令等。ps aux | grep python能过滤出你关心的 Python 进程，看一下它到底还在不在跑。有人会问，不是有个pgrep吗？确实有，但配合 grep 能看到完整命令行信息，更直观。
top是实时版的进程监控，每三秒刷新一次，显示 CPU、内存占用最高的进程排行。进入 top 界面后按Shift+P按 CPU 排序、按Shift+M按内存排序。服务器出现卡顿，第一步就是跑个top看看到底是谁在吃资源。我在之前的公司遇到过线上 Python 进程内存泄漏的问题，就是靠top观察发现 RSS 内存占比持续增长，最终确认是缓存对象没有释放，逐行查代码找到了根因。
看内存还有个专用命令free -h，-h参数同样是为了可读性。输出里要重点看available那一列，而不是free列，因为 Linux 会用空闲内存做文件缓存，free显示的数字往往很小，实际上可用内存很充足。磁盘情况用df -h查看，每个挂载点的使用率一目了然。Python 程序写日志、写临时文件时如果磁盘满了会报No space left on device，这个错误在线上不算罕见，排查时先跑df -h心里就有数了。
5.2 杀进程与看端口：kill、ss、netstat
开发时最频繁的一个操作是“重启服务”。找到进程 PID，杀掉，重新启动。杀进程的命令是kill PID，默认发送 SIGTERM 信号，让进程优雅退出。如果进程死活不退，kill -9 PID发送 SIGKILL 强制杀死。我见过不少新人上来就kill -9，其实这不是个好习惯，强制杀进程会跳过清理逻辑，可能导致数据没落盘、临时文件没删、端口没释放。优先用默认kill，等几秒没退再考虑kill -9。
端口占用是另一个高频问题。启动服务时提示“端口被占用”，就要查是谁占了这个端口。新版系统推荐用ss命令，老系统用netstat，用法类似：
ss -tlnp | grep 8080-t显示 TCP 端口，-l显示监听状态，-n不解析主机名显示数字地址，-p显示对应的进程 PID 和名称。一条命令就能看到 8080 端口被哪个进程占着，然后去ps查询那个 PID 是谁，决定是停掉旧服务还是换端口。
5.3 日志实时跟踪：tail 与 journalctl
日志说了很多次，但这里要专门提一下journalctl。如果你用 systemd 托管 Python 服务，服务日志会被 systemd 收集，这时候可以直接用journalctl查看：
journalctl -u myapp -f-u指定服务名称，-f实时跟踪。好处是不需要程序自己写日志文件也不怕日志丢失，systemd 已经帮你统一管好了。journalctl --since "1 hour ago"还能按时间范围过滤日志，排查问题非常方便。
配合前面提的grep，journalctl -u myapp | grep Traceback能在最近的日志里快速定位 Python 异常。日志这块的核心思路是：无论用文件日志还是 systemd 日志，要养成“先看日志再猜原因”的习惯。很多 Python 线上故障，错误信息就明明白白写在日志里，只是之前没人去看而已。
6. 网络排查与文件传输
6.1 curl：调试接口必备
Python 程序员调试 HTTP 接口的日常工具肯定是 requests 或者 httpx，但服务器上临时验证一个接口通不通，写一段 Python 脚本就太重了，curl是更轻量的选择。
curl -v http://localhost:8000/api/health curl -X POST -H "Content-Type: application/json" -d '{"key":"value"}' http://localhost:8000/api/submit-v打印详细信息，包括请求头和响应头、TLS 握手细节，是排查接口问题的第一个命令。-X指定请求方法，-H加请求头，-d带请求体。我经常用 curl 验证本地服务起没起来、线上服务的健康检查是否返回 200、反向代理有没有配好。curl -I只打印响应头，curl -o /dev/null -w "%{http_code}" URL只看状态码，写脚本做自动检查的时候相当好用。
有个细节：Python 的服务框架默认都是监听127.0.0.1，如果你在服务器本机用 curl 访问没问题，但从另一台机器访问不通，那大概率是配置文件里绑定了127.0.0.1而不是0.0.0.0，这个坑我踩过不止一次。
6.2 端口连通性排查：ping、telnet、nc
服务器之间互相访问不通，第一个要确认的是网络通不通。ping 目标IP测试基本的 ICMP 连通性。但很多云服务器默认禁 ping，ping 不通不代表服务不通，这时候就要测试 TCP 端口。
telnet 主机 端口是最简单粗暴的端口连通性测试，能连上会显示连接成功，连不上会报超时或拒绝。不过现在很多系统默认没装 telnet 客户端，更通用的替代品是nc：
nc -zv 目标IP 端口-z只扫描不发送数据，-v显示详细信息。这个命令在排查数据库连不上、Redis 连接超时这类问题时极其常用。有一次我们开发环境的 MySQL 从某个 Python 服务连接不上，我先在服务所在的机器上nc -zv mysql主机 3306，发现端口是通的，于是把问题定位到账号权限，而不是网络层面。
这里要多说一句：排查网络问题一定要分层。先确认 IP 通不通，再确认端口通不通，再确认应用层接口通不通。每一层都有对应的命令，别上来就直接怀疑代码，一层一层排除最有效率。
6.3 跨机器传输文件：scp、rsync
本地文件和服务器文件之间的拷贝也是高频需求。最简单的工具是scp：
scp local_file.py user@服务器IP:/opt/app/ scp -r local_dir user@服务器IP:/opt/app/-r递归复制目录。scp的缺点是每次都是全量复制，文件多了或者改了其中几个，每次都拖全部文件过去就太浪费了。更好的方案是用rsync：
rsync -avz ./app/ user@服务器IP:/opt/app/-a归档模式保留文件属性，-z传输时压缩，-v显示过程。rsync 最大的优点是增量传输，只同步有变更的文件，尤其在日志量大的场景下同步效率高很多。我部署 Python 项目时，一次代码更新往往只有几个文件变了，rsync 只需几秒就能完成同步，scp 可能要传完整包。
如果你有大量文件要互传，还可以考虑lrzsz的rz/sz，但那是交互式的，更适合小文件，跟 scp/rsync 的适用场景不完全一样。平时记住 scp 和 rsync 这两个就够了。
7. 权限、用户与终端配置
7.1 理解Linux权限模型：chmod、chown、sudo
上到服务器执行命令时会遇到Permission denied，新人常有的反应是加 sudo，但我建议先理解权限模型。Linux 权限分三组：文件所有者（user）、所属组（group）、其他人（other），每组又分读（r=4）、写（w=2）、执行（x=1）三种权限。
修改权限的命令是chmod。最常见的chmod +x script.sh给脚本加执行权限，chmod -R 755 目录递归设置目录权限。数字的含义很好记：7=4+2+1 完整权限，5=4+1 读+执行，6=4+2 读+写。Python 项目里.sh部署脚本经常要chmod +x才能执行，这是新人遇到最多的问题之一。
修改文件所有者的命令是chown，比如chown -R www-data:www-data /opt/myapp把项目目录归属给 web 用户。常用的场景是：用 root 用户部署了代码，但服务是用普通用户身份运行的，代码目录权限不对，程序就写不了日志文件，会报权限错误。
顺带讲一下sudo的使用原则。sudo 是“以其他用户身份执行命令”，默认是 root。它能让你做系统级操作，但同时也意味着更大的风险。我的原则是：日常操作尽量用普通用户，需要安装系统包、修改系统配置时才用 sudo。千万别什么事都sudo一把梭，用 root 跑 Python 服务更是要避免——一旦代码有漏洞，攻击者拿到的就是 root 权限，这不是开玩笑的事。
7.2 用好 .bashrc：配置你的命令行效率
终端环境的配置对效率的影响被很多人低估了。每次登录 Linux 服务器都会加载~/.bashrc这个文件，把你的个性化配置放进去，一劳永逸。
我自己的.bashrc里至少有这些内容：
alias ll='ls -alF' alias la='ls -A' alias python='python3' alias pip='pip3' export PATH="/opt/.venv/bin:$PATH"alias是命令别名，ll替代冗长的ls -l，python直接映射到 python3，省得每次手滑敲成python然后提示找不到命令。你还可以为项目设置快捷方式，比如alias proj='cd /opt/myapp && source .venv/bin/activate'，一条命令进入项目目录并激活虚拟环境。
如果经常用 Git 管理代码，在.bashrc里设置合理的PS1提示符能让你随时看到当前所在分支和目录。网上有很多现成的 PS1 配置，直接抄一份改改就行。我见过有人喜欢用 zsh 加 oh-my-zsh，确实好看，但在很多精简服务器环境里没有 zsh，bash 加上几条 alias 已经足够提升效率。
7.3 终端命令行编辑基础：vim 与快捷操作
提到终端配置，就绕不开 vim。虽然 Python 程序员本地开发基本都用 IDE，但上了服务器，很多时候你只能靠 vim 改文件。不用学很深的 vim 操作，掌握这几个就够日常使用了：vim 文件打开文件；i进入插入模式；编辑完按Esc，输入:wq保存退出，输入:q!不保存强制退出。再进阶一点，按/关键词在文件里搜索，按dd删除当前行，按yy复制当前行、p粘贴。就这么几个操作，覆盖了服务器上 90% 的文本编辑需求。
很多人会用nano代替 vim，因为 nano 底部的快捷键提示更直观。我没有强烈的偏好，但如果你经常操作远程服务器，建议至少把 vim 的这几个基本操作练熟，因为 vim 是任何 Linux 环境默认都有的编辑器，nano 不一定。在服务器上改代码，原则上是能少改就少改，重要改动前先备份原文件，cp app.py app.py.bak是我的习惯，一行命令给自己留条后路。
8. 面试与实战：把命令串成思路
8.1 运维与开发面试中最常问的几个命令问题
以前准备面试时整理过一批 Python 开发者岗位和运维开发岗位的高频 Linux 面试题，这里挑几个典型的说一说。
第一个：“你如何查看某个端口是否被占用？”这个问题看似简单，但能区分出有没有实践经验。标准回答是用ss -tlnp | grep 端口号或者netstat -tlnp | grep 端口号，重点是记得带-p参数，因为面试官通常接着会问“那你怎么知道是哪个进程占用的”，-p正好回答了这一步。
第二个：“线上服务 CPU 占用 100%，你怎么排查？”完整思路是：先用top找到 CPU 最高的进程 PID，然后用top -Hp PID查看该进程下哪个线程最耗 CPU，再用 Python 的faulthandler或者直接看线程 ID 转换成十六进制后到py-spy dump --pid PID查看对应线程的 Python 堆栈。这套思路的核心是“从系统层到应用层逐层聚焦”，而不是瞎猜代码哪里有问题。py-spy或pystack是 Python 性能排查的神器，建议提前了解。
第三个：“服务器磁盘满了，你怎么找到大文件？”不能只靠df -h知道满了，还得定位到具体文件。du -sh *按目录统计占用空间，du -ah 目录 | sort -rh | head -20找出目录下最大的前 20 个文件，find / -size +1G直接找大于 1GB 的文件。这道题考的就是组合使用命令解决问题的能力。
8.2 一个完整的真实排查案例：Python服务告警
把上面这些命令串起来的典型场景是：某天下午，监控告警提示线上 Python 服务响应变慢。我先 SSH 到服务器执行top，看到 python 进程 CPU 占用 98%。然后ps aux | grep python确认是哪个项目的进程，接着journalctl -u myservice -f看实时日志，没发现异常报错。于是用py-spy dump --pid 12345看线程堆栈，发现大量线程卡在requests.post的调用上。再查日志里对应时间段的访问记录，确认是某个上游回调接口变慢了，导致 Python 进程线程池被打满。最后用tail -f跟踪确认上游接口恢复后服务自动恢复。整个过程没有改一行代码，就是靠命令逐层定位。
这个案例想说明一件事：Linux 命令不是孤立的知识点，它们是排查问题时的线索链。单看top只知道 CPU 满了，配合ps知道是哪个进程，配合日志知道在做什么，配合堆栈才知道堵在哪。这个思维模式比记住任何单独的命令都重要。
8.3 快速构建排查命令组合：一个建议的脚本
排查思路固定下来之后，可以写一个短小的排查脚本放到.bashrc或者 alias 里。比如我常用的一个组合：
alias pycheck='ps aux | grep python | grep -v grep; ss -tlnp | grep python; journalctl -u myservice -n 50 --no-pager'一条命令查看所有 Python 进程、监听端口和最近 50 行服务日志。排查常规问题先跑一圈，心里有底再深入。这个习惯帮我节省了大量重复敲命令的时间，也避免了漏看关键信息。你可以根据自己的服务名改掉myservice，就是一套专属的快速体检工具。
9. 避坑经验与心得总结
9.1 我踩过的几个典型坑
先说说rm -rf的教训。有一年在一台测试服务器上清理临时目录，想删掉/tmp/old_cache/，不知道怎么就把~敲进去了，结果删掉了root用户的家目录。当时慌得不行，后来靠系统自动备份恢复了一部分文件。这个教训让我养成了一个习惯：在服务器上不使用 root 账户做日常操作，删除前必须 ls 确认路径，能不用 rm 就不用 rm。
第二个坑是pip install装到了系统 Python。在没激活虚拟环境的情况下执行了 pip install，结果把服务器系统 Python 的环境搞乱了，最后只能重装系统。这个问题的根因还是没有养成“先建虚拟环境再装依赖”的习惯。现在我在任何 Linux 服务器上拿下一个 Python 项目，第一步永远是python3 -m venv .venv && source .venv/bin/activate。
第三个坑是tail -f挂起太多进程。有段时间在多个服务上同时挂 tail 跟踪日志，终端一开一大堆，后来忘了关，服务器上一堆 tail 进程占着资源。虽然 tail 进程很轻，但数量多了也是一笔开销。教训是：用完就关，能用journalctl --since查历史日志的就不开实时跟踪。
9.2 给Python开发者的命令学习路径建议
如果你现在刚开始接触 Linux，我的建议是不要追求背完整本命令手册，先掌握这一条主线：能进入一个目录并查看文件 → 能看懂文件内容 → 能运行 Python 脚本 → 能查看脚本日志 → 能根据日志定位问题 → 能停掉出问题的进程 → 能用 systemd 托管服务让程序稳定运行。这条主线的每一步都是实际工作中逃不开的操作，把每一步的命令练熟，你已经能解决 80% 的日常工作。
再进一步，学grep、sed、awk这组文本处理工具，它们能让你从“看日志”进化到“分析日志”。再往后，学rsync、curl、systemd、journalctl这些涉及部署和任务管理的命令，你的能力就不再局限于“写代码”，而是能独立把一个 Python 项目部署到 Linux 服务器上并稳定运行。
9.3 最后再分享一个小技巧
很多人不知道history命令可以回看自己之前执行过的所有命令。我有一次要复现一个线上操作，但想不起当时到底用了什么参数，直接history | grep python找到了历史命令。还有!python可以直接执行最近一条以 python 开头的历史命令，省得重新敲一长串。这些细节并不起眼，但在实际工作中确实能节省不少时间。
如果你常在一台服务器上工作，认真配置一次.bashrc，把 alias 和环境变量都提前设好，后续每次登录都会受益。如果跨多台服务器，网上搜一下怎么配置免密钥登录，能省掉每次输密码的麻烦。
Linux 命令这个主题说起来可以无穷无尽，但真正值钱的永远是那些每天都用、能帮你解决问题的部分。从一个普通 Python 开发者到一个能在 Linux 环境里游刃有余的工程师，差别不在于背过多少命令，而在于遇到问题时能不能顺着命令的思路一步步把根因找到。希望这篇内容能给你一条清晰的路径，让你少走一些我当年走过的弯路。
