孙玲的空间我刚开始接触Linux那会儿，其实挺抗拒的——明明在Windows上点鼠标就能搞定的事，到了Linux服务器上全得敲命令，而且一长串参数看得人头皮发麻。后来真正做了几年Python开发，才意识到一件事：你写Python的时间越多，就越离不开Linux命令行。不管是部署服务、排查线上问题、管理虚拟环境，还是操作Git、跑定时任务、看日志，终端就是你的第二战场。这篇文章我不打算跟你讲什么“Linux命令大全”，那些命令查手册就能看到。我只想从一个Python开发者的实际工作流出发，把真正高频、真正能救命、真正能提升效率的命令串起来，帮你从“会敲几个命令”变成“能流畅地在一台Linux服务器上完成一整套开发运维工作”。
这篇文章适合谁？刚入门Python、准备把代码部署到Linux服务器上的新手；在Windows上用PyCharm写代码、但一进服务器就懵的开发者；还有那些已经会基础命令，但每次都要现查参数、想系统梳理一遍的朋友。我会尽量把“为什么要这样用”“底层逻辑是什么”“踩过哪些坑”都讲清楚，而不是丢给你一堆冷冰冰的参数表。
1. 为什么Python开发绕不开Linux命令行
先说一个很多人没意识到的事实：你写的Python代码，最终大概率不是跑在Windows上的，而是跑在一台Linux服务器上。不管是Django还是Flask，不管是爬虫还是数据分析任务，生产环境默认就是Linux。这就带来一个问题——你在Windows上开发得再舒服，最终还是要面对服务器上的Linux环境，而服务器通常是没有图形界面的，你能依赖的就是那一个黑乎乎的终端。
1.1 Python生态天然长在Linux上
Python生态里绝大多数核心工具都优先支持Linux。比如虚拟环境venv、包管理工具pip、进程管理工具supervisor、容器化工具Docker，它们在Linux上运行得最顺畅。为什么？因为Python诞生的时候就是运行在Unix/Linux系统上的，它的文件路径规则、进程模型、权限体系，和Linux原生契合。你在Windows上踩过的各种路径分隔符坑、编码坑、权限坑，到了Linux上基本不存在。
还有一个现实问题：你写Python经常要调用的系统级工具，比如抓包工具tcpdump、性能分析工具perf、日志处理工具awk/sed，这些绝大多数只有Linux版本，或者说不支持Windows。如果你不会用Linux命令，你连排查问题的手段都没有。
1.2 Windows和Linux命令行思维的三点差异
从Windows转过来的朋友，最先要适应的不是命令本身，而是三个思维转变：
第一个是“一切皆文件”。在Linux里，硬件设备是文件、网络连接是文件、进程信息也在文件里。你想看CPU信息就去看/proc/cpuinfo，想调试设备就操作/dev/下的文件。这个思维一旦建立，你会发现很多看似复杂的工具，底层都是在对文件做读写。
第二个是“组合大于单一命令”。Windows的命令行偏工具型，一个命令干一件事。Linux的命令则像积木，通过管道符可以把好几个命令拼起来完成复杂任务。比如查看某个Python进程的CPU使用率，一个ps做不到很精细，但ps aux | grep python、top -p 1234、pidstat -p 1234 1这些组合拳就能做到。
第三个是“权限体系无处不在”。Windows下你是管理员，没那么多限制；Linux下你是一个普通用户，很多操作都需要sudo提权，文件和目录的读写权限控制得非常细。这个差异一开始会让人很不适应，但理解了之后，你会发现它在多用户部署场景下能保护你少踩很多坑。
这三层思维建立起来之后，再去看具体的命令，你的脑子里就不再是死记硬背的单词表，而是一套有逻辑的工具箱。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 文件与目录操作：每天重复最多的基本功
Python开发者在Linux上最常干的事，就是在文件系统里来回穿梭，建目录、复制文件、移动文件、删除文件。这套操作看着基础，但如果你不把里面的细节抠明白，后面写部署脚本、处理路径的时候很容易出幺蛾子。
2.1 定位与浏览：pwd、ls、cd
pwd用来查看当前所在目录，没有任何参数，直白地告诉你“你在哪”。很多新手容易忽略这个命令，但我在排查问题的时候第一件事就是pwd，防止自己忘了在哪个目录下操作。ls是列目录，就像Windows下的dir，但它的灵活性要高得多。最常用的三个变体：
ls -l：以长格式显示文件详情，可以看到权限、属主、大小、修改时间。ls -a：显示所有文件，包括以点开头的隐藏文件（比如.gitignore、.env）。ls -lh：人类可读的格式显示大小，文件大小会显示为K、M、G这样的单位。
cd大家都会用，但有两个小技巧值得记住。cd -返回上一次所在目录，这在两个项目间切换时非常高效；cd ~回到当前用户的家目录，和你直接敲cd效果一样。在Python项目里，我习惯把虚拟环境、项目代码、配置文件放在不同目录下，频繁往返时这些快捷方式能省不少事。
2.2 创建与搬运：mkdir、touch、cp、mv
mkdir是创建目录，关键参数是-p，它支持递归创建多级目录。比如你想创建/data/www/myproject/logs，这个路径中间的www和myproject可能不存在，直接mkdir会报错，但mkdir -p /data/www/myproject/logs一步到位，连中间目录一起建好。
touch两个作用：一是创建一个空文件，二是更新一个已存在文件的时间戳。在Python项目里，我经常用它快速生成__init__.py文件，或者在调试时生成一个临时占位文件。
cp是复制文件，-r参数用于递归复制目录。我会特别提醒一点：复制目录的时候一定要带-r，否则cp source_dir target_dir会直接报错omitting directory。mv是移动或重命名，它在同一个文件系统内几乎是瞬间完成，因为它只是改了一下指针，并没有真正搬运数据。如果你要在不同文件系统之间移动大文件，mv可能会比较慢，这时可以考虑先用cp再rm。
2.3 删除操作与通配符的坑
rm是删除命令，它的危险程度在Linux命令里排前列。rm -rf表示递归强制删除，这个组合一旦用错，代价非常惨痛。网上流传着各种误删生产数据的段子，大部分都是这个命令闯的祸。我自己的习惯是：在删除前先ls确认路径，尤其当路径里有变量时，一定要用echo把变量值打出来看看。比如你写了个脚本，变量$DIR没有正确赋值，一条rm -rf $DIR/可能直接变成rm -rf /。
通配符也是重灾区。假设你想删除目录下所有.log结尾的文件，直接rm *.log没问题，但如果目录下有超多文件，命令可能会提示参数过长。更稳妥的方式是结合find来删除：find . -name "*.log" -type f -delete。另外，千万注意rm *.py和rm * .py的区别，中间多了一个空格，意思就完全变了——前者删除所有py文件，后者删除当前目录下所有文件再加一个名为.py的文件。这类错误在新手里很常见，多敲一个空格就可能酿成大祸。
3. 文件内容查看与处理：用好这三板斧
写Python的时候，你经常会需要快速查看一个配置文件的内容，或者从一个日志文件里提取特定信息。Linux提供了一套非常强大的文件内容查看和文本处理工具，比用Python现写脚本要轻量得多。
3.1 cat与less的取舍
cat是最简单的查看命令，直接输出全部内容，适合看短文件。但遇到几百MB的日志文件，cat会把终端刷爆，还可能让服务器负载飙升。这时候应该用less，它是分页器，支持上下翻页、搜索、跳转，查看大文件时非常从容。按/可以搜索关键词，按n跳转到下一处匹配，按q退出。我习惯在排查线上问题的时候用less打开日志文件，边看边搜，效率和体验远胜cat。
3.2 grep：从日志里捞关键信息
grep大概是Python开发者最爱的Linux命令之一。它能在文件或标准输出里搜索匹配的行。基本用法是grep "关键词" 文件名。但实际工作中，我很少单独用它，更多是配合管道符和其他命令使用。
比如查看某个Python服务今天有没有报错：
bash复制grep "Traceback" /var/log/myapp.log
比如递归搜索项目所有代码里哪一行用了废弃API：
bash复制grep -rn "deprecated_func" --include="*.py" /path/to/project/
这里的-r表示递归搜索子目录，-n显示行号，--include限定文件类型。-i忽略大小写也是高频参数。还有一个特别实用的组合：grep -A 5 "error"表示输出匹配行及之后5行，grep -B 5表示匹配行之前5行。排查Python报错时，错误堆栈往往是多行的，只匹配一行看不到上下文，加上-A或-B就能把完整堆栈捞出来。
3.3 sed与awk：轻量级文本手术刀
sed是流编辑器，适合对文本做替换、删除、插入操作。最常见的用法是替换字符串：
bash复制sed -i 's/old_text/new_text/g' config.py
-i表示直接修改文件，不加的话只是在屏幕上输出替换结果。s是替换命令，g表示全局替换。这个命令在批量修改配置时非常好用，比如把项目里所有数据库密码统一替换。
awk则更偏向结构化文本处理。它默认把每行按空白字符切分成若干列，然后你可以按列号进行处理。比如查看/etc/passwd文件里所有用户名，只需要：
bash复制awk -F: '{print $1}' /etc/passwd
-F:指定冒号为分隔符，然后打印第一列。awk还能做简单的统计和条件过滤，比如统计一个文件的行数：awk 'END{print NR}' file.txt。
我在日常中最常用的一个组合是tail -f加grep。实时跟踪一个日志文件，并只显示包含关键字的内容：
bash复制tail -f app.log | grep --line-buffered "ERROR"
--line-buffered保证grep在每读到一行时就立即输出，而不是攒到缓冲区满才输出。这个命令在我调试Python服务时几乎是标配，能让排错效率提升一倍。
4. 权限与用户管理：多用户协作的安全底线
很多Python新手部署自己的项目时，习惯用root用户一股脑操作，所有文件全在root名下，后面跑Web服务时用自己创建的普通用户，结果发现没有权限读代码文件，各种Permission denied。权限这块看似枯燥，但搞懂了，能帮你省去大量奇奇怪怪的坑。
4.1 理解权限的三元组
Linux权限体系可以拆成三组：文件属主的权限、属组的权限、其他人的权限。每组里又包含三个动作：读（r）、写（w）、执行（x）。用ls -l查看一个文件，输出类似：
text复制-rw-r--r-- 1 deploy deploy 2340 Feb 15 10:32 config.py
第一个字符-表示这是一个普通文件（目录则是d），后面9个字符每3个一组，分别对应属主、属组、其他用户。上面的例子表示：属主可以读写（rw-），属组的其他成员和其他用户只能读（r--）。
权限还常用数字表示，读是4，写是2，执行是1，三者的和就是该组的权限值。比如755表示属主有读、写、执行权限（4+2+1=7），属组和其他用户只有读和执行权限（4+1=5）。对Python项目来说，最常见的权限设置是：目录用755，普通文件用644，可执行脚本用755。
4.2 chmod与chown的实操
chmod用来修改权限，两种写法都要熟悉。数字写法更直观：
bash复制chmod 755 deploy.sh
符号写法适合小幅调整，比如给所有用户添加执行权限：
bash复制chmod a+x deploy.sh
chown用来修改文件属主和属组。比如把项目目录的所有权交给deploy用户和deploy组：
bash复制chown -R deploy:deploy /srv/myproject
-R参数实现递归，对目录下所有文件和子目录生效。很多部署问题的根源就是chown没做，导致Web进程无法读取代码文件。
我一直建议：部署项目时创建一个专用用户，比如deploy，然后所有代码、虚拟环境、日志文件都用这个用户去操作，避免直接使用root。这样即使某个服务被入侵，权限边界还是清晰的，能减少损失面。
5. 进程管理与资源查看：让Python服务稳定运行
写Python写久了，你一定会遇到这些场景：写的Web服务在后台跑了几天，突然内存飙升；或者多个进程抢同一个端口，服务起不来；又或者定位到某个Python进程CPU占用过高，需要揪出问题。这些场景下，进程管理和资源查看的命令就派上用场了。
5.1 ps和grep配合的经典组合
ps命令用来查看当前系统的进程快照。最经典的组合是ps aux，它会列出系统所有进程的详细信息，包括PID、CPU占用、内存占用、启动命令等。但输出内容太多，直接看会淹死在信息海里，所以基本都会配上grep：
bash复制ps aux | grep python
这条命令会列出命令行里包含“python”的所有进程。但这有个小坑：grep本身也是一个进程，它的命令行里也包含“python”，所以结果里会多出一条grep --color=auto python。为了避免误判，可以在grep时排除自身：
bash复制ps aux | grep python | grep -v grep
不过在排查问题的时候，多出来的那一行基本不影响判断，我一般懒得处理。更严谨的做法是使用pgrep -f python直接拿到PID列表。
ps aux的输出里，有一个比较关键的判断点：状态列（STAT）。如果看到某个Python进程的状态是Z（僵尸进程），说明它已经终止但父进程没有回收它的退出状态码。这种情况在长期运行的服务里偶尔会出现，一旦积累多了，进程表被占满，系统就没法再创建新进程了，这时候需要找到它的父进程并处理。
5.2 top与内存分析
top是实时查看系统资源和进程排行的工具，它每几秒自动刷新一次。进入top界面后，按P按CPU占用排序，按M按内存占用排序，按q退出。当你的Python服务占满CPU时，通过top能第一时间锁定是哪个进程，再配合ps -fp PID查看这个进程的详细信息。
内存方面，free -h可以查看系统可用内存。单位换算成人类可读格式，一眼就知道还剩多少内存。如果发现系统内存被Python进程吃光，别急着kill，先用top看看具体是哪个进程。很多时候不是代码泄漏，而是爬虫任务积压、队列积压导致的，解决方向完全不同。
5.3 后台运行命令的几种姿势
本地开发的时候，直接python app.py跑起来就行，但生产环境和服务器的场景下，手动跑的进程会随着SSH连接断开而退出。这时候需要让进程在后台持续运行。传统方案是nohup配合&：
bash复制nohup python app.py > app.log 2>&1 &
解释一下：nohup让进程忽略挂断信号，> app.log把标准输出重定向到文件，2>&1把错误输出也并入标准输出，&让命令在后台执行。这条命令敲完之后，终端会返回一个PID，进程就脱离终端独立运行了。
但裸后台运行也有问题：万一进程挂了，没有任何机制帮你自动拉起。所以稍微正式一点的环境，我会用systemd来管理服务，或者用supervisor。supervisor是一个Python进程管理工具，它帮你管理进程的启动、停止、重启、自动拉起、日志轮转。有了它，nohup基本就退役了。不过supervisor本身也是一个进程，它也有自己偶尔抽风的一天，所以方案的选择始终是个权衡。
6. 网络排查与端口管理：服务调不通时的自救指南
Python服务最容易出问题的，往往不在代码本身，而在网络链路。端口被占、连接数打满、DNS解析超时、防火墙拦截，这些问题排查起来头大，但好在命令行有非常趁手的工具。
6.1 查看监听端口和连接状态
部署Web服务时，最常遇到的就是端口冲突。如Django默认跑在8000端口，但8000已经被占用了，这时候需要找到是哪个进程占用了它：
bash复制netstat -tlnp | grep 8000
-t显示TCP连接，-l只显示监听状态的端口，-n不解析域名直接用数字显示IP，-p显示进程PID和名称。输出里能看到占用8000端口的PID，然后kill PID就能释放端口。
有些系统没有装netstat，可以用ss代替：
bash复制ss -tlnp | grep 8000
ss命令现在更被推荐，它性能更好，输出格式类似。日常排查连不上服务、端口冲突这类问题，这两条命令足够。
6.2 检查连通性与远程调用
ping用来测试主机连通性，但有一个误区需要澄清：ping通只代表网络层通，不代表应用层通。很多时候服务器ping通，但Python服务就是连不上，问题可能出在端口、防火墙、或服务本身。所以确认服务正常步骤应该是：先ping看网络是否通，再telnet或nc测试端口是否开放，最后才去检查业务逻辑。
curl是Python开发者最常用的HTTP调试工具。它能模拟GET和POST请求，查看响应头、响应体、耗时：
bash复制curl -I http://localhost:8000/api/health
-I只显示响应头，适合快速确认服务是否活着。完整测试接口时，我习惯用curl -v看详细交互过程，包括DNS解析、TCP握手、TLS握手、请求头、响应头、响应体，一个命令全搞定。对于REST API的调试，curl -X POST -H "Content-Type: application/json" -d '{"key":"value"}' http://localhost:8000/api是基本功。
6.3 解析域名和追踪路由
dig用来查询DNS解析记录。有时候服务调不通，不是代码问题，是DNS解析错了。比如你调用的域名解析到了错误的IP，dig example.com就能看到解析结果。nslookup也能干类似的事，但输出信息不如dig清晰。
traceroute用来追踪数据包到达目标主机经过的路由节点。当跨机房、跨地域调用出现延迟警告时， traceroute 可以帮助定位是哪个路由节点出了问题，是运营商线路问题还是对方机房防火墙问题。不过排查这个问题需要网络权限，本地和服务器都要有相应能力，实际用的频率没有前面几个高。
7. 日志查看与滚动：Python应用的排障入口
在所有Linux命令里，日志处理是我认为Python开发者最应该投入时间掌握的领域。很多时候线上问题不是靠IDE断点调试出来的，而是靠日志一点点推出来的。日志文件天生就是文本，而Linux命令行恰好最擅长处理文本。
7.1 tail、head、less的配合
tail查看文件末尾内容，默认显示最后10行。tail -f是“跟随”模式，会持续输出文件新增的内容。调试Web服务时，我习惯先开一个窗口跑tail -f，另一个窗口发测试请求，实时看日志输出，问题定位非常直观。
head查看文件开头内容，比如配置文件头部、CSV文件表头。less适合大文件，因为它不会把整个文件读入内存，而是按需分页加载。再加上less内部支持搜索、跳转，看大日志文件时比vi/vim更灵巧。
7.2 常见日志格式的处理套路
Python的logging模块默认输出格式一般是：
text复制2025-02-15 10:32:45,123 INFO 12345 - message content
如果想从这种行式日志里提取某个时间段之间的内容，可以结合grep的正则表达式，或者使用sed：
bash复制sed -n '/2025-02-15 10:32:45/,/2025-02-15 10:33:45/p' app.log
sed -n取消默认输出，/起始时间/,/结束时间/p打印这个区间内的行。这个命令在处理长时间的异常时段日志时非常有用。
如果我需要统计日志里某个关键字出现的次数，纯靠肉眼数是不现实的，一行命令就解决了：
bash复制grep -c "ERROR" app.log
更复杂的统计还能用awk按时间段聚合错误数，这个写起来有点累，但比用Python脚本处理要轻量，适合临时快速分析。
7.3 定期轮转日志：避免磁盘爆炸
日志文件会无限增长，不处理迟早占满磁盘。Linux自带的logrotate工具能按大小或时间进行日志轮转，自动压缩、删除旧日志。一个简单配置示例：
text复制/path/to/project/logs/*.log {
daily
rotate 7
compress
missingok
copytruncate
}
daily：每天轮转一次rotate 7：保留7份历史日志compress：旧日志用gzip压缩copytruncate：先复制当前日志内容再清空原文件，避免对正在写入日志的进程产生影响
配置好后，用logrotate -f /etc/logrotate.d/myapp手动触发一次，确认效果。日志轮转这块内容新手容易忽略，但生产环境一旦磁盘满了，服务直接就崩了，那时候再清理就非常被动。
8. 实用命令组合：把单个命令串成工作流
单个命令学会是一回事，真正工作中还需要把它们组合起来形成一套高效的流程。下面我分享三个我经常用的命令组合，代码部署、日志排查、目录清理这三个常见场景。
8.1 部署Python项目到Linux服务器的标准流程
每次发布新版本，我都会在服务器上按这套流程操作：
bash复制cd /srv/myproject
git pull origin main
source venv/bin/activate
pip install -r requirements.txt
python manage.py collectstatic --noinput
systemctl restart myapp
这里每个命令的先后顺序都有讲究：先更新代码，再更新依赖，再收集静态文件，最后重启服务。跳步看似省时间，实际上特别容易出问题。比如你先重启了服务再拉代码，就可能把新代码配旧依赖跑起来，报奇怪的错。更稳妥的做法是：git pull前先备份数据库和配置，pip install时注意不要用-U，那会把所有依赖升级到最新版，非常容易翻车。
8.2 排查线上Python服务异常的完整链路
线上服务报警，我通常按下面的顺序排查：
bash复制tail -f /var/log/myapp/error.log
ps aux | grep python | grep -v grep
top -p PID
free -h
df -h
ss -tlnp | grep 8000
先看日志有没有新报错，然后看进程是否存活、CPU内存占用如何、磁盘是否满了、端口是否正常监听。这些信息一套下来，80%的问题都能定位。如果还找不到，再考虑抓包、读内核日志、看监控曲线。
这个排查流程的核心是：从现象出发，一层层剥离表象，先系统后应用，先全局后局部。不要一上来就盯着一行日志猛看，容易陷入局部细节里出不来。
8.3 磁盘清理与文件查找
磁盘满是个高频事故，清理的时候很容易误删文件。我的安全清理顺序是：
bash复制df -h
du -sh /srv/myproject/*
find /srv/myproject -type f -size +100M
find /srv/myproject -name "*.log" -mtime +7 -delete
先看整体占用，再定位大目录，再找超大文件，最后只删确定过期的日志文件。find的-mtime +7表示修改时间在7天以上的文件，这个参数配合-delete用的时候要多加小心，建议先用不带-delete的版本打印出所有匹配文件，确认没问题再真正删除。
9. 包管理与镜像配置：pip的Linux生存指南
Python开发离不开pip，但在Linux上使用pip需要注意几个特殊地方。环境不同，包管理的策略也应该不同。
9.1 pip版本与Python版本的对应关系
Linux发行版自带的Python版本和pip版本往往不是最新的。比如某些老版本Linux发行版，自带Python版本还是2.x或者3.6，但当前Python生态已经到3.12了。这种情况下，直接pip install很容易装上不兼容的包。
我的建议是：不要动系统自带的Python，也不要全局安装最新的pip包。正确的做法是使用虚拟环境，为每个项目单独创建一个干净的Python环境。创建虚拟环境用python3 -m venv venv，激活用source venv/bin/activate，退出用deactivate。
如果你需要多个不同版本的Python，推荐使用pyenv。它能让你在同一台机器上管理多个Python版本，随时切换。这在开发多个项目、测试不同Python版本的兼容性时特别有用。
9.2 使用镜像源加速安装
在国内服务器上直接用pip安装海外PyPI镜像，速度往往让人崩溃。配置镜像源后，下载速度能提升一个数量级。临时指定镜像源：
bash复制pip install requests -i https://pypi.tuna.tsinghua.edu.cn/simple
更省事的方法是把镜像源写入配置文件，修改~/.pip/pip.conf：
text复制[global]
index-url = https://pypi.tuna.tsinghua.edu.cn/simple
trusted-host = pypi.tuna.tsinghua.edu.cn
这样以后每次pip安装都默认走镜像源，不需要每次手动加参数。这个配置文件在不同Linux发行版上路径可能不一样，用pip config list或者pip config debug可以查看当前生效的配置。
9.3 解决权限冲突与依赖冲突
如果在没有启用虚拟环境的全局Python里直接pip install，经常会遇到系统权限问题。破解方式是用pip install --user安装到用户目录。但在部署环境或服务器上，我更推荐老老实实用虚拟环境，这样不会污染系统Python，也能避免多个项目之间依赖版本打架。
pip freeze是检查当前环境所有包的命令，输出格式是包名==版本号。生成requirements.txt：
bash复制pip freeze > requirements.txt
在新环境安装：
bash复制pip install -r requirements.txt
这个命令保证你的项目依赖可以复现。不过要提醒一句：pip freeze会把当前环境的所有包都输出，包括很多无关的依赖，如果你的环境不太干净，生成的requirements文件里会有很多多余内容。
10. Git与代码协作：终端下的版本控制基本功
再熟练的Python开发者，也躲不开Git。在Linux终端上操作Git，比在IDE里点图形界面更透明、更直接，尤其是在服务器上直接调试代码时，终端下的Git几乎是唯一选择。
10.1 clone与status：进入项目的第一步
git clone <仓库地址>把远程仓库拉下来到本地。这个命令的坑在于，如果你的项目很大，或者网络不稳定，clone会卡在中间。可以加--depth 1只拉取最近一次提交，省流量也省时间。如果后面需要完整历史，再git fetch --unshallow补全。
git status查看当前工作区状态，搞清楚哪些文件被改过、哪些文件是新增的暂存区。我习惯在动手之前先敲一下这个命令，确认自己的位置和目标，避免改错分支。
10.2 提交代码的正确姿势
git add、git commit、git push是提交代码的三板斧。但这里有一个我踩过多次的坑：git add .会把当前目录下所有改动都加进去，包括一些临时文件（比如.pyc、__pycache__、.env），会污染仓库。正确做法是配合.gitignore文件把不需要跟踪的内容排除掉。
git commit -m "提交信息"把暂存区的改动提交到本地记录。提交信息我建议写清楚改动内容和原因，而不是写“update”这种口水话。好的提交信息长这样：fix: 修复用户登录时验证码过期导致的报错。git push把本地提交推送到远程仓库。如果是第一次推送新分支，还要设置上游：git push -u origin main。
10.3 查看变更与回滚：救命的undo操作
git diff查看工作区与暂存区的具体差异，git diff --staged查看暂存区与上一次提交的差异。在配合代码审查时，git diff基本是必用操作。
如果你改了代码发现改错了，想撤销：
- 还没有
git add时，git checkout -- file可以撤销对单个文件的修改。 - 已经
git add但没git commit时，git reset HEAD file取消暂存，再checkout撤销修改。 - 已经提交但没push时，
git reset --soft HEAD~1撤销最后一次提交但保留改动文件在暂存区。
这些命令在不同的Git版本下行为可能有差异，建议先在临时分支上试验。另外，如果已经push到了远程仓库，不要轻易用git reset回滚提交，因为这会改写历史，影响其他人。正确做法是用git revert生成一个反向提交，这样历史是向前推进的，协作更安全。
11. 系统信息与软件安装：新服务器初始化上手
拿到一台新服务器，第一件事通常是确认系统环境，安装必要软件，然后才进入项目部署。这个过程在命令行里走一遍，你会对整个系统有一个整体认知。
11.1 查看系统架构与资源
uname -a查看内核版本和系统架构，比如x86_64还是aarch64。这决定了你安装的Python版本是哪个平台的构建版本。cat /etc/os-release查看Linux发行版信息，CentOS还是Ubuntu，版本号是多少，不同发行版的软件包管理和依赖方式差异很大。
free -h和df -h查看内存与磁盘，nproc查看CPU核心数。这些信息决定了你部署的Python服务最大能开多少个工作进程，Gunicorn的--workers参数经常要和CPU核心数匹配，所以先查看系统资源是部署前的必备步骤。
11.2 安装软件的两种主流方式
不同Linux发行版用不同的包管理器。Ubuntu/Debian系用apt，CentOS/RHEL系用yum或dnf。安装软件前先更新软件源：
bash复制apt update && apt upgrade
安装Python开发相关的基础软件：
bash复制apt install -y python3 python3-venv python3-pip build-essential git curl
build-essential包含编译Python扩展包所需的工具链，很多Python包（如lxml、pandas）在安装时需要编译C扩展，没有这些工具会直接报错。安装完这些，再检查一遍python3 --version确认版本，不满足要求就考虑用pyenv安装指定版本。
11.3 压缩与解压
部署时经常要传递代码包、日志包，tar命令是必备技能。打包目录：
bash复制tar -czf myproject.tar.gz myproject/
解压：
bash复制tar -xzf myproject.tar.gz
c表示创建归档，z表示用gzip压缩，x表示解压，f后面跟文件名。这套参数必背，不需要理解太深，用多了自然就记住了。zip格式也行：打包zip -r myproject.zip myproject/，解压unzip myproject.zip，不过生产环境的Linux服务器上默认可能没装unzip，还是tar最稳。
12. 让命令高效运转：别名与定制化的个人心得
命令用得多了，你会发现有些固定组合天天敲，效率很低。这时候Linux的别名机制能帮你省下大量按键体力。
12.1 alias别名与.bashrc
alias命令可以给长命令起一个短名字。比如我常用的几个：
bash复制alias ll='ls -alF'
alias la='ls -A'
alias py='python3'
alias gp='git pull'
alias gpoh='git push origin HEAD'
这些别名写入~/.bashrc文件后，新开的终端窗口自动生效。修改完记得source ~/.bashrc让配置立刻生效。如果你用的是zsh，对应的配置文件是~/.zshrc，语法完全一样。
我养成了一个习惯：每发现一个重复输入三次以上的命令组合，就把它写成alias或小脚本。时间久了，你的终端效率会被别人甩开一大截。
12.2 history命令与技能演进
history能查看你敲过的所有命令。有时候之前解决过的问题，过了几个月又遇到，却忘了当时用的什么命令，这时候history | grep 关键词就能找回当时的“药方”。我甚至会把一些命令组合复制到自己的笔记软件里，按场景分类，比如“部署”“排错”“清理”“备份”，形成一个随时能查的个人命令行手册。
Linux命令的学习不是一蹴而就的，它是随着你的项目、你的服务、你的问题一起演进的。今天你只需要掌握pwd、ls、cd，明天可能就需要理解grep、sed、awk，再过一段时间你可能主动去研究systemd、iptables、Docker的网络模式。不要急着背完所有命令，而是带着具体问题去学，学一个用顺一个。
在我个人的使用体验里，把常用的二三十条命令练熟，就已经能覆盖90%以上的日常开发运维场景了。剩下的命令，遇到一次查一次，慢慢就进脑子了。命令行不是目的，它是一个通道，通向你写的Python代码真正产生价值的地方——那一台台跑着服务的Linux服务器。