应避免大文件读取时调用.read()等一次性加载方法，改用分块读取、流式处理、临时文件磁盘存储及作用域隔离，并通过max_content_length限制上传大小、禁用全局缓存、谨慎记录日志来防止内存溢出。
大文件读取时直接用 open().read() 会爆内存
Flask 默认没有请求体大小限制，用户上传一个 500MB 的文件，如果你写 request.files['file'].read() 或 file.stream.read()，整个内容会一次性载入内存 —— 这不是“可能”溢出，是“必然”溢出。Python 的 bytes 对象在内存中是连续分配的，且 GC 不会立即回收大对象，尤其当引用链隐式存在（比如被日志、临时变量、闭包捕获）时。
实操建议：
- 永远避免对未知大小的上传流调用
.read()、.readlines()、.readall() - 改用流式处理：用
for chunk in file.stream: ...或file.stream.read(8192)分块读取，每次只持有几 KB - 若需校验文件头（如判断是否为 CSV/PDF），只读前 1024 字节：
file.stream.read(1024)，之后调用file.stream.seek(0)回溯（注意：仅当stream支持 seek，如TemporaryFile；Werkzeug 的FileStorage在内存模式下支持，磁盘模式下也支持） - 上传前加前端限制 + 后端
MAX_CONTENT_LENGTH双保险：app.config['MAX_CONTENT_LENGTH'] = 16 * 1024 * 1024 # 16MB
超限会直接返回 413，不进视图函数
del 不等于立刻释放内存，关键在引用计数归零
很多人以为写了 del big_data 就万事大吉，但实际内存没降 —— 因为 big_data 可能还被其他变量、列表、字典、闭包或异常 traceback 引用。Python 的内存回收主要靠引用计数，del 只是减一，只有归零才触发释放。
实操建议：
- 显式
del有用，但前提是确认它是唯一引用源。常见陷阱：result = process(big_file); del big_file—— 如果process()内部缓存了它，或返回值里隐含引用，del无效 - 用
sys.getrefcount(obj)快速检查（注意：传参本身会+1，结果要减 1 或 2） - 更可靠的做法是“作用域隔离”：把大对象处理逻辑放进函数内，让局部变量随函数返回自动销毁。例如：
def handle_upload(file_stream):<br> data = []<br> for chunk in file_stream:<br> data.append(chunk.upper())<br> return b''.join(data)<br># 函数退出后 data 自动不可达，无需 del
- 极端场景（如长时运行的 Flask worker 处理多个大文件），可手动触发 GC：
import gc; gc.collect()，但别滥用 —— 它开销不小，且不能解决循环引用外的常规问题
用 tempfile.SpooledTemporaryFile 替代内存缓冲
默认情况下，Werkzeug 把小上传（MAX_MEMORY_FILE_SIZE=512*1024）放内存，大的落磁盘。但你无法控制这个阈值在运行时生效，且一旦进内存，就已踩中风险。
实操建议：
- 初始化
FileStorage时强制走磁盘：在接收文件后立刻转成SpooledTemporaryFile并设小max_size：from tempfile import SpooledTemporaryFile<br>file = request.files['file']<br>spooled = SpooledTemporaryFile(max_size=1024, mode='w+b')<br>spooled.write(file.read()) # 注意：这里仍是一次性 read，仅用于演示<br>spooled.seek(0)
更安全的是边读边写：while True: chunk = file.stream.read(8192); if not chunk: break; spooled.write(chunk) -
SpooledTemporaryFile在max_size超限时自动切换到磁盘，且.close()后自动删除 —— 避免临时文件堆积 - 不要用
NamedTemporaryFile（除非你明确需要文件路径），它不自动清理，且名字暴露在 /tmp 下可能被误读
Flask 中全局变量/缓存/日志是内存泄漏高发区
很多人为“提速”把解析后的数据塞进 app.config、模块级 dict 或 @lru_cache，结果用户反复上传不同大文件，缓存越积越多，最终 OOM。Flask 的 worker 进程生命周期远长于单个请求，这些对象不会随请求结束消失。
实操建议：
- 绝对禁止把上传内容、解析结果存入全局变量或
app对象属性 - 用
flask.g存放单次请求内的临时数据（如中间解析结果），它随请求上下文自动销毁 - 如果必须缓存，用带 TTL 和容量限制的外部缓存（如 Redis），而不是 Python 进程内字典
- 日志慎打大对象：
logger.info("data=%r", huge_dict)会触发repr()，可能把整个结构加载进内存并格式化成字符串 —— 改用摘要：logger.info("data len=%d, keys=%s", len(huge_dict), list(huge_dict.keys())[:3])
真正危险的从来不是某一行 del 没写，而是整个数据生命周期没设计清楚：谁创建、谁持有、谁释放、何时释放。Flask 是无状态协议的封装，别把它当成长连接服务来用内存。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
