为什么Flask应用使用gunicorn运行时自定义线程进度更新功能失效

• 耗时任务未真正放入子线程：你当前继承的ExportingThread没有重写run()方法，所有OCR处理、进度更新逻辑全部写在cert_details路由函数中，路由需要等待全部任务处理完成才会返回。而gunicorn默认使用同步工作模式，单个请求会占用工作进程的一个线程，处理cert_details的期间，前端发来的进度查询请求会被阻塞，直到任务完成后才会被处理，自然看不到实时进度。
• 多进程内存隔离：gunicorn默认会启动多个工作进程（默认数量为CPU核心数*2+1），你用来存储进度的全局变量exporting_threads和thread_id只存在于单个进程的内存空间中。如果进度查询请求被分发到其他工作进程，该进程内没有对应任务的进度数据，只会一直返回0。
• 原有开发服务器的特殊性：Flask自带的开发服务器默认是单进程多线程模式，只会启动一个进程，所有请求共享同一块内存空间，同时可以并发处理多个请求，所以进度查询不会被阻塞，刚好能匹配你的实现逻辑。

1. 修正线程实现，把耗时任务移入子线程 #

重写ExportingThread类，将文件处理逻辑放入run()方法中，cert_details路由启动线程后直接返回，不要等待任务执行完成。同时新增结果查询接口，供前端在进度完成后拉取处理结果：

class ExportingThread(threading.Thread):
    def __init__(self, filenames):
        super().__init__()
        self.progress = 0
        self.filenames = filenames
        self.details = [] # 处理结果存在线程对象中
        self.finished = False

    def run(self):
        # 把原路由中的处理逻辑移到这里
        for file in self.filenames:
            self.details.append(get_certficate_details(UPLOAD_FOLDER_LOCATION + file, file))
            self.progress += 1
        self.finished = True

# 修正后的cert_details路由
@app.route('/cert_details', methods=['POST'])
def get_details():  
    data = request.json
    if 'filenames' not in data:
        return {'error':'filenames not found'}
    filenames = data['filenames']
    # 从请求参数取上传阶段生成的线程ID，不要用全局变量存储
    thread_id = data['thread_id']
    exporting_threads[thread_id] = ExportingThread(filenames)
    exporting_threads[thread_id].start()
    # 立刻返回，不等待任务跑完
    return {'status': 'processing', 'thread_id': thread_id}

# 新增结果查询接口，进度100%时调用
@app.route('/result', methods=['POST'])
def get_result():
    data = request.json
    thread_id = data['thread_id']
    if thread_id not in exporting_threads:
        return {'error': 'invalid thread id'}
    thread = exporting_threads[thread_id]
    if not thread.finished:
        return {'status': 'processing'}
    return jsonify(file_details = thread.details)

2. 调整gunicorn配置（临时兼容单进程部署） #

如果你的业务规模小，不需要多进程扩容，可以调整gunicorn启动参数，指定单进程多线程模式，避免内存隔离问题：
CMD ["gunicorn","--timeout", "120", "--workers", "1", "--threads", "8", "--bind", "0.0.0.0:5000", "app:app"]
注意把timeout调大，避免长任务被gunicorn主动杀掉。

3. 多进程部署兼容方案 #

如果需要开启多worker提升并发能力，就不能用进程内全局变量存储进度，需要引入独立的共享存储（如Redis、SQLite）来存储所有任务的进度、状态和处理结果，所有gunicorn工作进程都从共享存储中读写数据，保证进度查询的一致性。

4. 修复全局线程ID的bug #

你当前用全局变量存储thread_id，如果有多个用户同时上传文件，ID会被覆盖，导致进度查询混乱。建议在上传接口生成唯一ID后直接返回给前端，后续所有进度查询、任务启动请求都携带该ID，不要用全局变量存储。

内容的提问来源于stack exchange，提问作者Tiger_Stripes