XAMPP环境下多端口部署Flask应用-php教程-PHP中文网

xampp 不支持原生多端口 flask 部署，因 apache 单进程模型下所有 virtualhost 共享同一 python 解释器，易致应用冲突、状态污染与模块缓存错误；必须为每个端口配置独立 wsgidaemonprocess 并严格匹配 mod_wsgi 路径、python 版本及虚拟环境，且 wsgi.py 仅导出 application、禁止顶层运行代码。

xampp环境下多端口部署flask应用

直接说结论：XAMPP 本身不支持原生多端口 Flask 部署，强行用 Listen 开多个端口 + 多个 VirtualHost 是可行的，但极易因 mod_wsgi 共享 Python 解释器而崩溃——同一进程里不能安全运行多个 Flask 实例。

为什么 XAMPP 的 httpd.conf 里加多个 Listen 不等于多服务

XAMPP 的 Apache 默认是单主进程 + 多子进程模型，所有 VirtualHost 共享同一个 WSGIPythonHome 和全局 Python 环境。哪怕你配置了 *:5000 和 *:6000 两个监听，mod_wsgi 仍会把两个 Flask 应用加载进同一解释器空间，导致：

app 变量名冲突（比如都叫 application）
全局状态污染（如 app.config、Flask-Login 的 session 设置互相覆盖）
Python 模块导入缓存（import myapp1 和 import myapp2 可能被当成同一个模块）

典型现象：ImportError: cannot import name 'application' 或启动后某一个端口返回另一个应用的内容。

mod_wsgi-express module-config 输出的配置必须逐项核对

运行 mod_wsgi-express module-config 后，它输出的三行不是“复制粘贴就能用”的模板，而是强绑定当前 Python 版本、架构和 mod_wsgi 编译参数的硬编码路径：

LoadFile "C:/Python310/python310.dll" —— 必须和你的 Python 安装路径完全一致，不能写成 python3.dll 或漏掉版本号
LoadModule wsgi_module "C:/Python310/lib/site-packages/mod_wsgi/server/mod_wsgi.cp310-win_amd64.pyd" —— 文件名中的 cp310 和 win_amd64 必须匹配你安装的 wheel 包，否则 Apache 启动失败且日志只报 Cannot load mod_wsgi.so
WSGIPythonHome "C:/Python310" —— 若你用了虚拟环境，这里必须指向虚拟环境根目录（如 C:/venv/myflask），而不是系统 Python

漏掉任一匹配，Apache 会静默失败或在访问时返回 500 错误，error.log 里可能只有一行 mod_wsgi (pid 1234): Target WSGI script 'd:/test/wsgi.py' cannot be loaded。

每个端口必须配独立的 WSGIDaemonProcess

想让两个 Flask 应用真正隔离，不能只靠 VirtualHost，必须为每个端口声明独立的守护进程：

XAMPP 8.0.30

XAMPP 8.0.30 是一款免费、开源的跨平台 Web 服务器集成包，专为快速搭建本地 PHP 开发环境而设计。该版本核心组件包括：Apache 2.4.56、MySQL 8.0.33、PHP 8.0.30、phpMyAdmin 5.2.1 等。它支持 Windows、Linux 和 macOS 系统，可让开发者在个人电脑上轻松模拟服务器环境，无需复杂配置即可运行 WordPress、Thin

下载

WSGIDaemonProcess app1 python-path="d:/app1" python-home="C:/venv/app1"
WSGIProcessGroup app1
WSGIScriptAlias / d:/app1/wsgi.py
<p>WSGIDaemonProcess app2 python-path="d:/app2" python-path="d:/app2" python-home="C:/venv/app2"
WSGIProcessGroup app2
WSGIScriptAlias / d:/app2/wsgi.py</p>

关键点：

WSGIDaemonProcess 名字（app1/app2）必须唯一，且与后续 WSGIProcessGroup 严格一致
python-path 要包含应用所在目录（让 import app 找得到），不能只写 python-home
Windows 下 WSGIDaemonProcess 默认使用 threads=1，高并发场景需显式加 threads=5，否则请求排队

漏掉 WSGIProcessGroup，所有请求仍会落到默认进程组，两个应用还是共享内存。

wsgi.py 文件必须导出 application，且不能有 top-level 运行代码

这是最常被忽略的细节。以下写法是错的：

from flask import Flask
app = Flask(__name__)
<p>@app.route('/')
def hello():
return 'hello'</p><p>if <strong>name</strong> == '<strong>main</strong>':
app.run()  # ← 这行会导致 Apache 启动时就执行 run()，阻塞进程</p>

正确写法只有两行：

from myapp import app as application
# 不要任何 if __name__ == ...，不要 print，不要 app.run()

原因：mod_wsgi 加载 wsgi.py 时会执行全部顶层代码。一旦触发 app.run()，Apache 主进程就被卡死，后续请求全超时；而 print 语句会写入 Apache 的 error.log，但不会报错，只会让日志变得难以排查。

复杂点在于：XAMPP 的 Apache 是 Windows 服务，重启不彻底时旧进程残留，mod_wsgi 的 Python 子进程不会自动回收。每次改完配置，务必用任务管理器杀掉所有 httpd.exe，再手动启动服务，否则看到的永远是上一次的缓存行为。