Python开发者必会的Linux命令：从环境搭建到部署排查

1. 为什么Python程序员离不开Linux命令

如果你写Python写了一段时间，大概率会遇到这样一个场景：本地代码跑得好好的，一放到服务器上就各种报错。环境不对、权限不够、路径找不到、进程起不来，光是定位这些问题就够折腾半天。这时候你才会意识到，Python语法写得再熟练，不会Linux命令，在开发这条路上始终是跛脚走路。

我见过不少Python开发者，IDE用得很溜，代码写得也漂亮，但一打开终端就犯怵。说实话，这不怪他们，现在很多教程都在教“怎么写代码”，却很少有人告诉他们“代码跑在哪里”“怎么让代码持续跑下去”“出了问题怎么查”。而这些问题的答案，全部藏在Linux命令里。

这篇内容不是那种把几百条Linux命令从头到尾罗列一遍的“命令大全”。那种东西你搜一下到处都是，但看完基本记不住，更用不上。我打算换一种思路，从Python开发者的真实工作流出发，按“你什么时候需要什么命令”来组织，把真正高频、真正能解决问题的命令讲透。比如你写了个爬虫要定时跑、写了个Web服务要部署上线、写了个数据处理脚本要挂在后台运行，这些场景分别需要哪些命令，我会一条一条讲清楚。

内容包括但不限于：环境搭建与Python版本管理、文件与目录的日常操作、代码的版本管理与线上同步、进程与服务的守护、日志的查看与排查、网络的检测与调试。每个命令我都会结合Python开发的真实场景来讲，告诉你这个命令解决什么问题、为什么这么用、有哪些坑要避开。适合刚接触Linux的Python新手，也适合已经在用但觉得不够系统的开发者。

2. 环境搭建与开发准备

2.1 Python版本管理：不装对版本，后面全是坑

很多Python开发者第一次在Linux上装Python就翻车。直接在系统里sudo apt install python3装出来的，往往是老掉牙的版本，可能连f-string语法都不支持。更麻烦的是，系统本身有一些工具依赖自带的Python，你贸然把系统Python换掉或者升级，轻则某个工具失效，重则系统直接出问题。

所以我的建议是：别去动系统自带的Python，而是用pyenv或者其他版本管理工具，单独装一个专门给开发用的Python。

# 安装pyenv curl https://pyenv.run | bash # 在.bashrc里加入pyenv初始化 echo 'export PATH="$HOME/.pyenv/bin:$PATH"' >> ~/.bashrc echo 'eval "$(pyenv init -)"' >> ~/.bashrc source ~/.bashrc # 安装指定版本的Python pyenv install 3.11.9 # 在项目目录里设定局部版本 pyenv local 3.11.9

这样做的逻辑很清楚：系统Python就像房子的承重墙，你不能乱动；pyenv则像给房子加装电梯，独立安装、随时切换，互不干扰。pyenv local会在当前目录生成一个.python-version文件，你进入这个目录，Python版本就自动切过去。顺带一提，这个文件本身也间接解决了“不同项目需要不同Python版本”的痛点，不用再折腾各种环境变量了。

2.2 虚拟环境与pip源配置

Python版本问题解决了，紧接着就是包管理。很多人习惯全局pip install，结果就是包越装越乱，版本冲突到你怀疑人生。好在虚拟环境是Python自带的方案，直接用就行。

# 创建虚拟环境 python -m venv venv # 激活虚拟环境 source venv/bin/activate # 退出虚拟环境 deactivate

激活之后，命令行前面会出现一个(venv)前缀，一眼就能确认你在虚拟环境里。装的所有包都只在这个目录下生效，项目间互相隔离。我见过有人每次都忘记激活虚拟环境，然后傻乎乎地对着报错干瞪眼，这里提醒一句：which python，看看指向的是不是venv目录下的解释器，比什么都管用。

另外，国内开发者用pip时经常遇到下载缓慢的问题。改一下全局配置，把镜像源换了，能省下大量等待时间。

mkdir -p ~/.pip cat > ~/.pip/pip.conf <<EOF [global] index-url = https://mirrors.aliyun.com/pypi/simple/ trusted-host = mirrors.aliyun.com EOF

这个配置文件是全局生效的，所有项目的pip都会走这个源。团队里如果有人问到pip太慢，直接把这个配置丢过去就行。这里也顺便说下为什么要用cat加EOF这种方式：如果你用文本编辑器去新建这个文件，很容易因为路径不对或者权限不足而失败，用命令直接生成文件是Linux下最稳的做法。

2.3 系统信息的排查：装什么都装不明白时的救命招

环境搭到一半，经常会有这种情况：程序编译报错缺某个库、跑起来提示依赖不存在、到底装了什么版本也搞不清楚。这些时候，下面这些命令能帮你快速摸清系统底细。

# 查看系统发行版信息（确认你在什么系统上） cat /etc/os-release # 查看内核版本 uname -a # 查看CPU信息 lscpu # 查看内存 free -h # 查看磁盘空间 df -h # 查端口占用（比如你的Django/Gunicorn要用的8000端口被谁占了） netstat -tlnp | grep 8000

这组命令里，netstat值得单独说说。做Web开发时，“端口被占用”是最常见的报错之一。别慌，netstat -tlnp能把所有正在监听的端口和对应的进程列出来，grep过滤出你关心的那一个，看一眼PID，再ps一下就知道是哪个程序占的。一套组合拳下来，问题基本定位。

2.4 安装常用开发工具的推荐姿势

有了Python，还需要装一些常用的开发工具。这里只推荐装了绝不亏的几个：

• git：版本管理，写代码的人都懂
• vim：至少在服务器上改配置时用得到
• curl/wget：下载文件、调试接口

Ubuntu系的系统用apt安装，CentOS系用yum，这里不再展开。有人会问：为什么不用IDE？我就把话说明白：你在服务器上排障的时候，是没有图形界面的，这时候vim就是你唯一的编辑器。不用学得多深，能打开文件、改几行、保存退出就够了。

3. 文件与目录的日常操作

3.1 目录管理与项目结构规划

Python项目的目录结构一多，就特别容易迷路。你写一个稍微正式点的项目，往往会有src、tests、docs、scripts这些目录，再加上venv和.git隐藏目录，文件一下子多了好几倍。如果连基本的目录操作都不熟，找文件都费劲。

# 创建多级目录（-p参数很关键，父目录不存在时会自动创建） mkdir -p src/utils # 递归查看目录树（-a显示隐藏文件，-h显示人类可读大小） ls -lah # 查看目录树（需要安装tree） tree -L 2 # 删除非空目录（-r递归，-f强制，慎用） rm -rf old_project # 移动/重命名 mv src/utils/helper.py src/utils/tools.py # 复制 cp -r templates templates_backup

tree -L 2这个命令特别适合展示项目结构，写技术文档时也经常用到。我自己写文章截图项目结构时就靠它，配合-I '__pycache__|venv|.git'参数还能把不相关的目录过滤掉，看起来很干净。rm -rf必须单独拿出来警告：这个命令没有回收站，用完就没了，尤其不要在root用户下随便敲。我吃过亏，删错目录后整个人是懵的，后来养成了一个习惯：重要目录先cp -r备份再删，宁可多占点空间也别冒险。

3.2 文件的查看与编辑：cat、less、vim的三层用法

看文件内容是Linux下最高频的操作之一，但很多人始终只用cat一个命令，遇到大文件就悲剧了。说一下我的习惯：

• 小文件（日志尾部、配置文件），用cat直接看
• 大文件（几十上百MB的日志），用less分页看
• 要改文件内容，用vim打开编辑

# 查看文件内容（带行号） cat -n config.py # 分页查看大文件（q退出，/搜索，空格翻页） less logs/app.log # 查看文件尾部（-f实时追踪，排日志必备） tail -f logs/app.log # 查看文件头部 head -20 logs/app.log

tail -f对Python开发者来说几乎必不可少。你写个脚本丢到后台跑，不确定它执行的进度？tail -f盯着日志看，输出的每一行都实时刷新，有异常也第一时间能看到。这比反复执行、反复刷新要高效得多。

再说说vim。很多人一进vim就出不来了，其实只需要记住三个操作：

• i进入插入模式，开始编辑
• Esc退出插入模式
• :wq保存退出，:q!不保存退出

就这三招，95%的服务器改配置场景都够用了。我见过有人在vim里误按Ctrl+S导致界面卡住，以为死机了，其实只是锁定屏幕，按Ctrl+Q就能恢复。

3.3 文件查找的两个核心命令：find与grep的配合

写Python的时候，最烦的就是“我记得那个函数写在一个文件里，但不知道在哪”。这时候grep加find就是你的最强组合。

# 在某个目录下查找所有py文件 find . -name "*.py" # 查找包含某个关键词的py文件（-r递归，-n显示行号） grep -rn "def process_data" --include="*.py" . # 忽略某些目录的搜索 grep -rn "TODO" --include="*.py" . --exclude-dir=venv

注意到一个细节没有：grep的时候指定了--include="*.py"，就是因为venv虚拟环境里可能有大量Python文件，不限定的话搜索结果会被干扰。做实际开发时，搜索范围一定要管好，否则几千个匹配结果等于没搜。

find还有个常用场景是找大文件、清理磁盘：

# 找出当前目录下大于100MB的文件 find . -size +100M # 找出7天前修改过的文件 find . -mtime +7 # 把查出来的文件直接删掉 find . -name "*.log" -exec rm {} \;

第三个命令，-exec加rm，意思是对查到的每个文件执行删除操作。这个命令效率很高，但危险性也大。建议先用前面不带-exec的版本确认结果，再动手删，别嫌多这一步。

3.4 文件上传下载与服务器同步

本地写代码，推到服务器上跑，文件传输是日常操作。这里有两个命令用得最多。

SCP（基于SSH的加密文件传输）适合临时传一两个文件：

# 本地文件传到服务器 scp local_file.py user@server_ip:/home/user/project/ # 从服务器下载文件到本地当前目录 scp user@server_ip:/home/user/project/data.json .

RSYNC适合同步整个目录，比如你要把本地项目代码同步到线上：

# 同步整个目录到服务器（-a归档模式，-v显示进度，-z压缩传输） rsync -avz --exclude="venv" --exclude=".git" ./ user@server_ip:/home/user/project/

rsync的优势在于增量同步：如果某个文件没有变化，它不会重复传输。第一次全量同步，之后只更新改动的部分，传大文件时能省下海量时间。我的习惯是：临时传文件用scp，长期维护项目同步用rsync。另外，排除venv和.git这两个目录几乎是必须的，虚拟环境和git历史传到服务器上既没必要，又拖慢速度。

4. 代码管理与部署上线

4.1 Git在Linux下的高频操作

Git不管在哪个系统里都是命令行操作，但Linux服务器上操作git更频繁，因为部署代码的时候没有图形界面。大部分Python项目的部署流程都是：服务器上git pull拉取最新代码，然后重启服务。

# 克隆代码到本地 git clone git@github.com:user/project.git # 查看仓库状态 git status # 添加所有改动到暂存区 git add . # 提交并写注释 git commit -m "fix: fix the bug in data processing" # 推送到远程 git push origin main # 拉取最新代码 git pull origin main # 查看提交历史 git log --oneline -10

这里想特别说下提交信息的问题。我看到很多人喜欢git commit -m "update"、git commit -m "fix"，这种提交信息在单人项目里还能忍，一旦团队协作或者自己回头翻历史，完全不知道当时改了什么。建议养成习惯，用英文写清楚修改内容，比如fix: fix the timeout issue in api calls，将来排查问题时能省大量时间。

服务器上的git pull还有一个小坑：如果本地有未提交的修改，git pull会报错。处理方式是git stash暂存修改，pull之后再git stash pop把改动恢复。这个命令组合值得记住，线上更新代码被卡住时，至少知道应急办法。

4.2 后台运行Python程序的两种方案

写好的Python脚本不可能总在前台跑着，你一关终端程序就停了。要让程序“挂”在服务器上持续运行，至少要会用下面两种办法。

最原始的办法是用nohup配合&：

nohup python main.py > logs/app.log 2>&1 &

拆解一下：nohup让进程忽略挂断信号，&将进程放入后台，> logs/app.log把标准输出写入日志，2>&1把错误输出也合并到同一个日志文件里。这样终端关了，程序还在跑。程序有没有在跑，可以用ps看看：

# 查找Python相关的进程 ps aux | grep python # 查找特定程序的进程 pgrep -f main.py

如果想要更正式地管理服务，就要用到systemd。它比nohup强的地方在于：服务崩溃了会自动重启、服务器重启了服务也会自动拉起、还能用status命令随时查看运行状态。下面是我常用的一个服务单元文件模板：

[Unit] Description=My Python API Service After=network.target [Service] User=www-data WorkingDirectory=/home/www-data/myapi Environment="PATH=/home/www-data/myapi/venv/bin" ExecStart=/home/www-data/myapi/venv/bin/gunicorn -w 4 -b 127.0.0.1:8000 app:app Restart=always RestartSec=3 [Install] WantedBy=multi-user.target

把这个文件放在/etc/systemd/system/myapi.service，然后执行：

systemctl daemon-reload systemctl enable myapi.service systemctl start myapi.service systemctl status myapi.service

enable是设置开机自启，status可以看到当前运行状态、最近日志、还有异常退出时的错误信息。部署Gunicorn、Celery这类服务时，用systemd是比nohup规范得多的做法。

4.3 日志查看与实时追踪的关键技能

日志是排查问题的第一现场，Python开发者在服务器上花时间最多的事情往往不是写代码，而是翻日志。

# 查看最近的日志（默认是文件末尾10行） tail logs/app.log # 实时追踪日志更新 tail -f logs/app.log # 按关键字搜索日志，并显示上下文 grep -n "Traceback" logs/app.log grep -B 5 -A 5 "TimeoutError" logs/app.log # 查看特定时间段内的日志 sed -n '/2024-01-01 10:00/,/2024-01-01 11:00/p' logs/app.log # 统计某个错误出现的次数 grep -c "Traceback" logs/app.log

grep -B 5 -A 5这个用法，B代表Before，A代表After，意思是把匹配行的前5行和后5行都打出来。Python的报错信息往往是一整个Traceback，只看一行不够，需要连带上下文才能定位到具体是哪个文件、哪一行抛的异常。这个细节特别有用，建议记下来。

sed按时间切片日志也很实用。日志文件动辄几百MB，你不可能全打开看，定位到具体时间点，再精确输出这一段，能节省大量时间。

5. 网络调试与接口联调

5.1 curl：调试API接口的万能工具

写了Web接口，总要自测一下。Python代码里可以用requests库发请求，但有时候就需要一条命令快速验证接口通不通，这时候curl是最顺手的。

# 发送GET请求 curl http://127.0.0.1:8000/api/users # 发送POST请求，带JSON数据 curl -X POST http://127.0.0.1:8000/api/users \ -H "Content-Type: application/json" \ -d '{"name": "zhangsan", "age": 25}' # 携带Token进行认证 curl -H "Authorization: Bearer your_token" http://127.0.0.1:8000/api/users # 查看响应头 curl -i http://127.0.0.1:8000/api/users

curl -i返回的响应头很关键：200是正常，301/302是重定向，401是未认证，403是没权限，500是服务端内部错误。看到状态码，心里基本就有谱了。

还有一个参数值得推荐：

# 完整输出请求和响应的所有细节 curl -v http://127.0.0.1:8000/api/users

-v会把TCP连接、发送的请求头、SSL握手过程全部打印出来。调接口时如果怀疑是网络层问题、证书问题、代理问题，用-v能把这些隐藏细节全都暴露出来。

5.2 用telnet和nc快速检测端口连通性

服务部署完，发现客户端连不上，到底是谁的问题？先确认端口开没开、能不能通。telnet是最直接的检测工具。

telnet 192.168.1.100 8080

如果连接成功，会显示连接已建立，进入空白交互界面。如果连接失败，提示Connection refused或超时，就说明对方端口没有服务在监听，或者中间有防火墙拦着。有些系统默认没装telnet，装一下就行：

apt install telnet

作为替代方案，nc（netcat）也能做端口检测，而且还能做更多事：

# 检测端口 nc -zv 192.168.1.100 8080 # 扫描一段端口范围 nc -z 192.168.1.100 8000-8100

平时做网络排查时，我习惯先用ping确认主机通不通，再用telnet或nc确认端口通不通。如果主机通但端口不通，基本可以断定是服务没启动、防火墙拦截、或监听地址不对（比如服务只监听了127.0.0.1，而客户端连的是公网IP）。层层定位，比瞎猜高效得多。

5.3 排查网络请求延迟和DNS问题的思路

Python程序偶尔会遇到请求第三方接口特别慢的情况。这种问题可能出在网络链路、DNS解析、对方服务性能上，需要用命令逐个排查。

# 查看DNS解析耗时 time nslookup api.example.com # 查看网络链路中每一跳的延迟 traceroute api.example.com # 查看本机网络信息 ip addr

time nslookup能看出DNS解析花了多久。如果解析时间很长，可以尝试换个DNS服务器，比如在/etc/resolv.conf里配置nameserver 223.5.5.5。traceroute能看到数据包经过的每一跳路由，延迟卡在某一跳时，基本能定位到是网络链路的问题。这些命令平时用不上，一到排查跨网访问慢的问题时，缺一个都别扭。

6. 进程与资源管理

6.1 进程查看与终止的实用姿势

Python程序出问题后，需要重启进程。Python的Gunicorn、Celery、爬虫脚本，都有一个父进程下面挂着多个子进程的结构。终止进程时如果不注意，经常会遇到“明明杀掉了，但过几秒又自动起来了”的诡异情况，其实是因为父进程还在，它会自动拉起新的子进程。

# 查看进程树 ps aux --forest | grep python # 按端口找PID lsof -i :8000 # 用PID终止进程 kill 12345 # 强制终止 kill -9 12345 # 按进程名终止（慎用，会把所有匹配的都杀掉） pkill -f main.py

处理方式要看情况：如果只想重启服务，先找到主进程（--forest视图下最顶层的那个），杀掉它，子进程自然会被接管或退出。如果是用systemd管理的服务，正规做法是systemctl restart myapi.service，不存在手工杀进程这种说法。

6.2 查看资源占用：CPU、内存、磁盘一网打尽

服务变慢了，第一反应通常是用top看一眼系统负载。

# 交互式查看进程资源占用 top # 按CPU排序 top -o %CPU # 按内存排序 top -o %MEM # 一次执行后直接退出（适合写入脚本） top -bn 1

在top的交互界面里，P按CPU排序，M按内存排序，q退出。看到某个Python进程CPU占用接近100%，多半是代码里有个死循环或者复杂的计算逻辑；看到内存持续猛涨不下降，要考虑是不是内存泄漏。排查Python代码的内存泄漏时，可以用tracemalloc模块或memory_profiler，但前提是你得先通过top发现这个异常。

磁盘方面常用的就是df和du：

# 查看分区使用量 df -h # 查看当前目录下每个子目录占用的空间 du -sh * | sort -rh | head -10

日志文件是最容易吃掉磁盘空间的东西。一两个GB的日志文件看起来没什么，但多个服务长期运行，日志能铺满整个磁盘。我的习惯是给日志加轮转，用Linux自带的logrotate，超过一定大小自动切割压缩，并设置保留份数。配置也不复杂：

cat > /etc/logrotate.d/myapp <<EOF /var/log/myapp/*.log { daily rotate 7 compress missingok notifempty copytruncate } EOF

这里daily表示每天轮转一次，rotate 7保留7份历史日志，compress将旧日志压缩，copytruncate在复制后清空原文件，这样即使服务还在往日志文件里写也不会出错。

6.3 定时任务的配置与管理

很多Python脚本是批处理性质的：每天凌晨跑一遍数据同步、每小时拉一次接口、每周清理一次临时文件。用Linux自带的crontab就能搞定。

# 编辑当前用户的定时任务 crontab -e # 查看当前用户的定时任务 crontab -l

一个典型的定时任务配置长这样：

# 每天凌晨2点执行数据同步脚本 0 2 * * * cd /home/user/project && venv/bin/python scripts/data_sync.py >> logs/cron.log 2>&1

解释一下五个时间字段：分 时 日 月 周。0 2 * * *表示每天的02:00执行。我的建议是：定时任务里不要用纯python，要写虚拟环境里的解释器绝对路径（/home/user/project/venv/bin/python），否则cron只能用系统默认的Python，装过的包都不存在，脚本必然报错。

还有一点：crontab里的环境变量跟登录终端不一样。默认PATH很短，很多命令找不到。如果你的脚本里调用了第三方命令，要么在脚本里写明绝对路径，要么在crontab文件顶部加上：

PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

6.4 软链接与PATH：解决命令找不到的问题

装完某软件后，系统提示command not found，这种问题很常见。原因无非两种：软件没装好，或者软件的安装路径不在PATH环境变量里。

# 查看当前PATH echo $PATH # 创建软链接（相当于Windows下的快捷方式） ln -s /usr/local/python3.11/bin/python3.11 /usr/local/bin/python3 # 在.bashrc中追加PATH echo 'export PATH="/opt/myapp/bin:$PATH"' >> ~/.bashrc source ~/.bashrc

软链接在Linux里是个特别常用的概念。Python包管理器pip自动安装的入口脚本都在/usr/local/python3.11/bin目录下，如果你用某个工具时提示找不到命令，去它的安装目录看一眼，然后在/usr/local/bin下补一个软链接就能解决。

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

7.1 Python开发者在Linux上最常见的10个报错

这些年帮人排查过不少Python项目在Linux上运行的问题，翻来覆去就是下面这些高频坑。我整理成一张速查表，遇到问题先按图索骥。

最后一条，bad interpreter这个报错经常把新手整懵。原因是Windows下编辑的脚本文件，换行符是\r\n，Linux下只认\n，导致Python解释器路径被拼上了\r这个不可见字符。解决办法是sed -i 's/\r$//' script.py，把这个隐藏的\r去掉就正常了。

7.2 排查问题的方法论：往死里看日志，往窄里查范围

最后聊一个比任何具体命令都重要的思路。很多人在服务器上排查问题时慌慌张张，东敲一条命令西敲一条命令，折腾半小时也没定位到原因。我的方法论只有两句话：往死里看日志，往窄里查范围。

什么是“往死里看日志”？就是不要只看报错那一行。Python的Traceback从上往下看，最底下的才是异常根因；而服务能正常返回结果，不代表没有警告信息，只是你没注意。我用tail -f追踪实时日志，用grep -B 5 -A 5看异常上下文，用sed按时间窗口切割日志，目的就一个：把当时发生了什么完整还原出来。

什么是“往窄里查范围”？用一个对比来理解：某个接口在服务器上能正常访问，从其他机器访问就超时，问题就先锁定在网络层而不是代码层；某个功能在本机跑得好好的，部署到服务器就出错，优先级先看环境差异而不是代码本身。逐层缩小范围，从网络到端口到进程到日志到代码，每一步都排除一批可能性，最后剩下的就是真相。

7.3 日常开发的高频命令清单（可直接抄作业）

说了这么多，最后给你一份可以直接写成便签贴在显示器旁边的清单：

# 日常开发三件套 pwd # 我在哪 ls -lah # 这有什么 cd /path # 去哪 # 改代码 vim file.py # 编辑文件 grep -rn "xxx" --include="*.py" . # 全局搜代码 # 跑程序 python main.py # 前台运行 nohup python main.py > app.log 2>&1 & # 后台运行 tail -f app.log # 看日志 # 部署 git status git add . git commit -m "message" git pull origin main git push origin main # 查问题 ps aux | grep python # 进程在不在 netstat -tlnp | grep 8000 # 端口通不通 df -h # 磁盘满没满 free -h # 内存够不够 top # 谁占用资源

这份清单里的命令我每天都在用，没有一条是偏门技巧，都是高频到不能再高频的基础操作。把这些命令用熟，你的Python开发就能真正做到“本地写代码、服务器跑代码”的无缝衔接，不再被环境问题绊住脚。

8. 写在最后的一点经验

从我自己的经历来看，Python和Linux的关系，有点像驾照和车的关系。Python语法是你考到的驾照，Linux命令是你真正上路时开的车。拿着驾照不敢上路的人很多，原因就是只学了开车理论，没实操过“挂挡、踩油门、看后视镜”。

有些命令短时间内可能用不上，比如traceroute、logrotate、systemctl，但当你的项目从一个单纯的脚本成长为真正的线上服务时，你会回来找它们的。我建议你先把最核心的那一批命令，cd、ls、grep、find、ps、netstat、tail、vim、git、nohup，练成本能反应。熟练到不假思索的程度，你才能把注意力放在真正重要的事情上——代码本身、业务逻辑、架构设计。

另外，千万不要觉得“背命令”是笨办法。命令这东西，多敲几遍就熟了。我到现在有时候也会为了一条find -exec的写法和一段sed命令去查手册，这不丢人。真正丢人的是连查的意愿都没有，碰到问题就卡死在那里。

我强烈建议你亲手搭一台Linux虚拟机或者买个便宜的小服务器，把上面这些命令一个一个敲一遍。踩坑、报错、重来，这个过程本身才是最快的学习方式。就像学Python一样，永远不要等“准备好”再动手，先跑起来，遇到问题再解决。你踩过的每一个坑，最终都会变成你的经验积累。