压测前必须关闭flask调试模式并禁用重载，使用gunicorn等生产服务器；jmeter需手动添加host头；返回json须用jsonify()确保content-type；高并发需调优线程模型与压测策略。
Flask接口压测前，必须关掉调试模式和重载
本地开发时 debug=True 和 use_reloader=True 是便利，但压测中会直接导致 JMeter 请求失败或响应极慢——Flask 开发服务器不是为并发设计的，调试模式下每个请求都触发文件监控和异常捕获，CPU 占用飙升，吞吐量断崖式下跌。
实操建议：
- 启动服务时明确设为
debug=False，并禁用重载：app.run(debug=False, use_reloader=False) - 生产环境务必用
gunicorn或uWSGI启动，例如：gunicorn -w 4 -b 127.0.0.1:5000 app:app - 检查日志里是否还有
* Debugger is active *或Watching for file changes字样，有就说明没关干净
JMeter 中 HTTP 请求默认不带 Host 头，Flask 可能返回 400
Flask 的 Werkzeug 服务器对 Host 头敏感，尤其当路由含子路径或反向代理转发时。JMeter 新建的 HTTP Request 默认不发 Host，而浏览器会自动补全，这造成本地能通、JMeter 报 400 Bad Request 的典型错觉。
实操建议：
- 在 JMeter 的
HTTP Request下添加HTTP Header Manager - 手动加一行：
Host→127.0.0.1:5000（端口要和 Flask 实际监听一致） - 如果 Flask 部署在 Nginx 后，Host 值应与
server_name匹配，否则可能被 Nginx 拒绝或路由到错误 upstream
Flask 返回 JSON 时 Content-Type 缺失，JMeter 断言容易误判
用 jsonify() 返回数据时，Flask 默认设 Content-Type: application/json；但若直接 return {"msg": "ok"}，响应头是 text/html。JMeter 的 JSON Extractor 或响应断言依赖正确 MIME 类型，类型不对就提取不到字段，断言全红。
实操建议：
- 统一用
jsonify()：写成return jsonify({"code": 0, "data": []}) - 不用
jsonify()时，手动指定：return json.dumps({...}), 200, {"Content-Type": "application/json"} - JMeter 中可在
View Results Tree里点开单个请求，看 Response Headers 是否含Content-Type: application/json，不然后续所有 JSON 相关操作都不可靠
高并发下 Flask 默认线程模型撑不住，JMeter 线程数别盲目调高
Flask 内置服务器默认单线程（threaded=False），即使开了 threaded=True，也只支持几十并发。JMeter 设 200 线程跑下来全是超时或连接拒绝，不是脚本问题，是服务端根本没处理能力。
实操建议：
- 本地快速验证可用：
app.run(threaded=True, processes=2)，但仅限临时，勿用于正式压测 - 真实压测必须上
gunicorn，推荐起步配置：gunicorn -w 4 -k gevent -b 127.0.0.1:5000 --timeout 30 app:app - JMeter 的线程数要阶梯式增加（比如 10→50→100），每档跑稳 2 分钟再加压，观察 Flask 日志里是否有
Connection reset by peer或大量503
压测不是比谁线程数填得多，而是看服务在什么并发下开始丢请求、延迟突增、错误率跳升——这些拐点藏在日志和 JMeter 的 Aggregate Report 里，不在数字本身。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
