CentOS怎么执行python脚本命令行

在 CentOS 系统的终端命令行中执行 Python 脚本，核心方式主要分为两类：直接调用 Python 解释器传入脚本路径（如 python3 script.py），或者在脚本首行配置 Shebang 解释器声明并赋予可执行权限后直接调用（如 ./script.py）。这两种方式在系统底层调用的链路、对文件权限的依赖以及适用场景上存在清晰的分工。掌握这两种基本操作后，结合命令行参数解析、I/O 输出重定向以及 nohup 后台守护运行，即可满足日常开发测试与生产自动化运维的全部需求。

一、CentOS 环境准备与解释器检查

在执行任何 Python 脚本之前，首要任务是明确当前 CentOS 系统安装的 Python 版本及其真实二进制路径。CentOS 拥有较为特殊的系统工具链历史：以被广泛部署的 CentOS 7 为例，系统底层自带的 /usr/bin/python 默认是指向 Python 2.7.5 的软链接，且系统核心包管理工具 yum 深度依赖该版本；而在 CentOS Stream 8 或 9 中，Python 3 已经成为系统默认环境。因此在 CentOS 命令行中操作时，应始终养成显式指定 python3 的习惯。

登录 CentOS 终端后，首先执行以下命令检查 Python 3 的安装情况：

[root@centos ~]# python3 --version
Python 3.6.8 （示例输出：具体版本取决于系统软件源）

[root@centos ~]# which python3
/usr/bin/python3

如果终端提示 bash: python3: command not found，说明当前操作系统尚未安装 Python 3 环境。在 CentOS 7 / 8 / Stream 系统中，可通过系统的官方包管理器进行规范安装：

[root@centos ~]# yum install -y python3
# 在 CentOS 8 / Stream 9 环境中亦可使用 dnf install -y python3

二、命令行执行 Python 脚本的两种核心方法

方法一：通过 Python 解释器直接显式调用

这是最常用、最直观的执行方式。它的语法是将 Python 解释器命令放在首位，脚本文件路径作为参数紧跟其后：

# 语法：python3 [脚本路径]
[root@centos ~]# python3 hello.py

# 如果脚本在其他目录下，可以使用绝对路径或相对路径
[root@centos ~]# python3 /data/scripts/backup.py

这种执行方式的工作原理是：Bash Shell 在当前环境变量 $PATH 中检索到 python3 二进制程序，创建子进程启动解释器，并将后面的路径字符串传给解释器；解释器以普通文件读取（Read）权限打开该脚本，完成语法解析并执行。使用该方法时，脚本文件只需要拥有读取权限（chmod +r），完全不需要具备执行权限（+x）。

方法二：配置 Shebang 行与文件执行权限独立运行

在 Linux 运维体系中，如果希望 Python 脚本像系统的标准二进制命令（如 ls、top）一样直接通过路径或命令名调用，就需要使用 Shebang 引导机制。该方式分为两个步骤：

第一步：在脚本首行添加 Shebang 解释器声明。 使用编辑器（如 vi demo.py）打开脚本，在文件的第一行写入以下内容：

#!/usr/bin/env python3
# -*- coding: utf-8 -*-
import sys

print("当前运行的 Python 版本:", sys.version)

这里推荐使用 #!/usr/bin/env python3，而不是硬编码的 #!/usr/bin/python3。原因是 env 程序会在系统当前会话的 $PATH 变量中动态查找名为 python3 的程序。当后续切换到了 Python 虚拟环境（Virtualenv）或通过 Conda 自定义安装的 Python 环境时，env 能自动匹配到激活的解释器，从而具备更好的跨环境移植性。

第二步：为脚本文件增加可执行权限（+x）。 在 CentOS 命令行中，新建的普通文本文件默认只有读写权限（通常为 644），系统出于安全策略不允许直接作为程序执行。需要执行 chmod 赋予其执行位：

[root@centos ~]# chmod +x demo.py
[root@centos ~]# ./demo.py
当前运行的 Python 版本: 3.6.8 (default, Nov 10 2020, 16:20:59)

在当前目录下运行时，必须在文件名前加上 ./（表示当前工作目录）。这是 Linux 系统的基础安全机制：当前目录默认不在 $PATH 中，以防止当前目录下恶意同名脚本被意外优先调起。

三、命令行参数传递与 I/O 重定向

在实际的自动化任务与定时运维场景中，很少执行没有参数的纯静态脚本。通常需要从命令行向 Python 脚本内部动态传入配置项，如处理的日期、环境标识、并发线程数等。

1. 命令行参数的传入与获取

在命令行运行脚本时，直接在文件名后使用空格分隔附加参数即可：

[root@centos ~]# python3 worker.py --env prod --limit 50

在 Python 脚本内部，处理这些参数有两种主流方式：

• 内置 sys.argv： 适合轻量参数。sys.argv[0] 永远是脚本名称本身，后续的参数依次存放在下标 1, 2, ... 的字符串列表中。
• 标准库 argparse： 适合中大型工具。支持参数命名（如 --env）、设置类型与默认值，并能自动生成 -h/--help 终端帮助文档，是规范开发的首选方案。

# argparse 快速示例 (worker.py)
import argparse

parser = argparse.ArgumentParser(description="CentOS 运维数据备份工具")
parser.add_argument("--env", default="test", help="运行环境 (prod/test)")
parser.add_argument("--limit", type=int, default=10, help="处理记录数")
args = parser.parse_args()

print(f"当前执行环境: {args.env}, 限制条数: {args.limit}")

2. 标准输出与标准错误的重定向

CentOS 终端为每个运行中的进程分配了三个标准文件描述符：标准输入 0 (stdin)、标准输出 1 (stdout) 和标准错误 2 (stderr)。当脚本产生大量日志或者需要将错误单独留存时，重定向是不可或缺的手段：

# 将正常输出 (stdout) 覆盖重定向到 run.log
[root@centos ~]# python3 worker.py > run.log

# 将正常输出追加到日志末尾，不覆盖原内容
[root@centos ~]# python3 worker.py >> run.log

# 将标准错误流 (stderr) 单独写入 error.log
[root@centos ~]# python3 worker.py 1> run.log 2> error.log

四、生产实战：后台守护运行与定时任务调度

在通过 SSH 远程连接 CentOS 服务器时，如果在前台直接运行耗时较长的 Python 任务，一旦网络抖动或本地终端关闭，当前会话的 Bash 会向所有子进程发送 SIGHUP（挂断）信号，导致正在运行的 Python 脚本被强行终止。针对这类场景，必须采取后台持久化执行方案。

1. 使用 nohup 与 & 组合实现免断开常驻

nohup 命令的作用是捕获并忽略 SIGHUP 信号，使进程在终端退出后仍能继续运行；末尾的 & 则将进程放入后台执行，立即释放终端交互提示符：

[root@centos ~]# nohup python3 -u task_consumer.py > consumer.log 2>&1 &
[1] 18274  （示例输出：[作业号] 进程PID）

这行命令包含了多个生产级关键参数，各个部分的具体含义如下：

• python3 -u：极其关键的参数。默认情况下，Python 在向管道或文件重定向输出时会启用缓冲区，这会导致 print 打印的日志堆积在内存中迟迟不写入磁盘，给人“脚本卡死”的假象。-u 强制对标准 I/O 采用无缓冲模式，确保日志即时落盘。
• > consumer.log：将标准输出（fd 1）写入指定的日志文件。
• 2>&1：将标准错误（fd 2）重定向并合并到标准输出（fd 1）中，从而将业务输出和 Traceback 异常报错完整收拢到同一个日志文件中。
• &：通知 Shell 将此任务置于后台运行。

2. 查看与终止后台运行的 Python 进程

要确认后台 Python 脚本是否在稳定运行，可以使用 ps 搭配 grep 查看进程状态：

[root@centos ~]# ps -ef | grep python3 | grep task_consumer.py
root     18274  1120  0 10:15 ?        00:00:02 python3 -u task_consumer.py

# 如需实时滚动查看脚本日志输出
[root@centos ~]# tail -f consumer.log

# 如需终止该后台脚本，向对应的 PID 发送终止信号
[root@centos ~]# kill 18274
# 若进程无响应，可使用强制终止信号：kill -9 18274

3. Crontab 定时调度中的“绝对路径铁律”

很多开发者在终端命令行中手动执行 Python 脚本一切正常，但配置到 CentOS 的 crontab 定时任务后却毫无反应。造成这一现象的根本原因是：Crontab 守护进程运行在极其精简的独立环境变量中，其 $PATH 默认仅包含 /usr/bin:/bin，无法识别用户自定义的环境变量或工作目录。

在配置定时任务（crontab -e）时，务必遵循全绝对路径原则：

# 错误写法（依赖当前路径和用户环境，极易失败）：
* * * * * python3 task.py

# 生产正确写法（解释器全路径 + 脚本全路径 + 日志全路径）：
* * * * * /usr/bin/python3 /data/apps/task.py >> /data/apps/logs/cron.log 2>&1

五、CentOS 执行 Python 脚本高频报错与排查清单

在 CentOS 命令行中运行 Python 脚本时，容易遇到以下几类由操作系统权限、文件编码或环境隔离引发的经典报错：

1. -bash: ./script.py: Permission denied

表现： 使用 ./script.py 执行时终端提示权限不足拒绝访问。
原因： Linux 针对该脚本文件未开启执行权限（x 位）。
解决： 执行 chmod +x script.py 赋予可执行权限；或者改用直接显式调用 python3 script.py。

2. /usr/bin/env: 'python3 ': No such file or directory

表现： 脚本明明存在且已经配置了 Shebang，但执行时报解释器找不到，且报错信息中包含怪异的 或反斜杠。
原因： 该脚本此前在 Windows 系统中编写或通过 Git 拉取时使用了 Windows 的 CRLF（ ）换行符。Linux 内核读取 Shebang 时，将末尾不可见的 当作了解释器文件名的一部分，导致系统去寻找名为 python3 的文件。
解决： 在 CentOS 终端中运行 sed -i 's/ $//' script.py，或者使用 dos2unix script.py 将换行符转为 Unix 规范的 LF。

3. ModuleNotFoundError: No module named 'xxx'

表现： 脚本在 IDE 中运行正常，但在 CentOS 命令行中执行时提示找不到第三方库。
原因： CentOS 上的第三方库安装到了其他 Python 解释器路径下，或者脚本依赖了尚未激活的虚拟环境。
解决： 检查当前安装库的 pip 对应关系：python3 -m pip list；如果项目使用了独立虚拟环境，建议在命令行中直接调用该虚拟环境内部的 Python 解释器绝对路径执行脚本，例如：/data/venv/bin/python3 /data/app/script.py，这种方式不需要手动执行 source activate，更加稳定可靠。

总结

CentOS 命令行执行 Python 脚本的路径非常清晰：在临时排查与开发阶段，首选 python3 script.py，简单直接且无需关心文件权限；在编写常态化系统运维工具时，使用 #!/usr/bin/env python3 搭配 chmod +x，使脚本具备原生命令般的调用体验；面对生产长时间任务与定时调度，牢记 nohup ... -u ... 2>&1 & 与绝对路径两大准则，即可确保 Python 脚本在 CentOS 命令行环境下高效、稳定、可监控地持久运行。