Python 为什么Flask忽略缓存控制？

我正在运行一个Flask应用程序，其中包括一个每小时更新内存中json变量的进程，并将该变量包含在其响应模板中。我遇到了以下意外行为：

    r.headers["Cache-Control"] = "no-cache, no-store, must-revalidate, public, max-age=0'"
    r.headers["Pragma"] = "no-cache"
    r.headers["Expires"] = "0"

对网页的初始访问显示仅在服务器启动时实例化的数据。忽略数据的最新每小时更新

快速重装5-10次将使浏览器更新并显示最新的json数据（仅重装一次或两次无效）

在浏览器显示最新数据后，再次单击“重新加载”将恢复到初始更新，就像它已被缓存一样

服务器代码：

data = None 
def updatejson():

    global data
    data = redditapi()

updatejson()

scheduler = BackgroundScheduler()
scheduler.add_job(func=updatejson, trigger="interval", minutes=60)
scheduler.start()
atexit.register(lambda: scheduler.shutdown())

app = Flask(__name__)
app.config['SEND_FILE_MAX_AGE_DEFAULT'] = 0

@app.route("/")
def hello():
    global data
    return render_template('index.html', data=data)

@app.after_request
def add_header(r):
    r.headers["Cache-Control"]  = "no-store"
    return r

if __name__ == "__main__":
    app.run(host='0.0.0.0')

我还尝试设置以下标题，但行为相同：

    r.headers["Cache-Control"] = "no-cache, no-store, must-revalidate, public, max-age=0'"
    r.headers["Pragma"] = "no-cache"
    r.headers["Expires"] = "0"

index.html模板还具有以下元数据：

<meta http-equiv="Cache-Control" content="no-cache, no-store, must-revalidate" />
<meta http-equiv="Pragma" content="no-cache" />
<meta http-equiv="Expires" content="0" />

编辑： curl-I报告如下：

HTTP/1.1 301 Moved Permanently
Server: nginx/1.14.0 (Ubuntu)
Date: Thu, 26 Dec 2019 22:24:29 GMT
Content-Type: text/html
Content-Length: 194
Connection: keep-alive
Location: https://pcsalesapp.com/

已尝试将expires-1和缓存控制添加到Nginx，但行为仍然存在：

location / {
    expires -1;
    add_header Cache-Control "no-store";
    include uwsgi_params;
    uwsgi_pass unix:/home/jv/pcsalesapp/pcsalesapp.sock;
}

---

我是否也需要在uwsgi中解决这个问题？

出于好奇，为什么不使用？使用curl或wget是否可以获得预期的结果？可能是你的浏览器，而不是你的应用。如果你有nginx服务器，它也可以缓存对某些页面的请求。您需要查看Flask输出—它是否接收您的所有请求？确实，问题可能出在Nginx或uWSGI上。有关nginx位置的详细信息，请参见上面的编辑。不确定如何进一步排除故障。出于好奇，为什么不使用？使用curl或wget是否能获得预期的结果？可能是你的浏览器，而不是你的应用。如果你有nginx服务器，它也可以缓存对某些页面的请求。您需要查看Flask输出—它是否接收您的所有请求？确实，问题可能出在Nginx或uWSGI上。有关nginx位置的详细信息，请参见上面的编辑。不确定如何进一步排除故障。