在Flask应用里处理表单，不少开发者都曾遇到过这样一个典型问题：用户提交任务后，页面内容看似没有变化，如果习惯性地按下F5刷新，浏览器往往会弹出一个令人困扰的提示——"确认重新提交表单"。一旦用户确认，同样的数据就会再次发送到服务器，导致数据库里插入两条完全相同的待办事项。
这真的是Flask的Bug吗？其实并非如此。这恰恰是HTTP协议与浏览器标准行为共同作用下的自然结果。当你的视图函数在处理完POST请求后，直接使用render_template返回一个HTML页面时，浏览器地址栏里的URL仍然是接收POST的那个地址（比如/app/today）。此时，整个页面的状态，包括表单中刚刚填写的所有内容，都被浏览器视为“上一次POST请求的结果”。刷新操作，在浏览器看来，就是“重新发送上一次的请求”，于是便触发了重复提交。
那么，如何优雅地解决这个问题，让表单在提交后“重置”，同时彻底杜绝刷新带来的副作用呢？答案就是严格遵循一个经典的Web开发模式：POST-Redirect-GET，简称PRG。
PRG模式：一剂标本兼治的良方
PRG模式的核心思想非常清晰：永远不要让POST请求的响应直接返回一个HTML页面。 它的流程可以拆解为三步：
- 接收并处理POST：用户提交表单，服务器接收数据，执行业务逻辑（比如将任务存入数据库）。
- 服务端发起重定向：处理完毕后，服务器不返回HTML，而是返回一个
302 Found（或303 See Other）状态码，并告诉浏览器“请去访问另一个URL”。 - 浏览器自动GET新页面：浏览器接收到重定向指令，自动向新的URL发起一个GET请求。服务器处理这个GET请求，并返回全新的、表单为空的页面。
这样一来，用户最后看到的页面，其地址栏URL是通过GET请求加载的。此时再刷新页面，浏览器只是重新发起一次无害的GET请求，彻底绕开了重复提交的陷阱。表单的“清空”也就自然完成了，因为每次GET请求渲染的都是一个全新的表单实例。
代码实现：关键在于重定向
理论说清楚了，看看具体在Flask路由里该怎么改。下面是一个修正后的/app/today路由示例，关键改动已经高亮：
from flask import render_template, redirect, url_for, request, flash
from datetime import datetime
@app.route('/app/today', methods=['POST', 'GET'])
@login_required
def today():
today = datetime.today().strftime('%a %b %d')
projects = [(p.id, p.title) for p in Project.query.filter_by(user_id=current_user.id).all()]
new_task_form = AddTask()
new_task_form.project.choices = projects
# 处理 POST 提交
if request.method == 'POST' and new_task_form.validate_on_submit():
try:
project_from_form = Project.query.get(new_task_form.project.data)
new_task = Task(
title=new_task_form.title.data,
description=new_task_form.description.data,
project=project_from_form,
due_date_time=new_task_form.due_date_time.data,
priority_level=int(new_task_form.priority.data),
user_id=current_user.id
)
db.session.add(new_task)
db.session.commit()
flash('Task added successfully!', 'success')
except Exception as e:
db.session.rollback()
flash('Failed to add task. Please try again.', 'error')
logger.error(f"Task creation error: {e}")
# ✅ 核心改动：无论成功失败，都重定向回当前页面（GET版本）
return redirect(url_for('today'))
# GET 请求：始终返回全新渲染的页面（表单自然为空）
pending_tasks = Task.query.filter(
Task.user_id == current_user.id,
Task.completed_status == 0
).all()
return render_template('today.html',
day_and_date=today,
new_task_form=new_task_form,
user_projects=projects,
pending_tasks_length=len(pending_tasks),
pending_tasks=pending_tasks
)
看明白了吗？无论表单验证通过并成功入库，还是处理过程中发生异常，代码的最后一步都是return redirect(url_for('today'))。这行命令让服务器中断了直接渲染模板的流程，转而向用户的浏览器发送一个重定向指令。浏览器随后对/app/today发起一次全新的GET请求，从而触发了函数底部的渲染逻辑，呈现出一个状态全新的页面。
实践中的注意事项与增强技巧
采用PRG模式后，还有一些细节需要留意，以确保体验的完善：
- 清理冗余操作：有些教程可能会建议在提交后手动清空表单对象的各个字段。在PRG模式下，这完全是画蛇添足。因为重定向后的GET请求会创建一个全新的表单实例，旧的请求数据（
request.form）生命周期已经结束，自然不存在残留问题。 - 妥善处理错误反馈：PRG模式引入了一个小挑战：如果表单验证失败，我们重定向后，错误信息不就丢了吗？解决方案是利用Flask的
flash()消息机制。在验证失败或处理异常时，将错误信息通过flash()存入session，然后在模板中使用get_flashed_messages()来获取并展示这些消息。这样既能重定向，又能让用户看到哪里出错了。 - 理解前端增强的定位：有时你会看到“无刷新表单提交”的讨论，这通常指通过JavaScript的AJAX技术提交数据，并在前端动态更新页面。这能提供更流畅的体验，但代价是复杂度显著增加，需要额外编写JavaScript并可能设计专门的JSON API端点。对于大多数场景，PRG模式因其简单、可靠、对SEO友好且符合RESTful原则，依然是首选方案。
- 安全机制依旧有效：不用担心重定向会破坏Flask-WTF提供的CSRF（跨站请求伪造）保护。只要你的模板中正确包含了
{{ form.hidden_tag() }}，CSRF令牌的验证在重定向前后都会正常工作，安全性不受影响。
说到底，在Flask中“清空表单”这个需求，其本质不在于在前端抹掉几个输入框里的文字，而在于通过服务端的重定向，巧妙地终结上一次表单请求的生命周期。坚持PRG模式，你收获的不仅仅是一个不再重复提交的表单，更是一个更健壮、更易于维护、行为更符合用户预期的Web应用。这可以说是每一位Flask开发者都应该熟练掌握并付诸实践的核心开发准则之一。
