ARTICLE · INTELLIGENCE

战地情报 · 详情页

来自尧图项目组的一线实战观察与深度解析

Python程序员必备的Linux命令实战指南:文件、进程、网络与环境

Python程序员必备的Linux命令实战指南:文件、进程、网络与环境 我见过太多Python写得溜的同事一坐到Linux服务器前面就开始露怯。写爬虫、跑训练脚本、部署服务平时在PyCharm里双击运行没啥感觉一旦要上服务器、看日志、查进程、调网络命令行就是绕不过去的坎。这篇文章不聊那些“Linux从入门到精通”的大而全只围绕Python程序员每天都会碰到的真实场景来拆文件操作、文本处理、进程管理、网络排查、环境安装。每一类我都给出最常用、最能救命的命令附带参数选择和踩坑记录读完可以直接照抄。开门见山先回答三个你肯定关心的问题这篇文章是什么它是给写Python的人准备的Linux命令实战手册内容围绕日常工作高频场景展开。能解决什么问题解决“我知道Python怎么写、但不知道怎么在Linux上跑起来、出了问题不知道怎么查”的尴尬。适合谁看适合刚接触Linux的Python开发者也适合会用Linux但想提升排查效率的中间水平选手。1. Python开发为什么绕不开Linux1.1 Python与Linux的生态绑定关系Python的很多核心应用场景——服务器后端、爬虫、数据分析、机器学习、自动化脚本——生产环境几乎都跑在Linux上。这不是巧合而是历史和技术演进的共同结果。拿爬虫来说你本地用requests和BeautifulSoup写完解析逻辑真正要稳定跑24小时抓数据还是得丢到一台Linux服务器上。那句话怎么说来着“本地能跑、服务器上一堆坑”最大的坑往往不是Python代码本身而是你对Linux系统的掌控力不足。再比如FastAPI、Django这类后端服务部署时用systemd写个service、用Gunicorn起worker进程、用Nginx做反向代理每一步都是Linux命令和配置文件的活儿。另外Python解释器本身在Linux上的表现也更纯粹。包管理、环境隔离、C扩展编译很多细节在Linux上处理得干净利落出了问题也好排查。Windows上装个MySQL-python、psycopg2或者涉及C扩展的库经常要跟编译器和预编译包折腾半天Linux上往往一个apt命令加pip install就完事了。1.2 Python程序员日常离不开Linux的四种真实场景我梳理了一下自己这么多年的工作基本上可以分成四类场景几乎覆盖了九成以上的需求。第一类是本地开发环境的搭建。装了双系统或者用了虚拟机、WSL的开发者每天都要在这个环境里安装Python、创建虚拟环境、写文件、跑脚本。第二类是远程服务器操作。代码写完推到Git仓库然后SSH登录服务器git clone、安装依赖、跑起来、看日志。整个流程一步都离不开Linux命令。第三类是线上问题排查。服务崩了、端口被占了、内存不够了、定时任务没执行这些全是Linux命令的活儿。第四类是数据处理和定时脚本。crontab挂定时任务、用shell脚本配合Python脚本做数据处理这种运维和开发混合的活儿命令熟练度直接决定效率。1.3 工具链的选型思路用终端思维做Python开发我以前也固执地认为IDE是效率最高的编码方式直到有一天被生产环境的问题逼着在Vim里改了一个配置文件才意识到在Linux上做Python开发效率高不高取决于你愿不愿意用“终端思维”去思考问题。什么意思呢IDE帮你做了很多事文件管理、搜索、一键运行、输出面板。但到了服务器上这些都没有。你需要自己用ls找到文件、用grep在代码库里搜关键词、用vim或nano改配置、用python3直接执行脚本、用tail盯日志。这种看似原始的交互方式一旦熟练起来效率反而高得多——因为你的每一步操作都是确定性、可复用、可脚本化的。所以我的建议不是让你抛弃IDE而是让你在终端里也能完成差不多的全流程操作。下面这些命令就是这套终端思维的地基。2. 文件和目录操作日常开发的地基2.1 定位与查看pwd、ls、find的实战用法文件操作里使用频率最高的说来说去就是几个pwd看当前路径ls列目录find按条件搜索。前两个太简单就不展开了真正有讲究的是find。比如你想找个3天内改过的Python文件在哪儿一条命令出结果find . -name *.py -mtime -3如果你想找到项目里所有大于50MB的文件用于排查为什么磁盘突然满了find / -type f -size 50M 2/dev/null这里有个小技巧加上2/dev/null可以把没权限访问的目录错误信息直接丢掉搜索结果清晰得多。找大文件这个方法我用了不知道多少次比在Windows资源管理器里右键排序快多了。还有ls本身也值得注意。ls -lh用人类可读的方式显示文件大小ls -lt按时间排序最新改过的文件排前面改文件后确认用这个非常方便。记这两个参数比死记ls -l的十列输出有意义得多。2.2 创建与删除mkdir、touch、rm的安全红线创建目录用mkdir -p这个参数可以递归创建多级目录比如mkdir -p /data/logs/2025/06甭管中间几级目录存不存在直接一把建好。这在项目初始化、创建日志目录的时候特别省事。删除操作就不得不认真聊聊安全红线了。rm -rf这个组合能删掉一切也能毁掉一切。我在生产服务器上见到过的和听说过的事故最有代表性的就是想删某个目录下的旧日志结果手一抖写成rm -rf /var/logs/多敲了一个斜杠或者一个空格然后就没有然后了。注意rm -rf后面跟着目录路径时务必先ls确认一次或者干脆用rm -r不带f参数让系统问一遍。还可以用ls通配符先看看要删除的文件列表长什么样确认无误再删。这一步多花三秒钟能避免你后悔三个月。还有个容易忽略的点软链接和rm -rf加斜杠的组合。大家记住一点——对软链接执行rm -rf link/删除的不是链接本身而是链接指向的目录里的内容。如果你只想删掉这个软链接要写rm link不带斜杠或者用unlink link。2.3 复制、移动与增量备份的细节复制文件和移动文件核心命令是cp和mv。Python开发里最常用的场景是上线部署把本地项目传上去或者备份旧的代码目录。cp -r project/ /data/app/project_backup_20250601 mv old_project/ new_project/cp -r处理目录递归复制mv在同一个文件系统内移动是秒级完成的跨文件系统移动就变成复制加删除大目录会明显感觉到卡顿。这里没有太多坑倒是推荐一个高级工具rsync。它是增量同步神器第一次全量拷贝之后只传变化的文件在日常备份和服务器间同步代码时效率远超scp手工拷贝。rsync -av --progress ./local_project/ userhost:/data/app/project/我最常用的是rsync -av做服务器上的代码备份特别是数据库文件、日志目录这类体积大、改动频繁的内容增量同步比整体打包快太多了。2.4 软链接虚拟环境和部署中的隐藏关键软链接符号链接是Linux文件系统里一个容易让新手懵、但Python程序员又避不开的概念。最常见的使用场景就是/usr/bin/python3这种默认命令指向一个具体的版本或者把某个数据目录、某个虚拟环境目录链接到项目路径下。ln -s /usr/local/python3.11/bin/python3.11 /usr/bin/python311创建软链接的完整逻辑是ln -s 真实位置 链接位置顺序千万别反。链接建立后直接执行python311就可以用指定版本的解释器了这在处理多版本Python共存时是常用操作。关于软链接怎么辨别用ls -l查看文件权限前面有l开头的就是链接。删链接用unlink或者rm不带斜杠这个我在上一节能避免的“坑”里已经详细说过了。3. 文本处理与日志分析比Python更快的三种方式Python程序员处理文本有个惯性思维写脚本。一行日志想看看某个状态码出现了多少次下意识就打开编辑器写Python循环。但Linux上有三个命令在绝大多数场景里比现写Python脚本快得多而且不用维护脚本文件用完即走。3.1 grep日志里找异常代码里搜关键词grep是文本过滤的基础工具说它是最常用的命令也不为过。排错的第一步永远是查日志查日志的第一步永远是grep。grep ERROR app.log grep -n Traceback app.log # 显示行号方便定位上下文 grep -r TODO --include*.py . # 递归搜索代码目录只看Python文件 grep -E ERROR|WARN|CRITICAL app.log # 用正则同时匹配多个关键词 grep -v healthcheck app.log # 排除无关噪声-v是反选实际排查异常的时候我习惯先grep -n ERROR app.log拿到行号再配合sed -n 120,140p app.log把对应区间的日志打出来这样能快速看到异常发生前后的完整上下文比直接grep一堆错误日志效果直观得多。还有一个高频组合是grep 关键词 | wc -l直接统计出现的次数。比如夜里定时任务执行完突然想看今天报错穿了几次一条命令秒出结果完全不需要Python脚本。3.2 sed批量替换和按行号提取sed的用处可以浓缩成两类针对文件内容做流式替换、按指定规则打印某些行。Python项目里批量替换变量名、把代码中某个接口地址改成新域名这种需求很常见sed是你唯一需要记住的答案。sed -i s/old_api_url/new_api_url/g config.py sed -n 100,120p app.log-i参数直接修改原文件务必先用不带-i的版本跑一遍看结果确认替换没有误伤再真正执行。后面那个按行号提取日志区间的方法配合grep定位到的行号使用在排查线上问题的时候几乎天天用到。初学的时候我在-i前面犹豫过很久担心会不会改坏文件。后来养成了习惯改之前先把文件复制一份cp config.py config.py.bak改完之后确认无误再删备份。这招稳建议所有刚入门的开发者都这么做。3.3 awk按列处理日志和输出awk在Python程序员眼里最实用的场景就是处理“按空格或某个分隔符分列展示”的内容。比如服务器的cpu top命令输出、一条按逗号分隔的访问日志想取其中某列做统计awk非常好用。awk {print $1, $4} access.log awk -F, {print $2} data.csv awk $3 500 {print $1} app.log-F,指定分隔符为逗号$1、$2是列号。第三条命令加了一个条件第3列大于500才打印第1列这在分析耗时接口、大文件占用的时候非常高效。关于文本处理一点个人心得Python在复杂逻辑处理上写循环、调第三方库、做聚合分析是王者grep、sed、awk是轻量快刀。正确思路是“先用命令快速摸清状况需要深入分析再上Python脚本”而不是一条路走到黑。4. 进程管理与后台运行别用CtrlC硬怼4.1 查看Python进程ps、pgrep、top的实战组合服务跑到一半挂了重启的时候发现端口被占用或者想知道自己启动的爬虫进程到底还活着没有这些场景都要跟进程管理打交道。ps aux | grep python pgrep -f spider.py # 按命令行关键字直接搜PID ps -ef | grep python3ps aux是最常用的无死角进程快照配合grep就能定位到具体进程。pgrep -f更直接按命令行里包含的关键字把进程号列出来。在使用ps时请注意第一列的输出显示的是用户第二列是进程号第三列是CPU占用第四列是内存占用后面是启动命令和参数这个顺序要清楚。top命令则是动态监控中量级以上的选择按P按CPU排序、按M按内存排序相当于Linux自带的任务管理器。排查Python进程是否内存泄漏的时候盯着RES那列看涨幅是最基本的操作。top -p $(pgrep -f spider.py | head -1)这条命令组合直接监控特定进程号的资源消耗非常实用。4.2 kill的使用优雅退出不等于强杀进程该停就得停但怎么停有讲究。Python程序里如果写好了一个信号处理器接收SIGTERM可以先存数据再退出直接SIGKILL是操作系统的终极强杀程序来不及做任何收尾。kill -15 12345 # 优雅退出SIGTERM默认 kill -9 12345 # 强杀SIGKILL killall -9 python3 # 用进程名杀慎用我的建议是默认先用kill不带参数默认就是-15等两三秒看进程退了没有实在不退再考虑kill -9。直接上来就-9容易把正在写数据的服务搞出数据损坏数据库进程尤其忌讳这个。说到killall -9 python3这个命令一次性杀掉系统里所有叫python3的进程代价可能是其他人在跑的任务被无辜团灭。生产环境千万别这么干除非你能百分百确定没有别的Python进程。4.3 nohup、、setsid让脚本在后台安定地跑本地跑爬虫脚本直接python3 spider.py就能在前台挂着但如果SSH连接一断开这个进程就会收到挂断信号直接跟着终端一起死掉。解决办法就是用nohup或者setsid。nohup python3 spider.py spider.log 21 拆解一下nohup让进程忽略挂断信号把标准输出重定向到spider.log21把错误输出也一起塞进同一个文件最后的放到后台执行。这样一来你可以放心关掉SSH窗口关掉电脑脚本会自己在服务器上跑。不过要提醒一句重定向的输出文件如果不做任何处理会随着时间无限增长一个小日志文件几天就能把磁盘塞满。长期运行的脚本建议在脚本内部用logging模块做日志轮转或者定时把日志清一下。4.4 关于“修改进程名称”的实用技巧搜索热词里有个“linux 修改进程名称”这个场景在Python程序员看来其实很现实服务器上跑了七八个Python脚本想用ps看看到底哪个是哪个结果全叫python3你根本分辨不出哪个进程是哪个任务。解决办法有两个方向。第一个是改命令行参数启动时带上能被pgrep识别的标识python3 /path/to/spider.py --namespider_a然后pgrep -f --namespider_a就能精确定位到是哪个进程。第二个是用Python自己的库安装setproctitle后代码里一行就能修改进程显示名称import setproctitle setproctitle.setproctitle(spider_a)设置后ps的输出里这个进程的名字就变成了spider_a定位管理方便很多。这个技巧在多任务脚本并存的服务器上特别实用避免“想杀A结果误杀B”的惨剧。5. 网络排查与调试从telnet到curl的一站式回答网络排查大概是Python程序员在Linux上遇到问题后最没底气的领域。我今天把高频问题里涉及的命令挨个讲透。5.1 端口连通性检查telnet ip port怎么用、怎么看通不通先回答高频问题“telnet ip 端口 命令怎么看通不通”。很多开发者对这个命令误会很大以为它只能连远程设备的终端。其实telnet最朴素的用法就是拿来找两台机器之间某个端口能不能连通。用法很简单telnet 192.168.1.100 3306执行后你期望看到的输出是类似这样的Trying 192.168.1.100... Connected to 192.168.1.100. Escape character is ^].看到Connected to这几个字就说明这个IP的3306端口是通的。如果端口不通你会看到Connection refused端口没开或服务没监听或者超时提示网络不通或防火墙把包丢了。在telnet交互界面里想退出直接Ctrl]进入telnet命令模式然后输入quit回车即可。这和直连数据库端口时“已经进来了想快速安全地退出”是同一个办法也有很多人裸按CtrlC实测在这种场景下经常不能干净退出。ncnetcat是telnet的替代方案nc -vz 192.168.1.100 3306直接显示连接状态输出更简洁适合写脚本做批量检测。5.2 curlPython爬虫调试的万能工具写爬虫时requests库跑不通第一反应应该是先用curl复现一遍请求看看服务端到底返回了什么。curl在Linux命令行里就是一台无需编码的HTTP客户端。curl -I https://example.com # 只看响应头 curl -v https://example.com # 显示完整请求和响应过程 curl -X POST -H Content-Type: application/json -d {key:value} https://api.example.com/submit curl -k https://self-signed.example.com # 跳过SSL证书验证curl -v输出里能看到DNS解析的IP、TCP连接建立的耗时、请求头、响应头Python request库如果排查不了的问题用curl直接裸看哪个环节慢、哪个头缺失一目了然。爬虫里最常见的“本地能请求通、服务器上一连就超时”问题脚本里跑不通先别急用curl -I试一下目标站点的响应头如果是403大概率是被防盗链或者WAF拦了curl里加个Referer再试思路和requests一模一样。5.3 端口监听检查与“端口被占用”的通用解法Python服务启动时报“地址已被使用”是发病率极高的报错。解决思路很简单找出是谁占用了端口然后做出处理。netstat -tlnp | grep 8000 ss -tlnp | grep 8000新系统上建议优先用ss性能比netstat好。-t只看TCP-l只看监听端口-n不做反向解析显示IP和端口数字-p显示进程信息。执行后如果那行显示python3 12345就说明8000端口被PID为12345的Python进程占着。是它该退就kill不是它该退就换端口。5.4 连通性排查的整体思路按三层顺序来很多读者一篇文章看下来记住了各种命令但真到排查的时候依然手忙脚乱。我提供一个自己用得很顺的排查顺序按这个顺序走90%的疑难杂症都能定位到环节。第一步先看本机网络接口状态ip addr或者ifconfig确认网卡有没有IP、是不是up状态。第二步检查到目标主机的链路层通不通ping 目标IP看ICMP是否返回。第三步检查目标端口是否开放上一步通了再执行telnet 目标IP 端口。第四步域名解析是不是正常dig或nslookup查看域名解析的IP是否符合预期。第五步看项目的代理配置或系统网络配置是否干扰了访问路径。这个顺序本质上是“从底层到上层、从本机到远端”。每一步都能给出明确的判断依据排查过程中我再强调一遍不要跳步骤——上次我排查一个线上超时问题花了大量时间在应用层翻配置最后发现是云安全组规则把端口挡了属于第二步就查出问题的范畴白白绕了一大圈。6. Python环境管理与安装别再问为什么pip装错地方6.1 安装Pythonapt、源码编译、pyenv三条路怎么选Linux发行版自带的Python版本往往低于你在本地开发时用的版本。比如你本地用3.11写好的代码服务器上可能只有3.8直接跑起来各种新语法报错。装新版本Python有三条经典路线。第一条是apt install python3.11不同发行版包名不同前提是软件源里有这个版本。优点是一键安装、系统自动管理缺点是版本更新滞后。第二条是源码编译安装到Python官网下载源代码./configure make make install优点是版本随心所欲缺点是编译耗时长机器配置不高时能磨叽半小时。第三条是用pyenv做版本管理pyenv可以理解为Python版本的git多版本共存、随时切换日常开发强烈推荐。个人建议生产服务器求稳优先考虑apt官方源能装的版本多版本共存实验性质的工作站上pyenv特殊场景必须用某个冷门版本就源码编译。6.2 venv与pip虚拟环境隔离和依赖安装的避坑指南热词里频繁出现“python安装numpy库的方法”“python安装教程”很多宝子装库遇到最大的坑就是装到了系统Python里或者装了以后import不到。根子在于没有使用虚拟环境。Python官方早就把venv内置了使用它一点都不复杂python3 -m venv venv source venv/bin/activate pip install numpy先创建虚拟环境目录再激活。激活后命令行前面会显示(venv)提示符此时输入python和pip用的都是虚拟环境里的版本装进去的包不会污染系统环境环境之间互相隔离。还有一个高频坑pip install以后明明装成功了运行代码却提示ModuleNotFoundError。大概率是你的python和pip不是同一个环境。用which python和which pip对照一下路径必须指向同一个解释器才正常。6.3 pip安装慢与换源配置国内网络环境下直接用官方PyPI源安装依赖慢到让人怀疑人生。解决方式是配置国内镜像源。这里以清华大学的开源软件镜像站为例一条命令把默认源切过去pip config set global.index-url https://pypi.tuna.tsinghua.edu.cn/simple换完源再装包速度提升几个数量级。这个配置对所有后续的pip install都生效不用每次手动指定-i参数。同样的问题也适用于conda环境conda config --add channels配置类似的镜像源即可。在团队项目里推荐把依赖文件requirements.txt固定好配合虚拟环境一整套流程部署一次成功一次而不是上服务器现试现装。7. 高频命令速查表与避坑经验总结7.1 Python高频场景命令速查表场景命令说明查看Python进程ps aux | grep python查看所有Python相关的进程按名字定位进程pgrep -f spider.py直接获取进程号优雅停服务kill -15 12345先给机会收尾不行再-9后台跑脚本nohup python3 app.py app.log 21 输出重定向后台运行实时看日志tail -f app.log日志追加时动态显示搜索错误关键词grep -n Traceback app.log带行号定位按行号看上下文sed -n 120,140p app.loggrep定位号后的配套操作统计错误次数grep -c ERROR app.log直接输出次数端口连通测试telnet 目标IP 端口看到Connected即通本机监听端口ss -tlnp | grep 8000找谁占用了端口递归搜索代码grep -r TODO --include*.py .按类型过滤搜索结果批量改文件内容sed -i s/旧值/新值/g config.py改前先不带-i试跑一遍切换镜像源pip config set global.index-url 镜像地址改完永久生效这张表是我日常使用频率最高的命令清单贴到笔记软件里需要时直接拿来抄作业。7.2 三个我亲自踩过的坑第一个是pip装错环境。有一次服务器上跑了个脚本需要pandaspip install pandas显示装好了但脚本一执行就ModuleNotFoundError。查了半天搞清楚了系统的pip对应的是/usr/bin/python3而这个项目的venv用的是/usr/local/bin/python3.11。后来检查which python和which pip的路径发现竟然不是一个解释器大家一定要养成虚拟环境激活后再装包的习惯并且装完的第一时间就验证import是否成功。第二个是rm -rf的通配符灾难。想清空某个目录下的.pyc缓存文件写了rm -rf *.pyc结果通配符展开后把当前目录里一个与*.pyc长得毫无关系的子目录也匹配上了。从此我强制自己在rm -rf前面先ls一下看看通配符到底展开成了什么。第三个是nohup.out无限膨胀。我跑过一个数据采集脚本nohup重定向输出到了默认的nohup.out文件三个月后这台机器磁盘100%。查了半天发现是那个日志文件膨胀到了几十GB。你可以用df -h看磁盘占用、用du -sh *找出具体文件这正是“先定位再处理”的思路。后来凡是长任务我一定在脚本里配置好logging轮转或者启动命令里显式指定输出文件路径并定期截断。7.3 小型服务器上“磁盘满了”的排查思路延伸磁盘满排查的思路值得单独说一步。依次执行下面的命令能让问题暴露得非常清楚df -h # 查看整体磁盘剩余 du -sh /var/log/* # 查看哪个日志目录最大 du -sh /home/user/* 2/dev/null # 查看用户目录下哪个文件占用高du -sh结合sort -hr可以排序列出大目录du -sh /data/* | sort -hr | head -10这个组合能够快速找到哪个应用把磁盘吃完了。排查思路比背命令更重要先看整体再逐层细化定位速度会快很多。8. 最后分享一个小技巧用终端把调试效率提上来说了这么多最后分享一个我一直在用的组合拳特别适合日常调试。比如本地测试一个FastAPI接口启动后想看实时请求日志并顺带统计某个路径的请求量uvicorn app.main:app --port 8000 access.log 21 tail -f access.log | grep POST /api再比如代码改完部署上服务器想确认改动是否生效在启动后立刻执行grep -n 启动成功 /data/app/app.log其实整个终端思维的内核就一条把该记的步骤沉淀成命令把该看的输出沉淀成日志然后熟练使用组合拳。刚开始可能会觉得不如IDE直观但用顺手之后你会发现排查问题的时间少了一大半。祝各位Python开发者的Linux之旅少踩坑、多躺赢。
RELATED READING

延伸阅读

更多一线实战笔记与深度复盘,助您持续精进