Python开发者必会的Linux命令：从项目初始化到线上排障

1. 开篇：为什么Python开发者离不开Linux命令

说实话，我接触过不少Python开发者，有人写Python两年了，还是习惯在Windows上做开发，一提到Linux就有点抵触。但真正开始部署项目、处理线上问题之后，几乎所有人都绕不开Linux命令这道坎。就算你平时只在本地写脚本，只要你需要跑定时任务、管理虚拟环境、查看日志、调试并发问题，迟早要跟Linux打交道。

这篇文章要聊的，就是Python程序员的日常工作中真正用得上的Linux命令。不搞那种一长串冷门参数堆砌的清单，而是从实际场景出发：初始化一个项目需要什么，写代码过程中怎么快速定位问题，上线部署时怎么管理服务，出故障时怎么排查性能瓶颈。每一步都给出具体的命令、参数含义、常见坑点，让你看完可以直接照着用。

适合三类人：刚接触Linux的Python初学者，能跑通代码但一部署就慌的开发者，以及想系统梳理自己常用命令的进阶学习者。如果你已经能熟练使用vim和grep，这篇文章的排查思路部分可能对你也有参考价值——毕竟命令就那么几个，真正值钱的是“什么场景下用什么命令”的判断力。

2. 环境操作：从零搭好Python项目的基础

2.1 文件与目录管理的几个高频命令

Python项目刚起步时，无非就是创建目录、移动文件、查看项目结构。这几个命令我每天都要敲无数遍：

mkdir -p /home/user/projects/myapp/{utils,tests,scripts}

-p参数的意思是“递归创建父目录”，也就是说如果上一级目录不存在，也会一并创建。花括号展开是bash的语法糖，一条命令能创建多个子目录，免去重复敲mkdir的麻烦。

tree -L 2

这个命令不是Linux自带的，需要装一下（apt install tree或yum install tree），但对Python项目来说非常好用。它能以树状图展示目录结构，-L 2表示只显示两层深度，用来快速确认项目骨架是否合理，比在编辑器里翻来翻去直观得多。

du -sh *

当你发现项目目录越来越大，想知道是不是node_modules或者__pycache__在膨胀，可以用这条。du是磁盘用量统计，-s是汇总，-h是人类可读格式，后面跟的*表示统计当前目录下每一个子项。我经常在清理磁盘的时候用它，一眼就能看出哪个目录占了几个G。

文件操作里还有个容易被忽视的场景：批量重命名。Python项目里经常会有v1、v2这种接口文件，手动mv一个个改太笨了。我用的是：

for f in *_old.py; do mv "$f" "${f%_old.py}_new.py"; done

${f%_old.py}是bash的字符串截取语法，意思是去掉结尾的_old.py部分。这条循环会匹配所有以_old.py结尾的文件，把它们改名为对应_new.py。注意引号一定要加，如果文件名里有空格，不加引号会把文件名拆成多个参数。

2.2 虚拟环境与Python版本的安心之选

每个Python项目都要建虚拟环境，这个步骤我刚入行的时候吃过亏——直接在全局环境里pip install，结果两个项目依赖的包版本冲突，升级一个把另一个搞挂了。从那之后，新建项目的习惯就固定成了：

python3 -m venv .venv source .venv/bin/activate

venv是Python自带的虚拟环境模块，.venv是约定俗成的目录名。激活之后，命令行前面会出现(.venv)前缀，这时候pip install只影响当前环境，不会污染系统Python。

但如果你是新手，可能还会踩另外一个坑：系统里可能同时有python、python3、python3.11这些命令版本不一致。稳妥的做法是用which python3确认路径，或者直接在项目里用绝对路径调用解释器。

如果你需要管理多个Python版本（比如有的项目要3.8，有的要3.11），我推荐用pyenv。它能在用户目录下编译安装多个Python版本，然后用pyenv local 3.11.9来切换。相比手动下载源码包配置，pyenv的体验顺畅得多，但要注意它通过shell插件改变PATH，需要把eval "$(pyenv init -)"加到bashrc里才能生效。

2.3 pip的镜像配置与离线迁移

pip install的时候，国内直连官方源慢到下不动，这个问题应该不止我一个人遇到过。解决办法是配置镜像源，在命令行临时指定：

pip install requests -i https://pypi.tuna.tsinghua.edu.cn/simple

这是临时生效的方式。如果想一劳永逸，可以修改配置文件。Linux下pip的配置文件路径是~/.config/pip/pip.conf，写入：

[global] index-url = https://pypi.tuna.tsinghua.edu.cn/simple extra-index-url = https://mirrors.aliyun.com/pypi/simple

这样之后每次pip install都会走镜像。extra-index-url可以追加多个备用源，当主源里没有某个包时，会去备用源找。

另外提一句离线迁移依赖的场景。内网服务器不能联网时，可以用pip download把包下载到本地：

pip download -r requirements.txt -d ./packages -i https://pypi.tuna.tsinghua.edu.cn/simple

然后到目标机器上pip install --no-index --find-links=./packages -r requirements.txt。实测下来稳定，尤其适合部署在隔离网络里的服务。

3. 代码调试与进程管理：让Bug无处遁形

3.1 用grep快速锁定问题代码

代码写多了，总会在一个几十万行的大项目里找某个函数、某个配置项。通读全文不现实，编辑器自带搜索也行，但在命令行里grep是无可替代的：

grep -rn "cache_expire" --include="*.py" ./app

-r是递归，-n是显示行号，--include限定只搜Python文件。这样直接把所有包含cache_expire的地方列出来，带着完整路径和行号，跳转起来非常方便。

反向查找也常用：你只想确认某个废弃的接口还有没有代码在调用，可以搜更精确的片段。比如：

grep -rn "api/v1/legacy" --include="*.py" --exclude-dir=.venv .

--exclude-dir=.venv是排除虚拟环境目录，否则会把整个site-packages都扫一遍，慢且噪音大。这一步不加上，光扫第三方库就能把人吓到——你以为是谁在调用接口，结果全是requests的头文件。

</br如果日志文件特别大，直接grep会输出几千行，配合less做分页浏览更顺手：

grep "Traceback" app.log | less

less支持上下翻页、/关键字搜索、q退出。在长日志里翻找上下文的时候，这个组合比在IDE里加载整个日志文件轻快得多。

3.2 进程查看与内存占用的真相

Python程序跑着跑着占了多少内存，是不是有内存泄漏，这个问题想确认的话，第一反应应该是：

ps aux --sort=-%mem | head -20

ps aux列出所有用户进程，--sort=-%mem按内存占用降序排列。head -20只取前20条。看输出时注意CPU百分比那列，如果某个python进程的CPU飙到100%以上（多核下可能超过100%），那代码很可能有死循环或阻塞问题。

要确认一个Python进程具体在做什么，光看CPU和内存还不够，得看它的调用栈。这种情况下py-spy是个好工具，它能像打印日志一样，把正在运行的Python进程的堆栈dump出来：

py-spy dump --pid 12345

输出里能看到该进程当前执行到哪个文件哪一行，甚至能看到局部变量的值。对定位线上卡死问题，比gdb那一套要友好得多。py-spy需要在目标机器上安装，但它是逐进程注入的方式，对运行中的应用性能影响极小。

还有个细节：当你发现一个Python进程退不掉，尝试kill -9之前，先确认一下这个进程是不是有需要落盘的缓存。某些情况下kill -9会导致数据不一致。先kill（也就是kill -15）让进程走完清理逻辑，几秒后还没退再升级为kill -9。这个习惯在数据库、缓存服务上尤其重要，纯脚本倒是无所谓。

3.3 后台运行的几种方式和它们的分工

本地调试的时候，我们一般直接python3 app.py跑前台，但部署到服务器上之后，进程不能挂在SSH会话上——一旦连接断开，程序就没了。处理这个问题有几种方式，我分别说下适用范围。

最简单的是nohup：

nohup python3 app.py > app.log 2>&1 &

nohup让进程忽略挂断信号，> app.log把标准输出重定向到文件，2>&1把标准错误也合并进去，末尾的&表示后台运行。启动之后能用echo $!查看刚启动进程的PID，方便之后管理。

nohup适合快速起一个临时任务，比如临时跑个爬虫。但如果你的服务是要长期运行的，用systemd管它更规范。创建一个服务文件（比如/etc/systemd/system/myapp.service）：

[Unit] Description=My Python Service After=network.target [Service] ExecStart=/home/user/projects/myapp/.venv/bin/python app.py WorkingDirectory=/home/user/projects/myapp Restart=always RestartSec=5 [Install] WantedBy=multi-user.target

之后用systemctl start myapp、systemctl enable myapp实现开机自启。Restart=always表示进程意外退出时自动拉起，RestartSec是重启前的等待时间。这套配置下来，部署一台新机器的时候，不再需要手动nohup加cron守护，系统本身就把服务生命周期管住了。

</br注意：接触过很多开发者的做法是直接在容器里用nohup让主进程常驻，这个思路不能说错，但不推荐。容器的推荐做法是前台运行PID 1进程，由容器编排工具负责重启策略，把进程管理交给编排层，而不是在容器内部再套一层nohup。

4. 日志排查与性能分析：实操过程复盘

4.1 日志滚动与磁盘吃满的解法之一

Python项目跑久了，最怕的一件事就是日志文件膨胀。直接重定向到app.log，跑一个月可能涨到几十G，然后磁盘满了，服务挂掉，现场一片狼藉。

Linux自带的logrotate能解决这个问题。配置文件写在/etc/logrotate.d/myapp：

/home/user/projects/myapp/app.log { daily rotate 7 compress missingok notifempty copytruncate }

daily表示每天轮换一次，rotate 7保留最近7份，compress压缩历史日志节省空间，copytruncate复制当前日志后清空原文件——这个参数很重要，它允许程序不重启的情况下完成轮换，对Python脚本写的日志尤其友好。

配置完成后可以用logrotate -d /etc/logrotate.d/myapp做一次演练（dry-run），看输出的轮换流程是否符合预期。我第一次配置的时候忘了copytruncate，结果程序打开的文件句柄还指向旧日志，日志内容继续往已轮转的文件里写，排查了半天。这个坑大家注意。

4.2 实时观察日志的优雅姿势

排查线上问题时，实时推流日志几乎是刚需。tail -f是最常用的一招：

tail -f -n 50 app.log

-f是持续跟踪文件新增内容，-n 50是先把最后50行加载出来再开始跟踪。当你发一个测试请求，旁边的终端立刻能看到对应日志输出，判断流程走到哪一步，这个体验比事后翻日志舒服太多。

但tail -f只看增量，如果你想往回翻历史记录，就得配合less了。还有一个进阶用法是按时间窗口看：

awk '/2024-05-20 10:1[5-9]/' app.log | wc -l

比如要看10:15到10:19之间有多少条日志，awk按正则匹配时间戳，wc -l统计行数。虽然有点粗糙，但在没有专业日志平台的环境下，这种命令组合就是最趁手的工具。

4.3 CPU与内存性能分析的标准动作

性能问题比Bug更隐蔽。代码逻辑看起来都对，但接口响应越来越慢。这时候第一步不是去猜，而是先看整体资源状况。

top

top是交互式界面，会持续刷新显示CPU、内存占用最高的进程。快捷键中，按P按CPU排序，按M按内存排序，按c显示完整命令行。如果看到一个python进程CPU跑满，按下c看看它在用什么参数启动，基本能判断是哪个服务。

top太占整个终端了，如果想输出纯文本方便保存和比较，用下面这个：

top -b -n 1 | head -20

-b是批处理模式，-n 1只采样一次。这种方式适合写进脚本做定时监控，比如crontab里每分钟记录一次，事后对比CPU排序的变化趋势。

如果怀疑是Python代码自身的瓶颈，cProfile或py-spy是更深的工具。先用cProfile跑一个短时任务，生成统计报告：

python3 -m cProfile -s cumulative myscript.py

-s cumulative按累计时间排序，输出里能看到每个函数的调用次数和总耗时。定位到热点函数后，再去优化算法或者用缓存，效率高很多。cProfile对长时运行的服务影响较大，所以一般只在开发环境做一次分析，线上服务更推荐py-spy这种按需采样的方式。

另外我常用的还有vmstat和iostat，它们看的是系统级指标。vmstat 1 5每秒采样一次共5次，能看到CPU的us（用户态）、sy（内核态）、wa（IO等待）三项。如果wa非常高，说明磁盘IO是瓶颈，这时候再怎么优化Python代码都没用，得从存储层面想办法。

4.4 网络问题排查的基础三件套

接口超时、连接被拒、数据传不完整，这类问题的排查顺序我一般是：先确认目标端口通不通，再确认延迟，最后看丢包。

telnet 127.0.0.1 8000

如果端口开放，会进入连接成功状态，按Ctrl+]然后quit退出。如果连接被拒，立刻会看到Connection refused的提示，说明服务没监听这个端口或者防火墙挡了。telnet没有安装的话，用nc -zv 127.0.0.1 8000也能达到类似效果，-z只是扫描端口不发送数据。

延迟和丢包用ping看基础连通性，但ping测的是ICMP，和应用层的TCP/UDP还有差异。更贴近实际的判断用ss命令：

ss -tlnp | grep 8000

-t显示TCP，-l只显示监听中的连接，-n用数字显示端口，-p显示对应的进程名和PID。这一条能看到当前8000端口是被哪个进程占用的。遇到端口起不来的时候，先ss看端口是否还能被绑定，再判断是不是之前的进程没退干净，比盲目重启整个服务要精准。

5. 常见问题与排查技巧实录

5.1 常踩的坑一：Permission denied

Python脚本写好之后，直接python3 app.py运行没问题，但如果要跑某个可执行脚本，可能会遇到Permission denied。这不是语法错误，而是文件没有执行权限。解决方法：

chmod +x myscript.py

然后脚本第一行需要有shebang（#!/usr/bin/env python3），才能直接./myscript.py执行。如果不加chmod，也可以python3 myscript.py运行，但加入执行权限后，脚本就能像普通命令一样用，体验差别还是挺大的。

另外注意，如果你把项目放在/root目录下，普通用户访问会直接权限报错。开发项目的目录权限管理中，我习惯给项目目录设置775（owner和group可写，others只读），下面具体的敏感文件再单独收紧权限。chmod 777是图一时方便，但对线上服务来说是坏习惯——任何用户都能修改你的代码，安全隐患很大。

5.2 常踩的坑二：编码问题导致乱码或崩溃

Windows上写Python并在文件头声明# -- coding: utf-8 --，然后部署到Linux上，一切正常。但如果你用过中文文件名，或者读取Windows编码的CSV，Python在Linux下默认UTF-8，遇到GBK编码的内容就可能炸。

建议所有开发机上把环境变量统一为UTF-8。在~/.bashrc里加：

export LANG=C.UTF-8

确保Python解释器按UTF-8解码。如果是从Windows传过来的旧文件，先用file命令确认编码：

file -i old_data.csv

输出会指出charset是什么。之后再用iconv转换：

iconv -f GBK -t UTF-8 old_data.csv > new_data.csv

把GBK转成UTF-8。这条命令帮我处理过数次旧系统交接过来的数据文件，比在Python里折腾open(encoding='gbk')要快得多。

5.3 常踩的坑三：端口被占用和进程清理

开发时最经典的坑：上午跑的服务，下午重启时报端口被占用。多半是有个残留进程还握着端口。

lsof -i :8000

lsof列出打开的文件，-i :8000过滤到该端口的进程。输出里有PID和进程名，然后kill那个PID即可。如果不放心，再加个-9强制杀掉。但在杀之前先确认，这个进程到底是残留还是你另一个会话里正跑着服务——我误杀过自己的调试进程，一查才发现忘了还有另一个终端开着它。

如果lsof没装，备选方案是fuser：

fuser -k 8000/tcp

这个命令更暴力，直接杀占用该端口的进程。我劝你谨慎用，因为它不会提示确认。

5.4 常见问题速查表

6. 最后的实战心得

先说说我自己踩过的一次印象特别深的案例：某次线上服务每过几天就挂一次，重启就好，过几天又挂。一开始怀疑是代码内存泄漏，py-spy看了半天也没找到明显的循环引用。后来用dmesg看内核日志，发现是OOM Killer把进程杀了——但杀得不是我们的主服务，而是某个子进程，主服务因为子进程退出触发了异常连锁反应。

那个排查过程用到的其实就是这篇文章里出现过的：ps看进程状态、dmesg查内核日志、ss确认端口状态。工具都不复杂，但排查的关键在于“先怀疑系统，再怀疑代码”的意识。很多Python开发者习惯性先看自己的代码，这当然是对的，但不要忘了操作系统的层面可能已经给出了线索。

我的建议是：不要试图一次性背下所有命令的参数。真正高效的方式，是把常用命令整理成自己的速查笔记，按场景分类——环境搭建就记虚拟环境和pip相关，日常调试就记grep和ps，部署运维就记systemd和logrotate。用的时候查阅，用得多了自然就条件反射了。

这篇文章里的命令组合，基本覆盖了Python开发者从项目初始化到线上维护的完整路径。你不需要全部记住，先挑最贴近你当前工作状态的用起来，比如grep、ps、tail这三个，真正用熟之后，你会明显感觉到处理日常问题的效率提升了一个台阶。