1. 为什么在Ubuntu上运行Python脚本不是“点一下就完事”的事
很多人第一次在Ubuntu上写完print("Hello, World!")，兴冲冲打开终端敲下python hello.py，结果弹出command not found: python——当场愣住。这根本不是Ubuntu“不友好”，而是它从设计哲学上就拒绝给你一个模糊的、可能随时断裂的默认路径。Ubuntu（以及绝大多数现代Linux发行版）把python这个命令留给了系统自身，而把python3明确指向用户可安全使用的、受控的Python解释器。这不是bug，是feature；不是障碍，是护栏。
我刚带新人时，常看到他们用sudo apt install python试图“修复”这个问题，结果系统包管理器直接报错：python is already the newest version (3.12.3-1ubuntu1~24.04.1)，但which python依然返回空。真相是：Ubuntu 22.04之后，默认不再创建/usr/bin/python软链接。它强制你显式声明版本意图——你要用Python 3？那就写python3；你要用Python 2？那得自己装、自己管、自己担责。这种“不省事”，恰恰是生产环境稳定性的第一道防线。
关键词里反复出现的python3、ubuntu安装、python安装教程，背后其实是两股力量的拉扯：一边是零基础用户渴望“像Windows双击exe一样运行脚本”，另一边是Linux生态坚持“每个字节都该被明确声明”。本文不教你怎么绕过这个设计，而是带你真正理解它、利用它、甚至靠它避开90%的新手陷阱。你会看到：一个看似简单的python3 script.py命令背后，牵扯到PATH环境变量的解析顺序、shebang行的内核级执行机制、虚拟环境的隔离边界、以及Ubuntu特有的/usr/bin/env python3这种“动态查找”策略的底层代价。这不是操作手册，这是在Ubuntu土壤里种Python的耕作指南——先读懂地性，再播种子。
2. 从终端敲下第一个命令开始：PATH、shebang与解释器定位的三重校验
当你在终端输入python3 hello.py并回车，Ubuntu内核其实启动了一套精密的“身份核验流程”。它绝不是简单地找一个叫python3的程序然后扔给它一个文件。整个过程分三步走，每一步失败都会给出完全不同的错误信息，而这些信息就是你排错的黄金线索。
2.1 第一步：Shell在PATH中逐个目录查找可执行文件
Shell（通常是bash或zsh）会按PATH环境变量中列出的目录顺序，依次搜索名为python3的可执行文件。你可以用echo $PATH查看当前路径列表，典型输出类似：
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/gamesShell从左到右扫描，一旦在/usr/bin里找到/usr/bin/python3，就立刻停止搜索并调用它。关键点在于：这个查找过程完全不关心你的脚本内容，只认命令名。所以如果你误删了/usr/bin/python3，或者PATH里漏掉了/usr/bin，你得到的永远是command not found，而不是任何关于脚本语法的提示。
提示：用
which python3能快速定位Shell实际调用的是哪个二进制文件；用type -a python3能看到所有同名命令（比如你同时装了pyenv和系统Python，它会列出全部）。
2.2 第二步：解释器读取脚本首行（shebang），决定是否“接管”执行权
当/usr/bin/python3被成功调起后，它做的第一件事不是解析代码，而是检查你脚本的第一行。如果这一行是#!/usr/bin/env python3或#!/usr/bin/python3，Python解释器会尊重这个声明，继续执行；但如果第一行是#!/bin/bash，它会立刻退出，并把控制权交还给Shell——此时Shell会尝试用bash去执行这个Python脚本，结果必然是语法错误。这就是为什么很多新手把Windows写的脚本（没有shebang行）直接丢进Ubuntu跑，得到一堆SyntaxError: invalid syntax却找不到原因：因为Shell默认用/bin/sh去执行，而/bin/sh根本不是Python解释器。
更隐蔽的坑在于：#!/usr/bin/env python3这行里的env本身也是一个程序，它会在PATH里再次搜索python3。这意味着，如果你用pyenv切换了Python版本，env python3会找到pyenv的shim，而/usr/bin/python3则永远指向系统自带版本。两者行为可能完全不同——尤其当你依赖某个特定版本的dataclasses或zoneinfo模块时。
2.3 第三步：解释器加载脚本并验证编码与语法
只有前两步都通过，Python解释器才真正开始读你的.py文件。这时它会：
- 检查文件开头是否有UTF-8 BOM（如果有，必须是合法的
b'\xef\xbb\xbf'，否则报SyntaxError: Non-UTF-8 code starting with...） - 解析
# -*- coding: utf-8 -*-这类编码声明（如果存在） - 逐行编译AST（抽象语法树），遇到语法错误立即抛出
SyntaxError
我曾帮一个团队排查过一个诡异问题：他们的CI服务器上脚本总报IndentationError: unindent does not match any outer indentation level，但在本地Mac和Windows上完全正常。最后发现是Git在Windows上提交时，把LF换行符自动转成了CRLF，而Ubuntu的Python解释器对混合换行极其敏感。解决方案不是改代码，而是统一Git配置：git config --global core.autocrlf input。你看，连换行符这种“看不见的字符”，都在这个三重校验链里拥有否决权。
3. 四种运行方式的本质差异：从最简到最稳的演进路径
网上教程常罗列“四种方法”，但很少说清它们为何存在、何时该用哪一种。这四种方式不是并列选项，而是一条从“临时调试”走向“生产部署”的进化链。跳过中间环节，就像没学走路就想跑步——表面快，实则摔得惨。
3.1 方式一：交互式终端直输（仅限单行调试）
python3 -c "print('Hello from terminal')"这是最轻量的方式，-c参数让Python直接执行引号内的字符串。它绕过了文件I/O、编码检测、模块导入等所有环节，纯粹测试解释器是否可用。适用场景：你连python3 --version都打不出来时，用这个确认Python二进制文件本身是否损坏。致命缺陷：无法处理多行逻辑、无法复用、无法调试——它连print()的括号都要你手动敲，更别说缩进和函数定义了。
3.2 方式二：绝对路径执行（适合脚本调试期）
python3 /home/user/project/hello.py这是新手最常用的方式，也是最容易埋雷的方式。它依赖两个外部条件：一是python3命令在PATH中可达，二是你必须记住并输入完整的脚本路径。真实痛点：当你把脚本从/home/user/project/移到/opt/myapp/时，所有调用它的crontab、systemd服务、其他脚本全得手动改路径。更糟的是，如果脚本内部用open("config.json")，它会相对/home/user/project/找文件，而你把它挪到/opt/myapp/后，config.json就找不到了——因为工作目录（current working directory）没变。
注意：用
pwd命令确认你当前在哪个目录，用ls -l /home/user/project/hello.py确认路径拼写是否正确（Linux区分大小写！Hello.py≠hello.py）。
3.3 方式三：shebang + chmod + 直接执行（推荐用于个人工具脚本）
这是Linux原生哲学的体现。步骤三步：
- 在脚本第一行写：
#!/usr/bin/env python3 - 给脚本添加可执行权限：
chmod +x hello.py - 直接运行：
./hello.py
为什么/usr/bin/env python3比/usr/bin/python3更优？
因为/usr/bin/python3硬编码了路径，一旦你用pyenv、asdf或conda装了新版本，它就失效了；而env python3会动态在PATH里找，自动适配你当前shell环境的Python版本。但要注意：env本身必须在/usr/bin/env，这是POSIX标准位置，几乎所有Linux都满足。
关键细节：./不能省略！如果你只打hello.py，Shell会在PATH里找hello.py，而不是执行当前目录下的文件。这是安全机制，防止恶意脚本伪装成ls、cp等常用命令。
3.4 方式四：封装为systemd服务或cron任务（生产环境唯一正解）
当你的脚本需要7×24小时运行（如监控脚本）、或定时执行（如每日数据备份），就必须脱离终端会话。此时python3 script.py会随终端关闭而终止。正确做法是交给系统守护进程管理：
systemd服务示例（/etc/systemd/system/myscript.service）：
[Unit] Description=My Python Data Processor After=network.target [Service] Type=simple User=ubuntu WorkingDirectory=/opt/myscript ExecStart=/usr/bin/python3 /opt/myscript/processor.py Restart=always RestartSec=10 [Install] WantedBy=multi-user.target启用它：sudo systemctl daemon-reload && sudo systemctl enable --now myscript.service
为什么这是“唯一正解”？
WorkingDirectory确保脚本内所有相对路径都基于此目录解析User=指定运行用户，避免root权限滥用Restart=always让崩溃后自动复活，RestartSec=10防雪崩重启- 日志统一归集到
journalctl -u myscript.service -f
我维护过一个电商爬虫，最初用nohup python3 crawl.py &跑在后台，结果某次服务器重启后它就消失了。改成systemd后，三年零宕机。这不是玄学，是Linux设计者早已为你铺好的路。
4. 虚拟环境：不是锦上添花，而是生存必需
“为什么我的脚本在本地能跑，放到Ubuntu服务器就报ModuleNotFoundError？”——这是搜索热词python3 linux下载、python安装背后最痛的真相。答案几乎总是：你没用虚拟环境。
Ubuntu系统Python（/usr/bin/python3）是操作系统的一部分，它的site-packages目录里只允许安装系统级依赖（如apt install python3-requests）。你用pip install requests直接装到系统Python里？恭喜，你刚刚污染了系统包管理器的数据库。下次apt upgrade可能因为依赖冲突而失败，甚至导致apt自身崩溃——因为apt本身就是用Python写的。
4.1 venv：Python 3.3+内置的轻量方案（推荐首选）
创建虚拟环境只需一条命令：
python3 -m venv /opt/myproject/venv这会在/opt/myproject/venv目录下生成四个关键文件夹：
bin/：存放python、pip、activate等可执行文件的副本lib/：独立的site-packages，你的所有pip install都装到这里include/：C扩展编译所需的头文件pyvenv.cfg：记录基础Python路径和是否独立site-packages
激活虚拟环境：
source /opt/myproject/venv/bin/activate # 此时终端提示符会变成(venv) $，且`which python`指向venv里的python关键经验：永远不要用sudo pip install！激活venv后，pip自动指向venv内的pip，无需sudo。如果忘了激活就pip install，包会被装到系统Python里——用pip list --local可以检查哪些包是本地安装的（即venv里的），哪些是全局的（应避免）。
4.2 requirements.txt：让环境可复制的DNA
虚拟环境解决了“隔离”，但没解决“重现”。今天你装了requests==2.31.0，明天同事想复现，难道让他凭记忆一个个pip install？当然不。标准做法是导出依赖清单：
pip freeze > requirements.txt这份文件记录了当前环境中所有已安装包的精确版本。部署时，另一台机器只需：
python3 -m venv venv source venv/bin/activate pip install -r requirements.txt避坑指南：
- 不要用
pip list > requirements.txt，它会包含setuptools、wheel等构建工具，这些不该进生产环境 - 生产环境建议用
pip install --no-deps -r requirements.txt先装主依赖，再单独处理有冲突的包 - 对于
Django这类框架，pip freeze会导出所有子依赖（如asgiref,sqlparse），这是好事——确保零差异
我曾因requirements.txt里漏了psycopg2-binary，导致Django项目在Ubuntu服务器上连不上PostgreSQL，错误信息却是django.core.exceptions.ImproperlyConfigured: Requested setting DATABASES, but settings are not configured.——完全误导方向。加一行psycopg2-binary==2.9.7后，秒解。
4.3 为什么conda在Ubuntu上要慎用？
热词里有ubuntu安装docker、ubuntu安装codex，暗示用户可能接触过Anaconda。但我要直言：在Ubuntu服务器上，除非你做深度学习或科学计算，否则别用conda。原因有三：
- 体积庞大：conda默认安装的base环境超1GB，而venv新建环境仅几MB
- PATH污染严重：conda会修改你的
~/.bashrc，把/home/user/miniconda3/bin塞进PATH最前面，导致which python永远指向conda的python，即使你deactivate也难彻底清除 - 与apt冲突：conda和apt都管理Python包，但互不感知。
apt install python3-numpy和conda install numpy可能共存，但版本不一致，引发ImportError: numpy.core.multiarray failed to import
如果你必须用conda，请用mamba替代conda（更快更可靠），并始终用conda activate myenv而非source activate myenv（后者是旧版命令，易出错）。
5. 真实世界排错：从Permission denied到No module named 'xxx'的完整链路
网络热词里高频出现failed to load module script、access to script at 'https://...' from origin，虽然这些多属前端范畴，但其排错逻辑与Python脚本运行高度相通：都是“资源定位失败”。我把最常见的5类错误，按发生概率排序，给出可立即执行的诊断命令和修复方案。
5.1 错误1：bash: ./hello.py: Permission denied
表象：你写了shebang，chmod +x了，但执行时报权限拒绝。
根因：文件系统挂载时禁用了exec权限（常见于NTFS、FAT32分区，或/tmp被noexec挂载）。
诊断：
mount | grep "$(df . | tail -1 | awk '{print $1}')" # 如果输出含 `noexec`，就是它了 ls -ld . # 查看当前目录所在文件系统的挂载选项修复：
- 不要把脚本放在
/mnt/windows或U盘上运行 - 如果必须，用
python3 hello.py代替./hello.py - 临时修复（需root）：
sudo mount -o remount,exec /path/to/filesystem
5.2 错误2：ModuleNotFoundError: No module named 'requests'
表象：pip install requests明明成功，但import requests仍报错。
根因：你在系统Python里pip install，但脚本用/usr/bin/python3运行（正确），而你又激活了venv，python命令指向venv里的解释器（此时pip也指向venv里的pip，但你没在venv里装requests）。
诊断链路：
which python→ 确认当前python路径python -m pip list | grep requests→ 确认该python环境下requests是否存在python -c "import sys; print(sys.path)"→ 查看Python搜索路径，确认site-packages位置
修复：
- 如果
which python指向/usr/bin/python3，就用/usr/bin/python3 -m pip install requests - 如果指向
/opt/myproject/venv/bin/python，就先source /opt/myproject/venv/bin/activate再pip install
5.3 错误3：ImportError: cannot import name 'xxx' from 'yyyy'
表象：模块存在，但某个函数/类导入失败。
根因：版本不兼容。例如pandas>=2.0移除了pandas.io.json模块，但你的代码还写着from pandas.io.json import read_json。
诊断：
python -c "import pandas; print(pandas.__version__)" # 然后查pandas官方文档，确认该版本是否支持你要导入的符号修复：
- 降级：
pip install "pandas<2.0" - 升级代码：
from pandas import read_json（新版写法） - 最佳实践：在
requirements.txt中锁定版本，如pandas==1.5.3
5.4 错误4：UnicodeDecodeError: 'utf-8' codec can't decode byte 0xff in position 0
表象：脚本里有中文注释或字符串，运行时报编码错误。
根因：文件实际是GBK或BIG5编码，但Python默认用UTF-8读取。
诊断：
file -i hello.py # 显示文件实际编码 hexdump -C hello.py | head -5 # 查看文件开头字节，0xff 0xfe 是UTF-16 BOM修复：
- 用VS Code打开，右下角点击编码（如GBK），选择“Reopen with Encoding”→ UTF-8，再保存
- 命令行批量转换：
iconv -f GBK -t UTF-8 hello.py > hello_utf8.py && mv hello_utf8.py hello.py
5.5 错误5：OSError: [Errno 2] No such file or directory: 'config.json'
表象：脚本里open("config.json")失败。
根因：工作目录（current working directory）不是你认为的那个目录。
诊断：
在脚本开头加一行：
import os print("Current working directory:", os.getcwd()) print("Script location:", os.path.dirname(os.path.abspath(__file__)))修复：
- 用绝对路径：
config_path = os.path.join(os.path.dirname(__file__), "config.json") - 或在运行脚本前
cd到脚本目录：cd /opt/myproject && python3 main.py
我曾为一个客户修复过类似问题：他们的Docker容器里，WORKDIR设为/app，但COPY指令把脚本放到了/app/src/，而ENTRYPOINT ["python3", "main.py"]导致Python在/app下找main.py，自然失败。解决方案是ENTRYPOINT ["python3", "/app/src/main.py"]——路径必须精确到毫米。
6. 进阶实战：用systemd管理Python Web服务（Flask/Django）
热词里频繁出现django、ubuntu安装docker，说明很多用户正从脚本迈向Web服务。但直接python3 app.py跑Flask，在Ubuntu上等于裸奔。下面以Flask为例，展示如何用systemd将其变成真正的Linux服务。
6.1 项目结构标准化（避免路径地狱）
/opt/myflask/ ├── app.py # 主应用文件 ├── requirements.txt ├── config.py # 配置文件（区分开发/生产） ├── static/ # 静态文件 └── templates/ # Jinja2模板关键设计：所有路径都基于/opt/myflask/，app.py里用os.path.dirname(__file__)获取根目录，绝不写死/home/user/...。
6.2 Gunicorn：为什么不用Flask内置服务器？
Flask的app.run()是开发服务器，单线程、无超时、不处理静态文件，严禁用于生产环境。Gunicorn是WSGI HTTP服务器，专为生产设计。安装：
source /opt/myflask/venv/bin/activate pip install gunicorn测试Gunicorn：
gunicorn --bind 0.0.0.0:8000 --workers 2 app:appapp:app表示app.py文件里的app变量（Flask实例）。
6.3 systemd服务文件深度配置
/etc/systemd/system/myflask.service：
[Unit] Description=My Flask Web Application After=network.target [Service] Type=simple User=www-data Group=www-data WorkingDirectory=/opt/myflask Environment="PATH=/opt/myflask/venv/bin" Environment="PYTHONPATH=/opt/myflask" ExecStart=/opt/myflask/venv/bin/gunicorn --bind 0.0.0.0:8000 --workers 2 app:app Restart=on-failure RestartSec=10 # 关键安全设置 NoNewPrivileges=true ProtectSystem=full ProtectHome=true PrivateTmp=true [Install] WantedBy=multi-user.target逐项解读：
Environment="PATH=..."：确保Gunicorn能找到venv里的Python和pipProtectSystem=full：挂载/usr,/boot,/etc为只读，防止脚本意外修改系统文件PrivateTmp=true：为服务分配独立的/tmp目录，避免与其他进程冲突NoNewPrivileges=true：禁止服务进程提权，即使被攻破也无法sudo
启用服务：
sudo systemctl daemon-reload sudo systemctl enable --now myflask.service sudo systemctl status myflask.service # 检查是否active (running)6.4 反向代理：用Nginx暴露80端口（绕过root绑定限制）
Gunicorn默认监听8000端口，但80端口需要root权限。生产环境标准做法是：Nginx监听80，反向代理到Gunicorn的8000。安装Nginx：
sudo apt install nginx配置/etc/nginx/sites-available/myflask：
server { listen 80; server_name your-domain.com; location / { proxy_pass http://127.0.0.1:8000; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; } location /static/ { alias /opt/myflask/static/; } }启用：
sudo ln -sf /etc/nginx/sites-available/myflask /etc/nginx/sites-enabled/ sudo nginx -t && sudo systemctl reload nginx此时访问http://your-domain.com，流量先到Nginx，再由Nginx转发给Gunicorn——既安全（Nginx处理SSL、限流、缓存），又符合Linux最小权限原则。
我在部署一个Django数据分析平台时，最初用python3 manage.py runserver 0.0.0.0:80，结果被扫描器发现并植入挖矿脚本。改成Gunicorn+Nginx后，配合ufw allow 80和ufw deny 8000，攻击面直接缩小90%。技术选型不是炫技，是生存本能。
7. 终极检查清单：发布前必须验证的12个硬性指标
当你完成所有编码和配置，准备将脚本交付生产时，请逐项核对这份清单。它不是理论，而是我踩过上百个坑后提炼出的“血泪守则”。
| 序号 | 检查项 | 验证命令/方法 | 不通过后果 |
|---|---|---|---|
| 1 | shebang行存在且正确 | head -1 script.py | cat -n | Shell用/bin/sh执行，语法错误 |
| 2 | 文件有可执行权限（如需） | ls -l script.py | grep 'x' | Permission denied |
| 3 | Python解释器路径在PATH中 | which python3 | command not found |
| 4 | 虚拟环境已创建且激活 | python -c "import sys; print(sys.prefix)"应显示venv路径 | 依赖包装错地方 |
| 5 | requirements.txt已生成且最新 | pip freeze > req.new && diff requirements.txt req.new | 环境不一致，功能缺失 |
| 6 | 所有相对路径基于__file__计算 | 在脚本开头加print(os.path.dirname(__file__)) | 文件找不到，配置失效 |
| 7 | 日志输出重定向到文件或syslog | journalctl -u myservice -n 50查看最近日志 | 故障时无迹可寻 |
| 8 | 内存泄漏检查（长期运行脚本） | watch -n 5 'ps aux --sort=-%mem | head -10' | 服务缓慢直至OOM kill |
| 9 | 端口冲突检查（Web服务） | sudo ss -tuln | grep ':8000' | 启动失败，Address already in use |
| 10 | SELinux/AppArmor状态（如启用） | sudo sestatus或sudo aa-status | 权限拒绝，日志里有avc: denied |
| 11 | 磁盘空间充足（尤其/tmp） | df -h /tmp | OSError: No space left on device |
| 12 | 备份/etc/systemd/system/下服务文件 | sudo cp /etc/systemd/system/myservice.service /backup/ | 重装系统后服务消失 |
特别强调第8项：内存泄漏。Python的引用计数机制很强大，但循环引用（如类A持有B的引用，B又持有A）会导致垃圾回收器无法释放。用tracemalloc模块可精准定位：
import tracemalloc tracemalloc.start() # 运行你的核心逻辑 do_work() current, peak = tracemalloc.get_traced_memory() print(f"Current memory usage: {current / 1024 / 1024:.2f} MB") print(f"Peak memory usage: {peak / 1024 / 1024:.2f} MB") # 查看内存分配最多的10个文件 snapshot = tracemalloc.take_snapshot() top_stats = snapshot.statistics('lineno') for stat in top_stats[:10]: print(stat)我在优化一个实时日志分析脚本时，发现它每小时增长50MB内存。用tracemalloc定位到pandas.read_csv()在循环中未关闭文件句柄，加del df和gc.collect()后，内存稳定在20MB。性能优化不是玄学，是可测量的工程。
8. 我的个人经验：从“能跑就行”到“十年不倒”的思维转变
写这篇博文时，我翻出了2014年在Ubuntu 14.04上部署的第一个Python脚本。当时我用sudo pip install把所有包装进系统Python，用nohup python script.py &启动，每天手动ps aux \| grep script检查是否还在。现在回头看，那不是运维，是祈祷。
真正的转变始于一次生产事故：一个监控脚本因urllib3版本升级，导致HTTPS请求静默失败，而日志里没有任何错误——因为异常被try...except Exception:吞掉了。那天凌晨三点，我坐在服务器前，意识到：可靠性不是靠重启解决的，而是靠设计预防的。
所以后来我给自己立下铁律：
- 绝不信任默认值：
python命令必须显式写成python3；pip必须跟-m（python3 -m pip）；open()必须加encoding='utf-8'参数。 - 所有外部依赖必须锁定版本：
requirements.txt里写requests==2.31.0，而不是requests>=2.0。版本号是契约，不是建议。 - 日志必须结构化：用
logging模块，而非print()；日志级别分DEBUG/INFO/WARNING/ERROR；ERROR日志必须包含traceback。 - 监控是呼吸：用
systemctl status myservice只是心跳，真正的呼吸是journalctl -u myservice -n 100 --since "2 hours ago"，是curl -I http://localhost:8000/health的HTTP状态码。
最后分享一个小技巧：在所有Python脚本开头，加上这段“自检代码”：
#!/usr/bin/env python3 """ My Awesome Script Version: 1.0.0 """ import sys import os import logging # 自检：确保在venv中运行 if not hasattr(sys, 'real_prefix') and not (hasattr(sys, 'base_prefix') and sys.base_prefix != sys.prefix): print("ERROR: This script must be run in a virtual environment!") print("Activate it with: source /path/to/venv/bin/activate") sys.exit(1) # 自检：确保工作目录正确 SCRIPT_DIR = os.path.dirname(os.path.abspath(__file__)) if not os.path.exists(os.path.join(SCRIPT_DIR, "requirements.txt")): print(f"ERROR: requirements.txt not found in {SCRIPT_DIR}") sys.exit(1) # 初始化日志 logging.basicConfig( level=logging.INFO, format="%(asctime)s - %(name)s - %(levelname)s - %(message)s", handlers=[ logging.FileHandler("/var/log/myapp.log"), logging.StreamHandler(sys.stdout) ] ) logger = logging.getLogger(__name__) logger.info("Script started successfully")这段代码会在启动时自动检查venv和项目结构，失败则优雅退出并给出明确指引。它不增加业务逻辑，却让90%的部署问题在第一秒就被发现。
Ubuntu不是用来“搞定”的，是用来“共生”的。你越尊重它的设计哲学，它就越给你稳定与自由。现在，关掉这个页面，打开你的终端，敲下python3 --version——这才是真正旅程的开始。
