我非常希望您能详细了解具体情况和原因、特定于应用程序的内容等
嗬。好吧，你要求的！
和 Daniel 一样，我个人将 Apache 与 mod_wsgi 一起使用。它仍然很新，在某些环境中部署它可能会很困难，但如果你自己编译所有东西，那很容易。我发现它非常可靠，即使是早期版本。向格雷厄姆·邓普顿（Graham Dumpleton）的支持，让他几乎独自控制了它。
但是对我来说，WSGI 应用程序必须在所有可能的服务器上工作。目前在这个领域有一点漏洞：你有 WSGI 标准告诉你 WSGI 可调用（应用程序）做什么，但是没有标准化的部署；没有一种方法可以告诉 Web 服务器在哪里可以找到应用程序。当您更新应用程序时，也没有标准化的方法让服务器重新加载应用程序。
我采用的方法是：
模块/包中的所有应用程序逻辑，最好在类中
通过子类化主应用程序和覆盖成员来完成所有特定于网站的自定义
所有特定于服务器的部署设置（例如数据库连接工厂、邮件中继设置）作为类 __init__() 参数
一个顶级的“application.py”脚本，它使用当前服务器的正确部署设置初始化应用程序类，然后以可以部署为 CGI 脚本的方式运行应用程序， mod_wsgi WSGIScriptAlias（或Passenger，显然工作方式相同），或者可以从命令行进行交互
一个帮助模块，负责处理上述部署问题，并允许在应用程序依赖的模块发生更改时重新加载应用程序
所以 application.py 最终的样子是这样的：
#!/usr/bin/env python
import os.path
basedir= os.path.dirname(__file__)
import MySQLdb
def dbfactory():
return MySQLdb.connect(db= 'myappdb', unix_socket= '/var/mysql/socket', user= 'u', passwd= 'p')
def appfactory():
import myapplication
return myapplication.Application(basedir, dbfactory, debug= False)
import wsgiwrap
ismain= __name__=='__main__'
libdir= os.path.join(basedir, 'system', 'lib')
application= wsgiwrap.Wrapper(appfactory, libdir, 10, ismain)
wsgiwrap.Wrapper 每 10 秒检查一次 libdir 中的任何应用程序模块是否已更新，如果更新了，那么一些令人讨厌的 sys.modules 魔术会可靠地卸载它们。然后会再次调用 appfactory() 以获取更新后应用程序的新实例。
（也可以使用命令行工具如
./application.py setup
./application.py daemon
运行应用程序 callable 提供的任何设置和后台任务挂钩 — 有点像 distutils 的工作方式。它还像初始化脚本一样响应启动/停止/重启。）
我使用的另一个技巧是将多个服务器（开发/测试/生产）的部署设置放在同一个 application.py 脚本中，并嗅探“socket.gethostname()”来决定要使用哪个服务器特定的设置使用。
在某些时候，我可能会将 wsgiwrap 打包并正确发布（可能使用不同的名称）。同时，如果您有兴趣，可以在http://www.doxdesk.com/file/software/py/v/wsgiwrap-0.5.py 看到 dogfood-development 版本。