最直接、可控性最强的方式是用 subprocess.Popen 启动多个独立进程，不阻塞、显式传 sys.executable、手动传递环境变量、捕获 stderr 并统一 wait。
怎么用 subprocess 同时跑多个 .py 文件
最直接、可控性最强的方式是用 subprocess.Popen 启动多个独立进程，而不是 subprocess.run（它会阻塞）。关键在于别等一个结束才启下一个。
- 用
shell=False更安全，尤其路径含空格或特殊字符时；Windows 下建议显式传sys.executable而非硬写"python" - 如果多个脚本都依赖同一份环境变量（比如
DJANGO_SETTINGS_MODULE），得在env=...里手动传进去，父进程的os.environ不会自动继承 - 别忘了捕获
stderr，否则报错时控制台可能没输出，你以为它“静默成功”了
import subprocess import sys <p>procs = [ subprocess.Popen([sys.executable, "a.py"], stderr=subprocess.STDOUT), subprocess.Popen([sys.executable, "b.py"], stderr=subprocess.STDOUT), ] for p in procs: p.wait() # 这里才统一等全部结束</p>
threading 跑多个 .py 文件？别试
不能直接用 threading.Thread 去执行整个文件——线程跑的是函数，不是进程。有人误把 exec(open(...).read()) 塞进线程，结果变量污染、input() 冲突、异常难追踪。
- CPython 的 GIL 让纯 CPU 任务在线程里根本不会并行，反而增加调度开销
-
exec执行文件会共享全局命名空间，两个脚本同时改sys.path或重载模块，行为不可预测 - 一旦某个脚本调
os._exit()或崩溃，整个主线程就挂了，连清理逻辑都没机会跑
用 concurrent.futures.ProcessPoolExecutor 的边界在哪
它适合运行「可序列化、无状态」的函数，不是为启动独立 Python 进程设计的。强行用来跑多个 .py 文件，要绕很多弯：
- 得把每个文件封装成函数，再通过
importlib动态导入，路径处理麻烦，且无法传递命令行参数 - 子进程默认不继承父进程的
sys.argv，想模拟python script.py --port 8001得自己拼字符串再喂给subprocess - Windows 下 spawn 方式启动新进程，模块必须在
if __name__ == "__main__":下保护，否则递归创建进程
真正该考虑的：是不是非得“同时运行多个文件”
多数时候，所谓“同时运行”，其实是需要协调多个服务（API + 定时任务 + 日志监听），这时 docker-compose 或 supervisord 比手写 Python 启动逻辑更稳。
- Python 文件之间如果有共享状态（比如共用一个 SQLite 文件），并发写入大概率损坏数据，得加文件锁或换数据库
- 日志混在一起看不清谁输出了什么，建议每个进程用不同
logging.FileHandler，或用structlog打上进程 ID 标签 - Ctrl+C 终止时，子进程可能变成僵尸，要用
signal.signal(signal.SIGINT, ...)拦住并主动.terminate()所有Popen实例
真正麻烦的从来不是“怎么启动”，而是“怎么可靠地收尾、排错、隔离资源”。没做这三步，跑得越快，查得越懵。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
