Apache 的 mod_python 模块诞生于 Web 应用早期，它的目标非常直接：让 Apache 这个成熟的 Web 服务器不再借助外部 CGI 进程，而是在自身工作进程里内嵌一个 Python 解释器，从而以最低延迟执行 Python 代码。与每次请求都启动新 Python 进程的传统 CGI 相比，mod_python 复用解释器与模块导入状态，显著降低了响应耗时。它提供了一整套 handler 接口，开发者可以编写 Python 函数来处理请求、生成内容、做认证或日志。尽管如今更流行用 mod_wsgi 或反向代理接应用服务器，但在不少老系统里，mod_python 仍是必须面对的现实。
mod_python 的安装与基础配置
在 Debian 或 Ubuntu 一类的系统上，最早可以通过包管理器直接安装 libapache2-mod-python，随后用 a2enmod 命令启用。在 Apache 的配置文件里，最关键的是用 LoadModule 指令把模块挂到服务器上，再通过 AddHandler 把某种后缀或路径交给 mod_python 处理。例如把 .py 结尾的请求转给 python-script 处理器，这样 Apache 收到对应请求时就会调用内嵌解释器执行文件里的逻辑。
下面是一段典型的 Apache 配置片段，注意其中 <Directory> 指令限定了生效范围，而 PythonHandler 指定了实际的处理函数。这种配置方式把 URL 路径、文件系统路径和 Python 函数名绑定在一起，虽然直观，却也让部署和代码位置强相关。
LoadModule python_module modules/mod_python.so
<Directory /var/www/mypy>
AddHandler mod_python .py
PythonHandler myapp
PythonDebug On
</Directory>
上面的 myapp 对应一个 Python 模块，其中需要定义名为 handler 的函数。如果该函数返回 apache.OK，Apache 就认为请求已被妥善处理。这种紧耦合的配置在小型项目里上手很快，但一旦 Python 版本或 Apache 版本变动，往往要重新编译模块，运维复杂度随时间累积。
请求处理流程与 handler 编写
mod_python 的核心抽象是 handler。当请求进入 Apache 并处理到对应阶段时，模块会调入指定 Python 模块，调用其中约定名称的函数，并传入一个 requestobject 对象。这个对象封装了请求头、响应头、URI 和客户端信息，开发者通过它读写内容。最常见的便是发布内容 handler，它在内容生成阶段被调用。
下面示例展示了一个最简单的 handler，它忽略请求细节，直接返回一段文本。注意函数第一个参数习惯叫 req，通过 req.content_type 设置 MIME，再用 req.write 输出响应体。返回 apache.OK 告知 Apache 流程结束。
from mod_python import apache
def handler(req):
req.content_type = 'text/plain; charset=utf-8'
req.write('Hello from mod_pythonn')
return apache.OK
除了基础 handler，mod_python 还支持 PythonAuthenHandler、PythonFixupHandler 等钩子，分别介入认证、请求修正等阶段。这种阶段化设计让开发者能在不碰 Apache C 代码的前提下扩展服务器行为。不过所有逻辑都跑在 Apache 进程内，一个 Python 代码死循环或内存泄漏会拖垮整个 Worker，隔离性远不如独立应用进程。
与 WSGI 方案的对比及迁移建议
mod_python 把应用嵌进 Web 服务器，带来了性能优势，也制造了绑定陷阱。Python 社区后来推出 WSGI 标准，用一套简单的可调用协议隔开服务器与应用。mod_wsgi 便是遵循该标准的 Apache 模块，它既能嵌入式运行，也能守护进程模式把应用放到独立进程，重启应用不影响 Apache。
从代码角度看，mod_python 的 handler 依赖 req 对象与 apache 模块，而 WSGI 应用只接收一个 environ 字典和 start_response 回调，不关心背后是 Apache 还是其他服务器。这种解耦让同一份代码可跑在 Gunicorn、uWSGI 等环境。下表列出两者主要差异：
| 维度 | mod_python | mod_wsgi/WSGI |
|---|---|---|
| 耦合度 | 高，绑定 Apache 与 Python 版本 | 低，标准接口隔离 |
| 进程隔离 | 弱，代码在 Apache 内 | 可强，守护进程独立 |
| 部署灵活度 | 差，重编译常见 | 好，多服务器通用 |
对于仍运行 mod_python 的遗留系统，建议先梳理 handler 逻辑，把业务代码抽成纯函数，再外层包一层 WSGI 入口。这样迁移时不需要重写算法，只需调整服务器配置。新项目则不应再选 mod_python，它的开发早已停滞，安全更新缺失，继续使用只会放大技术债务。
mod_pythonApachePython_WSGI修改时间：2026-08-17 20:16:32