FastAPI文件上传接口测试卡顿退出问题排查求助

核心问题分析 #

exit code 137本质是进程被系统强制终止，大概率是内存耗尽（系统OOM Killer触发），但也可能和测试请求构造错误导致接口异常处理有关。结合你怀疑的请求发送方式，从以下方向逐一排查：

一、检查测试代码的文件请求构造是否正确 #

FastAPI接收上传文件要求用files参数构造multipart/form-data格式请求，常见错误会导致接口处理异常：

• 未指定文件MIME类型或文件名
• 用data参数而非files参数传递文件
• 文件对象未以二进制模式打开或读取

正确测试代码示例 #

from fastapi.testclient import TestClient
from your_app_module import app

client = TestClient(app)

def test_save_cota():
    # 以二进制模式打开测试xlsx文件
    with open("test_sample.xlsx", "rb") as f:
        response = client.post(
            "/save_cota",
            # 格式：{"字段名": (文件名, 文件对象, MIME类型)}
            files={"file": ("test_sample.xlsx", f, "application/vnd.openxmlformats-officedocument.spreadsheetml.sheet")}
        )
    assert response.status_code == 200

二、检查接口实现的内存占用情况 #

如果接口处理xlsx时采用内存密集型操作，会直接触发内存耗尽：

• 检查是否用pandas.read_excel()一次性加载整个大文件，未做分块处理
• 检查是否在处理过程中创建大量冗余数据结构

接口内存优化示例 #

from fastapi import FastAPI, File, UploadFile
import pandas as pd

app = FastAPI()

@app.post("/save_cota")
async def save_cota(file: UploadFile = File(...)):
    # 分块读取xlsx，避免一次性加载全量数据到内存
    chunk_size = 1000
    for chunk in pd.read_excel(file.file, chunksize=chunk_size):
        # 逐块处理数据
        process_data_chunk(chunk)
    return {"status": "success"}

三、验证测试环境的资源限制 #

• 检查测试运行环境的内存配额（如Docker容器、CI平台的内存上限），配额过低时处理稍大的xlsx就会触发OOM
• 本地测试时用top/htop监控内存占用，确认是否是内存耗尽导致进程被终止

四、排查接口是否存在阻塞或死循环 #

若请求构造错误，接口可能进入无限等待或死循环：

• 检查接口读取文件时是否正确处理EOF（如循环读取未设置终止条件）
• 开启FastAPI调试日志，查看接口处理到哪一步卡住

总结 #

优先确认测试请求的文件构造是否符合multipart/form-data规范，再排查接口处理xlsx的内存使用逻辑，最后验证环境资源限制。exit code 137最常见的诱因是内存耗尽，重点关注大文件的分块处理优化。

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