尽管您可以更改服务器上的超时时间或其他技巧来尝试保持页面“活动”，但请记住，连接的其他部分可能无法控制，可能会使请求超时（例如超时）浏览器的值，或浏览器与服务器之间的任何代理等）。另外，如果任务需要更长的时间才能完成（变得更高级，或者因为更多的人使用它而变得更慢），则可能需要不断提高超时值。
最后，这种问题通常可以通过更改体系结构来解决。
该视图不是在处理视图中提交请求并运行任务，而是在单独的进程中开始任务的运行，然后立即返回响应。此响应可以使用户进入“请稍候，我们正在处理”页面。该页面可以使用多种推送技术之一来确定任务的完成时间（长轮询，Web套接字，服务器发送的事件，每N秒发出AJAX请求或最简单的方法：重新加载页面）每5秒钟）。
无论如何，就像我说的那样，处理请求的视图并不会执行冗长的操作：它只是启动了一个后台进程来完成该任务。您可以自己创建此后台进程（请查看此Flask片段以获取可能的想法），或使用诸如Celery或（RQ）之类的库。
任务完成后，您需要某种方式通知用户。这取决于您在上面选择了哪种通知方法。对于一个简单的“每N秒发送一个ajax请求”，您需要创建一个视图来处理AJAX请求，以检查任务是否完成。一种典型的方法是执行长时间运行的任务，作为最后一步，对数据库进行一些更新。然后，检查状态的请求可以检查数据库的这一部分以进行更新。
使用此方法（而不是尝试将长时间运行的任务放入请求中）有一些好处：
1.）处理长时间运行的Web请求是一件棘手的事情，因为存在多个超时的事实（浏览器和服务器除外）。使用此方法，您的所有Web请求都非常短，并且超时的可能性大大降低。
2.）Flask（以及类似的其他框架）旨在仅支持一定数量的可以响应Web查询的线程。假设它有8个线程：如果其中四个正在处理长请求，则仅剩下四个请求实际处理更典型的请求（例如，用户获取其个人资料页面）。您的Web服务器的一半可能被捆绑在执行不提供Web内容的操作！更糟糕的是，您可能会使所有八个线程都运行很长时间，这意味着您的站点将无法完全响应Web请求，直到其中一个完成。
主要缺点：设置和运行任务队列需要做更多的设置工作，这会使您的整个系统稍微复杂一些。但是，对于长时间运行在Web上的任务，我强烈建议使用此策略。
602392714
清零编程群