WSGI中调用subprocess是否违背初衷？是否与CGI等效？

首先直接给出核心结论：这种方式确实违背了使用WSGI替代CGI的初衷，而且本质上和CGI一样会为每个请求生成新进程，下面详细拆解原因并给出优化方案：

1. 为什么违背WSGI的初衷？ #

WSGI诞生的核心目标之一就是解决CGI的低效痛点——CGI会为每个请求启动全新进程执行脚本，处理完毕就销毁，完全没有进程复用的可能。而WSGI的优势恰恰在于，它支持Python应用进程常驻内存，搭配uWSGI、Gunicorn这类服务器的进程池机制，可以复用进程处理大量请求，既避免了进程启动/销毁的开销，还能共享内存中的资源（比如数据库连接、缓存数据）。

但你当前的架构里，wsgi.py通过subprocess.check_output调用app.py，相当于每个请求都会启动一个全新的Python解释器进程来执行业务逻辑，处理完就退出。这等于用WSGI做了个“空壳”，内部还是CGI的运行模式，完全浪费了WSGI的核心价值。

2. 是不是和CGI一样每个请求生成新进程？ #

没错，本质完全一致。subprocess.check_output每次调用都会创建一个独立的子进程（这里是运行Python解释器执行app.py），请求处理完成后这个子进程就会终止。和CGI为每个请求fork新进程执行脚本的逻辑没有区别，同样会面临进程启动开销大、无法共享资源的问题。

3. 你的代码里还有几个小问题需要修正 #

• app.py里的json.loads(response)会报错：response是字典类型，不是JSON字符串，应该改成json.dumps(response)序列化后再print输出；
• wsgi.py传递arg1的方式有误：environ是请求信息字典，不能直接用json.loads(environ)（会因参数类型错误报错），正确做法是将environ序列化为JSON字符串后传递，比如：

  arg1 = json.dumps(environ)
  response = subprocess.check_output([sys.executable, script, arg1])
  

  然后在app.py里通过sys.argv[1]获取参数并反序列化。

4. 正确分离业务逻辑的方式 #

如果想把业务逻辑和WSGI入口解耦，完全不需要用子进程，直接将业务逻辑做成可导入的模块即可：

修改后的app.py #

def handle_request(environ):
    # 这里可以编写你的业务逻辑，比如根据environ的请求信息处理
    return {
        'status': '200 OK',
        'header': [('Content-type', 'text/html')],
        'content': "Hello, World!"
    }

修改后的wsgi.py #

from app import handle_request

def application(environ, start_response):
    response = handle_request(environ)
    status = response['status']
    header = response['header']
    content = response['content']
    start_response(status, header)
    return [content.encode('utf-8')]

这样修改后，业务逻辑和WSGI入口实现了分离，同时又能充分利用WSGI的常驻进程优势——handle_request函数会在同一个WSGI worker进程里被多次调用，不用每次启动新进程，完美发挥WSGI的效率优势。

内容的提问来源于stack exchange，提问作者Michael M