Process.Start() 是唯一推荐用于生产环境的方案；Python.Included 不支持 pip 包和 C 扩展，IronPython 仅兼容 Python 2.7 且无现代语法与生态支持。
Process.Start() 是唯一推荐用于生产环境的方案；Python.Included 和 IronPython 都有硬性限制，不解决实际问题，只制造新问题。
为什么不能用 Python.Included 跑真实脚本
Python.Included 把 CPython 二进制和标准库打包进 .NET 项目，听起来很美，但实际运行时连 import numpy 都会直接报 ModuleNotFoundError——它根本不支持任何 pip 安装的包，更别说 cv2、pandas、torch 这类依赖 C 扩展的库。
适用边界极窄：
- 纯内置库逻辑（
json、re、datetime） - 分发给完全没装 Python 的终端用户，且你 100% 控制脚本内容
- 能接受每次启动慢 300ms+（解释器冷启动开销）
- 目标平台只能是 x64 或 ARM64，x86 直接不支持
一旦脚本里出现 import requests 或 import sklearn，就只剩失败。这不是配置问题，是设计限制。
立即学习“Python免费学习笔记（深入）”；
为什么 IronPython 在 2026 年仍不该碰
IronPython 不是“另一个 Python”，它是 Python 2.7 语法在 .NET 上的实现，最新稳定版仍是 2.7.11。所有现代 Python 特性都不可用：
-
f-string→ 语法错误 -
async/await→ 不识别 -
typing.List或任何类型注解 → 解析失败 -
import pandas→ImportError: No module named 'pandas'（根本没 pip 支持）
它甚至不能加载你自己写的含 ctypes 或 cffi 的模块。所谓“.NET 原生集成”只体现在能调用 int、string 这类基础类型，一旦涉及数据结构或第三方生态，立刻断链。
Process.Start() 必须做对的五件事
别被“简单”误导——错一个点，脚本就静默失败或路径崩掉。
- 显式传
FileName为 python.exe 绝对路径，例如C:\Python311\python.exe，别信PATH，尤其在 Windows 服务、IIS 或打包后运行时 -
UseShellExecute = false，否则RedirectStandardOutput失效，stdout/stderr 捕获不到 -
CreateNoWindow = true，避免 GUI 应用弹黑窗（WinForms/WPF 尤其明显） - 参数走
ArgumentList（.NET 5+），不是拼Arguments字符串：防止空格、中文路径、引号导致截断或注入 -
WaitForExit(30000)加超时，永不写无参WaitForExit()；超时后必须Kill()+Dispose()，否则子进程残留
Python 端输出必须用 print(json.dumps(...)) 到 stdout，C# 端用 StandardOutput.ReadToEnd() 读取；别指望函数 return 值——进程间没有返回值概念，只有流。
最容易被忽略的编码和路径陷阱
Windows 控制台默认是 GBK，而 Python 脚本和 C# 默认 UTF-8，不统一就会出 UnicodeDecodeError 或乱码。
- C# 端设
StartInfo.StandardOutputEncoding = Encoding.UTF8 - Python 脚本开头加
# -*- coding: utf-8 -*- -
WorkingDirectory必须设为脚本所在目录，否则import ./utils或相对路径文件读取全失败 - 脚本路径本身不能传进
Arguments，应作为FileName的一部分或单独用ArgumentList[0]传，避免空格解析错位
真正卡住人的从来不是“怎么调”，而是“为什么明明路径对了却 ModuleNotFoundError”、“为什么输出看着像 JSON 但反序列化失败”——这些全是编码、工作目录、流重定向没对齐的后果。
