企业官网建设流程全解析

最近部门来了几个刚转Python开发的同事，坐在工位上第一周干得最多的不是写代码，而是跟Linux终端上的命令较劲：有的卡在给服务器装Python包上，有的把项目路径搞混导致import报错，还有一个折腾了半天才发现自己写的脚本压根儿没被执行。说实话，这些事看着是代码问题，实际上都是基本功的债。我在Python上写了七八年业务代码，带过不少新人，最深的体会是：Python代码能跑起来只是第一步，真正拉开效率差距的，是你对操作系统的熟悉程度，以及命令行工具的熟练度。今天这篇不讲花哨的Python技巧，就聊聊Python程序员每天最常用的那些Linux命令——从装环境、查进程、看日志、测接口，到部署服务、排查故障，每一节都是我实际踩过坑之后沉淀下来的用法。文章整体是“场景+命令+原因”的逻辑，每个命令我都会说清楚项目里什么时候用得上，适合刚转过来还没顺手的兄弟，也适合想系统补一补基本功的人。

1. Python开发环境的地基：装好Python，理顺路径

1.1 系统自带的Python够用吗？从apt到pyenv的真实选择

很多Linux发行版默认就带Python3，比如Ubuntu 22.04自带3.10，Debian 12自带3.11。对写业务代码的人来说，系统自带的版本通常够用，但如果你同时维护多个项目，每个项目依赖的Python版本不一样，这时候直接用系统Python就会非常难受。我见过最典型的场景：项目A用3.8，项目B用3.10，有人直接在系统里装了3.10，结果项目A的某些依赖编译不过去，最后只能整个环境推倒重来。

我的建议是分两种情况处理。

如果只是跑一些临时脚本、做点自动化，直接用系统Python就行，命令就这几条：

# 查看当前版本 python3 --version # 查看可执行文件位置 which python3 # 查看系统里装了哪些Python ls /usr/bin/python*

如果你要正经开发多个项目，或者想随时切换Python版本，直接用pyenv。pyenv的核心价值是“按目录切换版本”，它不会污染系统环境，所有版本都装在你家目录下。安装方法官方文档写得很清楚，这里说几个上手关键点：

# 查看可安装版本 pyenv install --list # 安装指定版本 pyenv install 3.11.8 # 在当前目录锁定版本 pyenv local 3.11.8 # 全局默认版本 pyenv global 3.11.8

注意pyenv local会在当前目录生成一个.python-version文件，进到这个目录Python版本就自动切换，离开就恢复。这个机制配合poetry或pipenv用，几乎可以解决99%的多版本环境问题。

1.2 PATH与环境变量：为什么python命令总找不到

新手碰到“command not found”第一反应是重装，其实90%的情况是PATH没配好。PATH就是一套目录清单，系统执行命令时会按这个清单挨个目录去找可执行文件。你可以这么理解：你喊“python”，系统就按PATH里的顺序一家一家问“你有没有叫python的程序”，全问一遍都没找到，就报command not found。

查看当前PATH：

echo $PATH

临时把目录加进去：

export PATH=/usr/local/bin:$PATH

永久生效就写进shell配置文件：

echo 'export PATH=$HOME/.local/bin:$PATH' >> ~/.bashrc source ~/.bashrc

这里有个很典型的场景：你用pip安装了gunicorn或uwsgi，执行时却提示找不到。原因就是pip把可执行文件装到了~/.local/bin或者Python安装目录的bin下，而这个目录不在PATH里。解决办法就是把对应bin目录加进PATH，而不是卸载重装。我自己在服务器上部署Flask项目时就被这个坑过两次，后来习惯性地先在命令行敲python3 -m pip show gunicorn看安装路径，再决定要不要改PATH。

注意：改完~/.bashrc之后要source ~/.bashrc或者重新开一个终端窗口才会生效，直接在当前终端里敲命令可能没反应。

2. 文件与目录操作：Python项目里的高频基本功

2.1 快速定位文件：find和locate帮你省下半小时

写Python项目的时候经常要找一个文件，比如“这个settings.py到底在哪”“那个爬虫脚本放哪个目录了”。用文件管理器一层层点太慢，直接在命令行用find最痛快。

我最常用的几个组合：

# 在当前目录下按名字找文件 find . -name "settings.py" # 忽略大小写 find . -iname "*.log" # 按类型找，比如找所有Python文件 find . -type f -name "*.py" # 排除虚拟环境目录 find . -type f -name "*.py" -not -path "*/venv/*"

这里解释一下为什么加-type f。不加的话find会把目录也打印出来，目录名匹配到结果里反而干扰判断。还有一个小技巧：2>/dev/null可以把“权限不够”这类报错信息丢掉，让输出干净一些。比如你想在整个系统里找某个配置文件，但又不能保证每个目录都有权限访问，可以写成：

find / -name "nginx.conf" 2>/dev/null

另外一个实用场景是批量处理文件。比如清理Python项目里的__pycache__缓存目录：

find . -type d -name "__pycache__" -exec rm -rf {} +

这个命令的意思是把找到的每个目录作为参数传给rm -rf，一次删干净。如果你写过一段时间的Python，应该知道这个缓存目录有多烦人，尤其是代码改完跑起来还是旧逻辑的时候，先清一遍缓存能解决很多“怪问题”。

2.2 磁盘占用与日志清理：du、df、truncate的组合拳

Python服务跑久了最容易出的问题就是磁盘被日志塞满。一旦磁盘满了，进程写不了日志，可能直接崩溃，表现还很迷惑。排查手段就三步。

第一步，看磁盘整体使用情况：

df -h

-h的意思是human-readable，自动换算成GB、MB。看到某个分区使用率100%，基本就是它了。

第二步，定位是哪个目录占的空间：

# 看当前目录下一级各子目录的大小 du -h --max-depth=1 # 只看当前目录总大小 du -sh . # 展示当前目录所有文件和目录的大小并排序 du -sh * | sort -hr | head -20

这条命令我几乎隔两天就要用一次，尤其是排查生产环境的服务器时，du -sh *一眼就能看出哪个目录异常。

第三步，清理日志。这里推荐truncate而不是直接rm，因为很多正在运行的进程持有日志文件句柄，你删了文件，进程还在往已删除的文件里写数据，磁盘空间不会释放，只有重启进程才生效。用truncate把文件内容清空但不删除文件本身，进程会接着写，空间立刻释放：

truncate -s 0 /var/log/myapp/app.log

如果你确定某个日志文件不再需要，也可以rm -rf直接删掉，但要确认没有进程在写它。

2.3 软链接：一条命令解决路径迁移问题

我在部署Python项目时经常用ln -s建软链接。软链接你可以理解成Windows里的快捷方式，它本身只是一个指向，不复制实际内容。最常见的用法是：项目代码放在/opt/app，但Nginx配置里指定的路径是/var/www/html，这时候不用移动文件，直接建一个软链接就行：

ln -s /opt/app /var/www/html/app

以后访问/var/www/html/app就等同于访问/opt/app，代码更新也是直接在/opt/app里改。

查看软链接是否生效：

ls -l /var/www/html/

输出里会看到类似app -> /opt/app的箭头指向，说明链接正常。

软链接有一个特别容易踩的坑：如果你把一个软链接指向了相对路径，那这个链接就可能失效。比如你在/var/www/html下执行ln -s ../app linkname，那么链接linkname指向的实际是/var/www/app，而不是你以为的/opt/app。所以建软链接时最好用绝对路径，避免理解偏差。检查链接是否失效，就执行ls -l看箭头指向，再确认目标路径是否存在。

3. 进程管理与资源监控：Python程序卡死先来这里

3.1 ps和top：怎么找出吃CPU、吃内存的“元凶”

Python程序出问题，最直观的表现是CPU冲高、内存暴涨，或者整个进程卡住没反应。这时候第一步不是改代码，是先把现场看清楚。

查看当前有哪些Python相关进程，最经典的命令：

ps aux | grep python

ps aux输出包含用户、PID、CPU占用率、内存占用率、启动命令等字段。grep python用来过滤，把只含“python”的行筛出来。这里要提一个细节：grep匹配的是命令行里包含“python”的进程，如果某个进程叫python3，也会被匹配到，所以输出很正常。

如果你已经知道PID，可以直接盯住单个进程：

top -p 12345

想动态看所有进程的实时占用，直接敲top，然后按Shift+P按CPU排序，按Shift+M按内存排序。要注意top看到的CPU占用是百分比，有时候你会看到一个Python进程CPU占用率超过100%，这是正常的，说明它用了多个CPU核心。

在实际排障里，我发现很多内存问题不是瞬间爆发的，而是缓慢上涨。这种情况下用top盯几分钟看不出名堂，更好的办法是把进程内存变化记录下来：

# 每秒记录一次PID 12345的常驻内存，输出10行 for i in $(seq 1 10); do ps -o pid,rss,cmd -p 12345; sleep 1; done

RSS就是常驻内存，单位是KB，可以看出它是不是一直在涨。

注意：如果你在服务器上发现某个Python进程CPU占用率异常高，先别急着kill。先看它的启动参数和日志，确认是正常任务（比如一个长时间运行的批处理或训练任务）还是异常死循环，免得误杀。

3.2 kill与信号：怎么优雅地停下Python进程

很多人一遇到进程卡死，第一反应是kill -9 PID。这个做法简单粗暴，但有个问题：-9发的是SIGKILL信号，内核直接回收进程，进程自己连“善后”的机会都没有。比如你用requests正在写文件，强制杀掉可能导致文件写到一半，数据损坏。

正确的流程是先发kill -15（也就是默认的kill PID，默认信号就是SIGTERM），告诉进程“请主动退出”。Python进程收到SIGTERM后会触发atexit注册的清理函数，把该刷的缓冲刷掉，该关的文件关掉，然后自行退出。如果过了几秒还没退出，再升级成kill -9。

查看进程还能收到哪些信号，以及进程状态：

kill -l ps -o pid,stat,cmd -p 12345

状态字段里常见的是S（睡眠）、R（运行）、D（不可中断睡眠）。如果看到D状态，这个进程可能在做磁盘IO，你先别急着kill，等它IO完成再说，否则容易造成数据不一致。

3.3 后台运行：nohup和systemd帮你把脚本变成服务

开发时我们经常在终端里直接跑python app.py，一旦关掉终端进程就没了。想让Python脚本在服务器后台持续运行，最简单的是nohup：

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

拆开讲一下：nohup让进程忽略挂断信号，即使终端关闭进程也不退出；> app.log把标准输出重定向到日志文件；2>&1把标准错误也重定向到同一个文件；最后的&让命令在后台执行。

但nohup有个缺点：如果进程自己崩溃了，没有机制帮你拉起来。正式一点的服务还是用systemd更稳。写一个service文件，比如/etc/systemd/system/myapp.service：

[Unit] Description=My Python App After=network.target [Service] WorkingDirectory=/opt/app ExecStart=/usr/bin/python3 /opt/app/app.py Restart=always User=www-data Environment=PYTHONUNBUFFERED=1 [Install] WantedBy=multi-user.target

这里有几个关键参数：Restart=always表示只要进程异常退出就自动重启，Environment=PYTHONUNBUFFERED=1让Python输出不经过缓冲，日志能实时看到。然后执行：

systemctl daemon-reload systemctl start myapp systemctl enable myapp

这几条命令的意图分别是让systemd重新加载配置、启动服务、设置开机自启。之后查看状态就是systemctl status myapp，看日志就是journalctl -u myapp -f。

4. 文本处理三件套：grep、awk、sed的Python日常

4.1 grep：从日志里筛Python异常

写Python的人不可避免要跟日志打交道。Django的日志、爬虫的日志、celery的日志，全堆在文件里，出了问题第一件事就是搜索关键词。grep就是干这个的。

最基本的用法：

grep "Traceback" app.log

这会打印日志里所有包含“Traceback”的行。想精确知道异常出现在哪一行：

grep -n "Traceback" app.log

想同时匹配多个关键词，比如既想找Traceback又想找Error：

grep -E "Traceback|Error|Exception" app.log

想在整个项目代码里搜索某个函数名或变量名：

grep -r "my_function" src/

这里-r是递归搜索子目录。如果你不想搜索二进制文件，可以加--include="*.py"，只搜Python文件：

grep -r --include="*.py" "TODO" src/

grep还常常跟管道搭配，比如你想统计日志里某类异常出现了多少次：

grep -c "TimeoutError" app.log

只输出匹配的总行数，这个在汇报问题、定位影响范围时特别好用。

我的习惯是先在日志里搜Traceback，然后在Traceback前后的几行上下文里找具体报错内容。所以一般用grep -n -A 10 -B 2 "Traceback" app.log，-A 10表示匹配行之后显示10行，-B 2表示匹配行之前显示2行，这样能直接看到异常栈的完整片段。

4.2 awk：按列提取日志数据

awk最典型的用法是处理“按列分隔”的文本。比如Nginx访问日志的默认格式是IP、时间、请求、状态码、大小等字段，用空格分隔。你想快速看每个请求的状态码，可以写：

awk '{print $1, $9}' access.log

$1是第一列（IP），$9是第九列（状态码）。awk默认按空格拆分字段，这个特性在处理日志时非常实用。

我经常用awk加sort统计接口的访问量，比如统计每个IP访问了多少次：

awk '{print $1}' access.log | sort | uniq -c | sort -rn

这条链路的含义是：先把所有IP列打印出来，排序，然后uniq -c统计每个连续相同值的数量，最后按数量倒序排。这样一眼就能看出哪个IP在疯狂请求。

awk也支持条件过滤，比如只看状态码为500的请求：

awk '$9 == 500 {print $1, $7, $9}' access.log

这里的$9 == 500是条件，满足条件的行才执行后面的打印。如果你在排查线上接口返回500，这条命令能直接帮你列出所有500请求来自哪些IP、请求了哪些路径。

4.3 sed：批量替换配置文件里的内容

sed的核心功能是“流式编辑”，最常用的就是批量替换。举个例子，你项目里的数据库密码要换，配置文件有一堆地方写旧密码，手动改容易漏，用sed一次搞定：

sed -i 's/old_password/new_password/g' config.py

-i表示直接修改文件，s是替换命令，g是全局替换（每一行所有匹配都替换，而不只是每行第一个）。如果不加-i，sed只把替换结果打印到终端，不会改原文件，这个很适合先预览效果。

只替换特定行可以搭配行号或模式。比如只想修改第20行的内容：

sed -i '20s/old/new/' config.py

或者只替换包含某个关键字的行：

sed -i '/db_host/s/localhost/192.168.1.10/' config.py

这个写法是“找到包含db_host的行，在这一行内做替换”，在改配置文件时非常精准。

注意：macOS自带的sed是BSD版本，-i后面需要跟一个字符串参数，比如sed -i '' 's/old/new/g' file，否则会报错。如果你团队里有人用macOS写这个命令，容易踩这个差异，建议统一在Linux环境里操作，或者加一个''参数兼容。

4.4 管道与重定向：把零散命令串成一条流水线

前面其实已经用到管道了，这里把概念讲透。管道符|的作用是把前一个命令的输出作为后一个命令的输入。你可以把它想象成一条流水线：第一个工人处理完，直接把半成品递给第二个工人。

重定向符号有三个常见用法：

# 覆盖写入文件 python3 script.py > output.txt # 追加写入文件 python3 script.py >> output.txt # 把标准错误也融进去 python3 script.py > output.txt 2>&1

2>&1这个写法是很多新手看不懂的。在Linux里，每个进程默认有三个文件描述符：0表示标准输入，1表示标准输出，2表示标准错误。2>&1的意思是把文件描述符2重定向到文件描述符1当前指向的地方，也就是“把错误输出也送到和标准输出同一个地方”。这样日志文件才能完整记录所有输出，而不是只记一半。

如果不想看到任何输出，可以重定向到/dev/null：

python3 script.py > /dev/null 2>&1

/dev/null就是一个“黑洞”，所有写进去的内容都被丢弃。在调试一些只有副作用、不需要输出的脚本时，这个写法很干净。

5. 网络与调试命令：接口排查离不开的几招

5.1 curl：本地联调和线上排查的瑞士军刀

Python后端开发跟接口打交道太频繁了。本地起了Flask或FastAPI服务，想验证接口正不正常，我最常用的工具就是curl。

最简单的GET请求：

curl http://127.0.0.1:8000/api/users

带请求头的POST请求：

curl -X POST http://127.0.0.1:8000/api/users \ -H "Content-Type: application/json" \ -d '{"name":"test","age":18}'

如果接口返回的是JSON，你直接看终端输出可能是一大串没格式化的字符串，建议加一个管道格式化：

curl -s http://127.0.0.1:8000/api/users | python3 -m json.tool

python3 -m json.tool会把JSON重新格式化打印，层级关系一目了然。这个命令在调试返回大量嵌套结构的接口时特别香。

想看响应头和完整通信过程：

# 只看响应头 curl -I http://example.com # 显示完整的请求和响应过程 curl -v http://example.com

-v会打印SSL握手、请求头、响应头、响应体等所有细节，是排查“接口到底发出去没有”“服务器到底返回了什么”最直接的手段。当你怀疑是代理或者CDN搞的鬼时，-v能帮你看到请求真正打到了哪。

5.2 ping、telnet、nc：快速判断网络通不通

排查接口问题，首先得确认“通不通”，再下结论是谁的锅。

ping测试的是三层连通性，也就是主机能不能到达：

ping -c 4 8.8.8.8

-c 4表示只ping 4次就停，避免一直刷屏。如果ping不通，说明网络链路有问题，服务器可能都不在线。

端口是否开放，用telnet或者nc更直接。比如你怀疑服务器8000端口没开：

telnet 192.168.1.20 8000

如果端口通，终端会显示连接成功；如果不通，会卡住或提示无法连接。telnet命令的本职是远程登录，但在网络排查里它的“端口探测”能力更常用。不过telnet在部分新系统里没预装，碰到这种情况用nc：

nc -zv 192.168.1.20 8000

-z表示只扫描不发送数据，-v显示详细信息。这个测端口的方式比telnet更轻量，脚本里也可以用它判断服务状态。

提示：测完连通性之后，如果端口通但接口还是报错，那问题基本不在网络层，回到应用层看日志和代码，别在网络上死磕。

5.3 ss和netstat：查看端口被谁占了

端口被占用是Python开发里特别常见的问题。你启动Flask服务，提示Address already in use，第一反应是“我明明没开过8000端口啊”。这时候用ss查一下谁占着端口：

ss -lntp | grep 8000

拆解一下：-l表示只显示监听中的端口，-n表示显示数字地址和端口（不做域名解析，速度快很多），-t表示只看TCP连接，-p表示显示进程信息。输出里会看到PID和进程名，比如某个残留的Python进程。

老系统可能没有ss，用netstat也行：

netstat -lntp | grep 8000

找到占用端口的PID后，确认这个进程确实可以杀，再执行：

kill -15 PID

如果还不行再kill -9 PID。

更直接的方法是用fuser，一条命令杀掉占用端口的进程：

fuser -k 8000/tcp

这个命令会把8000端口上的进程杀掉，适合开发环境图省事用。但在生产环境别乱用，一定要先看清PID和进程是什么。

6. 版本控制与文件传输：Git和远程复制命令的日常

6.1 高频使用的Git命令

Git虽然不是Linux自带的命令，但Python程序员在Linux上写代码，Git就是日常。这里不展开讲Git原理，只说我每天都用、最实用的一组流程。

开发一个新功能时，第一件事是拉最新代码、建分支：

git pull origin main git checkout -b feature/login

改完代码，查看改动和状态：

git status git diff

git status看哪些文件改了、哪些文件没跟踪；git diff看具体改了哪些内容。这个习惯能帮你提交前再检查一遍，避免把调试用的print也提交上去。

提交代码：

git add src/ tests/ git commit -m "feat: add login endpoint" git push origin feature/login

提交信息我习惯写得具体一点，比如“feat:”表示新功能、“fix:”表示修复，这样git log看起来就像一份清晰的变更日志：

git log --oneline -10

临时要切分支但手头工作没做完，先存起来：

git stash git stash pop

git stash会把当前未提交的改动暂存起来，git stash pop再恢复。很多新手一换分支就panic，其实stash在手，天下我有。

6.2 服务器之间传文件：scp和rsync

Python项目部署到服务器后，经常需要在本地和服务器之间传文件。最简单的用scp：

# 本地文件传到服务器 scp ./app.py user@192.168.1.20:/opt/app/ # 服务器文件拉回本地 scp user@192.168.1.20:/opt/app/requirements.txt ./

scp会把文件原样复制过去，目录不存在不会自动创建。传整个目录加-r：

scp -r ./project user@192.168.1.20:/opt/

如果经常要同步大量文件，我更推荐rsync，它只传差异部分，效率高很多。比如把整个项目同步到服务器：

rsync -avz --delete ./project/ user@192.168.1.20:/opt/project/

-a是归档模式（保留权限、时间戳等），-v显示进度，-z传输时压缩，--delete表示本地删掉的文件远程也删掉，保持两边目录完全一致。我第一次用rsync同步一个包含几万个小文件的项目时，scp要跑十几分钟，rsync第一次同步稍微慢点，后续每次只要几秒钟，这个差距非常明显。

7. vim：没有IDE时的救急编辑器

7.1 模式切换与高频操作

在服务器上临时改个配置、改个Python脚本，没有VS Code怎么办？几乎每台Linux机器都自带vim，学会基础操作能救命。

vim的核心是“模式”：普通模式、插入模式、命令行模式。刚打开vim是普通模式，按i进入插入模式才能打字，按Esc回到普通模式。保存退出是ZZ或者:wq，不保存退出是:q!。

在普通模式下，最常用的几个操作：

# 向下翻半屏 Ctrl+d # 跳到文件开头/结尾 gg G # 按行号跳转，比如跳到第100行 100G # 搜索关键词，按n向下继续查找，N向上回退 /error

编辑Python代码时，最实用的命令是批量缩进。选中多行之后按>整体右移、按<整体左移，能快速修正缩进错误。复制粘贴是yy复制一行、p粘贴，删除一行是dd，这些基础操作熟练之后，在服务器上改代码完全够用。

7.2 几个值得写进~/.vimrc的配置

vim默认界面很朴素，但几行配置就能让它好用很多。我自己一直用的最小配置：

set number " 显示行号 set tabstop=4 " Tab显示宽度 set shiftwidth=4 " 自动缩进宽度 set expandtab " 用空格代替Tab set syntax on " 语法高亮 set mouse=a " 支持鼠标操作

把这几行写进~/.vimrc，再用vim打开Python文件，感受完全不同。特别是expandtab，Python对缩进极其敏感，如果用Tab和空格混用，解释器大概率报TabError，统一成空格能避免很多恶心的问题。

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

8.1 权限类问题：Permission denied怎么办

在Linux上跑Python脚本，最常见的就是“Permission denied”。比如你写了个deploy.sh，执行./deploy.sh却提示权限不够，那是因为文件没有执行权限。查看权限用ls -l，第一列类似-rw-r--r--，如果没有x权限就执行不了。给脚本加执行权限：

chmod +x deploy.sh

如果是对某个目录没有写权限，比如/var/log，那就用sudo执行当前命令，或者给当前用户授权：

sudo python3 app.py

但要注意，sudo执行Python脚本时，脚本里操作的文件路径也都是root权限的，后面改起来会有些麻烦。能不用sudo尽量不用，宁可把日志目录的所有者改成当前用户：

sudo mkdir -p /var/log/myapp sudo chown -R $USER:$USER /var/log/myapp

这样之后运行脚本就不需要sudo了，日志文件也归当前用户管。

8.2 “command not found”问题怎么排查

这个我在前面谈PATH时提过，这里归纳成一套排查步骤。第一步确认命令是否真的装了，比如which pip3或pip3 --version，如果提示找不到，很可能pip3没装，用python3 -m pip --version试试。第二步如果python3 -m pip能用而pip3不行，说明pip3这个可执行文件不在PATH里。第三步检查PATH里有没有包含Python的bin目录：

echo $PATH

安装Python包之后特别容易出现这种“python能跑但pip命令找不到”的情况，我的处理方式是不纠结，直接用python3 -m pip install xxx，这个写法绝对可靠，因为它是通过Python解释器去调用pip模块，不依赖PATH。

除了pip，pyenv安装新版本后有时也会出现“python命令还是旧版本”的情况。这时检查一下pyenv versions，确认当前环境是否切换成功；再which python，看可执行文件路径是不是指向pyenv的shims。

8.3 Python日志中文乱码问题

Python程序在Linux服务器上输出中文日志，经常遇到乱码。多数情况下不是程序的问题，是系统的字符集不对。先检查当前locale：

locale

如果输出里有LANG=POSIX或C.UTF-8没配置好，就可能导致Python的stdout无法正确编码中文。解决办法有两个方向。第一，在启动服务前设置环境变量：

export LANG=en_US.UTF-8 export LC_ALL=en_US.UTF-8

第二，在Python代码层面强制指定标准输出编码：

import sys import io sys.stdout = io.TextIOWrapper(sys.stdout.buffer, encoding='utf-8')

或者更简单的方案，在系统d服务里加上Environment=PYTHONIOENCODING=utf-8，强制Python输出UTF-8编码。这几个方法对付日志中文乱码基本够用了。

8.4 问题排查速查表

我在团队内部做了张速查表，贴出来供你参考，遇到问题先对照一遍：

我个人的体会是，Linux命令这些东西，本质上就是一套跟操作系统对话的“短语”，你不需要把全网的命令都背下来，只要把高频的二十来条练到不用想就能敲出来，效率就能提升一大截。我在带新人的时候，一直建议他们每天抽出十五分钟，用ls、ps、grep、curl这几条命令去折腾一下自己的开发环境，坚持两周就会发现，很多以前要写一段Python脚本才能干的事，命令行里一条管道就搞定了。

最后再分享一个我自己的小习惯：我会在~/.bashrc里把常用的长命令alias成短命令，比如alias py='python3'、alias gs='git status'，少敲几个字符，长期下来真的能省不少时间。工具这东西，用得顺手比花里胡哨重要，希望这篇能帮你把Linux命令真正变成写Python的助力。