Process.Start 是最快落地的方案，但需显式指定 Python 解释器全路径、正确处理脚本路径与空格、设置 WorkingDirectory、捕获 StandardError；Python.Included 无需安装 Python 但不支持第三方包和 C 扩展；IronPython 和 PythonTools 不推荐用于生产；传参取结果优先用 JSON 文件或标准流并加异常边界。
用 Process.Start 调用 Python 脚本最直接，但路径和环境必须手动处理
绝大多数场景下，Process.Start 是最快落地的方案——它不依赖额外 NuGet 包，也不强求 Python 安装在系统 PATH。但问题也集中在这里：python.exe 的位置、脚本路径中的空格、工作目录不一致，都会导致“找不到文件”或“模块导入失败”。
实操建议：
- 显式指定 Python 解释器全路径，比如
C:\Users\Alice\AppData\Local\Programs\Python\Python311\python.exe，别依赖python命令； - 脚本路径传给
ProcessStartInfo.FileName，参数（如.py文件路径）放在Arguments里，避免拼接字符串引发空格截断； - 设置
WorkingDirectory为脚本所在目录，否则import相对路径模块会报ModuleNotFoundError； - 务必捕获
StandardError输出，很多报错（如No module named 'numpy'）只出现在 stderr，stdout 可能为空。
用 Python.Included NuGet 包可免安装 Python，但仅限简单脚本
Python.Included 把 CPython 二进制和标准库打包进 .NET 项目，运行时无需用户装 Python。但它不支持 pip 安装的第三方包（如 requests、pandas），且无法加载 C 扩展（numpy、cv2 全部失效）。
适用场景：
立即学习“Python免费学习笔记（深入）”；
- 纯逻辑计算、文本处理、调用内置库（
json、re、datetime）； - 分发给无 Python 环境的终端用户，且你完全控制脚本内容；
- 不追求性能，能接受启动慢 200–500ms（每次初始化解释器）。
注意：Python.Included 不支持 Windows x86，只提供 x64 和 ARM64 构建目标。
用 Microsoft.PythonTools 或 IronPython？基本不推荐
Microsoft.PythonTools 是 VS 插件 SDK 组件，不是运行时库，不能用于生产调用；IronPython 虽然能直接在 .NET 进程内执行 Python 字节码，但它兼容的是 Python 2.7 语法，不支持 async/await、f-string、类型注解，第三方包几乎全不可用。
常见误判：
- 看到 “.NET 集成 Python” 就选 IronPython——结果发现
import pandas报错且无解； - 以为
PythonTools提供了ExecutePythonScript()方法——实际它只暴露调试器协议，没运行能力； - 忽略版本锁定：IronPython 3.x 仍处于实验阶段，NuGet 上稳定版仍是 2.7.11。
传参和取结果：别用命令行拼接，优先走 JSON 文件或标准流
通过 Arguments 传复杂数据（如含空格的路径、嵌套字典）极易出错；用 stdout 解析文本也容易被日志干扰。更稳的方式是：
- 输入：C# 序列化对象为 JSON 到临时文件（
Path.GetTempFileName()），Python 脚本读取该路径； - 输出：Python 脚本把结果写入另一临时 JSON 文件，C# 读取并反序列化；
- 若坚持用标准流，Python 必须确保
print(json.dumps(result))后调用sys.stdout.flush()，否则 C# 的StandardOutput.ReadToEnd()可能卡住（尤其在 Linux 容器中）。
别省略异常边界：Python 进程崩溃、JSON 解析失败、临时文件被杀毒软件拦截——这些都得在 C# 层加 try/catch 和超时控制（Process.WaitForExit(30000)）。
真正麻烦的从来不是“怎么调”，而是“Python 环境谁来管、升级谁负责、错误日志在哪看”。如果脚本逻辑复杂或依赖外部包，与其在 C# 里硬扛，不如把它做成独立 HTTP 服务（Flask/FastAPI），用 HttpClient 调用——环境隔离、日志清晰、升级自由。
