说起来，搞Python的兄弟姐妹们，谁还没遇到过这种场景？你写了个特牛的Python脚本，能处理数据、能自动化流程，可偏偏到了某个环节，得依赖一个老掉牙的或者别人写好的Windows下的.exe程序。那玩意儿功能是强，但没接口给你直接调啊！你总不能手动去点吧？那时候，脑袋里蹦出的第一个问题，多半就是：python怎么调用exe程序？这事儿，说难不难，说简单也不简单，里头门道还真不少，踩坑也是家常便饭。

刚开始接触这块儿的时候，我记得自己真是两眼一抹黑。上网搜，出来的都是些零零碎碎的代码片段，或者讲得太理论。真拿到自己手头那个具体的exe，带着一堆命令行参数，有时还要等它跑完才能进行下一步，甚至还得知道它执行过程中有没有报错……那时候真是抓耳挠腮。

最早接触到的，多半是os.system()这个老古董。说实话，它用起来是挺直接粗暴的。

“`python
import os

调用一个简单的exe，比如计算器

os.system(“calc.exe”)

调用带参数的exe，注意参数间的空格

假设有一个叫 mytool.exe 的程序，可以接受一个文件路径作为参数

os.system(f”mytool.exe C:\path\to\my\file.txt”)

“`

你看，就这么一行代码，calc.exe就蹦出来了。简单吧？是挺简单的。但问题来了：这玩意儿就是直接把你的命令扔给操作系统的shell去执行，就像你在命令行里敲命令一样。它最大的缺点是啥？它不会等你执行的那个exe跑完，它就会直接返回！而且你想拿到那个exe执行过程中在控制台里打印出来的信息（就是标准输出，或者报错信息——标准错误），门都没有！更别提你想知道它到底有没有成功运行（返回值）了。用os.system()调个计算器玩玩还行，真要做自动化流程，等着它跑完再接着干活儿，或者根据它输出的内容做判断，这根本玩不转啊！完全是“把球踢出去就不管了”的状态。而且，它直接暴露给shell，如果你的命令字符串里有啥特殊字符，搞不好还得防注入，虽然在调用本地exe时不是主要风险，但这种“不安全”的感觉总是有的。

所以，很快我就抛弃了os.system()，转向了更现代、更强大的武器——subprocess模块。这玩意儿才是Python里处理外部进程的“亲儿子”，功能强大到让你爱不释手（当然，一开始学的时候可能会觉得选项有点多，有点晕）。

subprocess模块里有好几个函数，但对于调用外部exe并希望能灵活控制、捕获输出的场景，最常用的、我个人觉得最方便的，是subprocess.run()。

“`python
import subprocess
import sys

假设我们要调用一个简单的命令行程序，比如Windows下的 dir 命令（它其实是cmd的内置命令，但原理类似）

如果是真正的exe，直接写exe的路径或名字就好

try:
# 使用 run 函数调用
# capture_output=True 会捕获标准输出和标准错误
# text=True 会把输出和错误解码成文本（默认是字节串）
# check=True 会在返回码非零时抛出CalledProcessError异常，方便错误处理
result = subprocess.run([“dir”, “/b”], capture_output=True, text=True, check=True)

print("命令执行成功！")
print("标准输出:")
print(result.stdout)
print("标准错误 (如果为空则无错误):")
print(result.stderr)
print(f"返回码: {result.returncode}") # 返回码通常0表示成功

except subprocess.CalledProcessError as e:
print(f”命令执行失败！返回码: {e.returncode}”)
print(“标准输出:”)
print(e.stdout)
print(“标准错误:”)
print(e.stderr)
except FileNotFoundError:
print(“错误：要调用的exe或命令不存在！”)
except Exception as e:
print(f”发生未知错误: {e}”)

“`

看看这段代码，是不是感觉瞬间高大上了许多？subprocess.run()默认是会等待你调用的程序执行完毕的。capture_output=True这个参数，哎呀，可真是个救星！它能帮你把目标exe往标准输出（stdout）和标准错误（stderr）里吐的所有内容都抓回来，存在result.stdout和result.stderr里。想看exe执行过程中打印了啥日志？想知道它有没有报了个错？全在这里了！再配合text=True，抓回来的就直接是字符串了，不用再自己解码，省事儿！

还有个check=True，强烈推荐加上。它干嘛的？就是让你调用的程序一旦执行失败（通常表现为返回码不是0），它就直接甩个CalledProcessError异常出来。异常处理多方便啊！不用自己去判断那个神秘的returncode是不是0了。当然，你也可以不加check=True，然后自己去检查result.returncode是不是0，看你习惯哪个。

参数传递这里也有点讲究。看到subprocess.run()里面那个列表了吗？["dir", "/b"]。这里把命令和它的参数分开放到列表里了。这是推荐的做法，特别是当你的参数里可能包含空格或者其他特殊字符的时候。这样能避免很多shell解析命令字符串带来的麻烦。想象一下你要调用的exe需要一个包含空格的文件路径作为参数，比如"C:\\Program Files\\My App\\config.ini"，如果直接拼接字符串，处理那些引号和反斜杠能让你抓狂。用列表形式，subprocess会帮你处理好。

那如果你的exe需要输入呢？比如需要你输入个’Y’或者’yes’才能继续？subprocess.run()也有办法，可以用input参数：

“`python

假设有一个exe，运行后会问你一个问题，需要你输入个东西

比如一个简单的模拟程序，输入 ‘hello’，它输出 ‘you said hello’

import subprocess # 已经在上面导入了

try:
process = subprocess.run(
[“your_interactive_exe.exe”],
input=”hello\n”, # 要发送给exe的标准输入，注意要加上换行符
capture_output=True,
text=True,
check=True
)
print(“互动完成。输出：”)
print(process.stdout)
except Exception as e:
print(f”发生错误: {e}”)
if hasattr(e, ‘stdout’):
print(f”错误时输出: {e.stdout}”)

``
这里的input参数就是把你要输入的内容通过标准输入传递给那个exe。别忘了加个换行符\n`，模拟你在键盘上敲完回车。

不过，subprocess.run()虽然好用，但它是同步的，也就是说，你的Python脚本会一直在这里等着，直到那个exe彻底跑完。如果那个exe是个图形界面程序，或者是个需要跑很久的任务，你的Python脚本就会“卡”在那里，界面可能会无响应。这时候，你就需要请出subprocess.Popen()了。

subprocess.Popen()就不一样了，它是异步的。它启动目标exe后，立刻就返回一个Popen对象，你的Python脚本可以接着往下执行自己的事儿，不用干等着。这就像你派了个手下去干活儿，手下去了，你还能接着处理别的事情。

“`python

import subprocess # 导入过了

print(“准备调用一个exe，但不想等它…”)

调用一个记事本，它会弹出来，但Python脚本不会停在这里

process = subprocess.Popen([“notepad.exe”])

print(“记事本已经启动了，我可以继续做别的事情了…”)

这里可以写一些不依赖于记事本执行结果的代码

import time
time.sleep(5)
print(“我忙活了一会儿，现在想看看记事本是不是还在跑…”)

你可以通过 Popen 对象的 poll() 方法检查进程是否还在运行

if process.poll() is None:
print(“记事本还在运行。”)
# 如果你想等待它结束，可以使用 wait() 方法
# print(“现在我决定等等它…”)
# return_code = process.wait()
# print(f”记事本关闭了，返回码是: {return_code}”)
else:
print(f”记事本可能已经关闭了，返回码是: {process.returncode}”)

你甚至可以通过 communicate() 方法与 Popen 进程交互，并等待其结束，这类似于 run 的功能，但更灵活

stdout, stderr = process.communicate(input=”要发送给进程的输入\n”)

print(f”标准输出: {stdout.decode()}”) # communicate 默认返回字节串，需要解码

“`

Popen对象能干的事情更多，你可以通过它的属性拿到进程ID（pid），可以往它的标准输入写数据（通过process.stdin.write()），从它的标准输出（process.stdout.read()）和标准错误（process.stderr.read()）读数据，这需要你手动去处理管道（pipe），比run的capture_output=True要麻烦一点，但更灵活。你还可以调用process.terminate()或者process.kill()来强行中止那个exe。

所以你看，subprocess.run()适合那种“调用exe，等着它跑完，然后拿到结果或看它有没有错”的场景，简单直接。而subprocess.Popen()则更适合需要异步执行、需要实时与外部程序交互、或者需要更精细控制进程生命周期的复杂场景。大多数情况下，subprocess.run()已经足够应付日常的python怎么调用exe程序的需求了。

实际操作中，还有几个坑不得不提。
一个是路径问题。 你要调用的那个exe，它的路径是啥？如果在系统的PATH环境变量里，直接写名字就行，比如notepad.exe。如果不在，你就得给全路径，比如"C:\\Program Files\\MyApp\\tool.exe"。注意Windows路径里的反斜杠\，在Python字符串里它是个转义符，所以要么用双反斜杠\\，要么在字符串前加个r变成原始字符串r"C:\Program Files\MyApp\tool.exe"，或者用正斜杠/，在Windows上通常也能识别"C:/Program Files/MyApp/tool.exe"。写脚本的时候，强烈建议用绝对路径，省得在不同目录下运行脚本时找不到exe。或者，你也可以用subprocess.run()或Popen()的cwd参数，指定一个工作目录，让exe在这个目录下运行。

“`python

指定工作目录

import os
exe_path = r”D:\SomeFolder\MyTool\tool.exe” # 假设exe在这里
work_dir = r”D:\SomeOtherFolder\Data” # 想让exe在这个目录里运行，处理这个目录下的文件

try:
subprocess.run([exe_path, “some_param”], cwd=work_dir, check=True)
print(“在指定目录下成功运行exe。”)
except FileNotFoundError:
print(f”找不到exe文件: {exe_path} 或 在工作目录 {work_dir} 下找不到其他必要文件?”)
except Exception as e:
print(f”运行错误: {e}”)
“`

另一个是参数传递。 如果你的exe参数比较复杂，特别是带空格或者需要引号的参数，一定要小心处理。前面说的用列表传递参数是最好的方法，能避免绝大多数问题。比如你要传的参数是--config "C:\My Documents\settings.cfg"，用列表就是["--config", "C:\My Documents\settings.cfg"]。

再来就是权限问题。 有时候你要调用的exe可能需要管理员权限。Python脚本默认运行的用户权限可能不够。这种情况下，直接用subprocess调用可能会失败。解决办法嘛，就得从Windows系统层面想办法了，比如让Python脚本本身以管理员身份运行，或者用一些特定的Windows API（但这超出了纯Python调用的范畴了）。

黑乎乎的命令窗口。 用os.system()或者subprocess默认调用命令行程序时，有时候会弹出一个黑乎乎的控制台窗口，跑完可能又瞬间消失，或者一直占着。如果你想让它在后台静默运行，不显示这个窗口，可以在subprocess.run()或Popen()里加个参数creationflags。对于Windows系统，常用的值是subprocess.CREATE_NO_WINDOW（或者0x08000000这个十六进制值）。

“`python
import subprocess
import sys

隐藏窗口调用记事本（不会弹那个黑框）

注意这个参数是Windows特有的

if sys.platform == “win32”:
try:
subprocess.Popen([“notepad.exe”], creationflags=subprocess.CREATE_NO_WINDOW)
print(“静默启动了记事本。”)
except Exception as e:
print(f”启动失败: {e}”)
else:
print(“非Windows系统，忽略 creationflags 参数。”)

“`
加上这个参数，再调那些命令行工具型的exe时，就不会闪那个烦人的黑框了，感觉整个自动化流程瞬间“隐形”了许多，干净利落。

总而言之，当Python遇上外部exe，别慌。忘记那个简陋的os.system()吧，拥抱强大的subprocess模块！根据你的需求——是需要等它跑完拿结果，还是需要异步执行甚至实时交互——选择subprocess.run()或subprocess.Popen()。处理好路径、参数、权限这些细节，再根据需要决定是否隐藏窗口、是否捕获输出。多实践，多踩坑，慢慢地，你就能熟练地让Python和那些“非Python血统”的exe程序和谐共处，甚至协同作战了。这可真是自动化工作流里的一个必备技能啊！别小看它，有时候解决一个棘手问题，靠的还真就是这招“Python指挥exe”的跨界协作。希望这篇文章能给你点启发，让你在python怎么调用exe程序这条路上少走点弯路。