MAX_CONTENT_LENGTH是Flask拦截超大文件上传的首选机制，通过Content-Length头在解析前返回413错误；需在app.config中设置字节数，且须与Nginx的client_max_body_size同步调整。
Flask上传文件超限直接 413 错误，MAX_CONTENT_LENGTH 是第一道防线
Flask 默认不限制请求体大小，大文件上传会吃光内存、拖垮服务，甚至被用来做 DoS 攻击。MAX_CONTENT_LENGTH 是最轻量、最有效的拦截方式——它在解析请求体前就检查 Content-Length 头，不读磁盘、不进视图函数，失败直接返回 413 Request Entity Too Large。
- 必须在
app.config中设置，且要在创建Flask()实例后、任何路由注册前生效 - 单位是字节，不是 KB 或 MB；写成
16 * 1024 * 1024比16777216更可读也更少出错 - 如果用了 Nginx，它默认只允许 1MB，得同步调大
client_max_body_size，否则用户根本传不到 Flask 层 - 该配置对所有请求生效（包括 JSON POST），如需按 endpoint 区分限制，得用中间件或装饰器二次校验
为什么 request.files 里没文件，但 request.form 还能取到数据？
因为 MAX_CONTENT_LENGTH 触发时，整个请求体被 Flask 丢弃，request.files 和 request.form 都为空。但如果用户绕过前端限制、手动构造 multipart 请求并塞入超大字段，而你又只检查 request.files 是否为空，就可能漏掉恶意 payload——比如在 request.form['description'] 里塞几十 MB 的 base64 图片。
-
MAX_CONTENT_LENGTH是全局守门员，但它拦不住“小体积+高密度”的攻击（如压缩炸弹、超长文本） - 上传逻辑里仍要检查
file.filename是否为空、file.content_type是否可信、file.stream.read(1)是否抛异常 - 不要依赖前端的
<input type="file" max-size="...">，那只是提示，完全可被绕过
和 Werkzeug 的 max_content_length 参数冲突吗？
不冲突，但容易混淆：MAX_CONTENT_LENGTH 是 Flask 的配置项，底层交给 Werkzeug 的 Request 类处理；而 Werkzeug 自己也有一个 max_content_length 参数（比如在 Request.from_values() 里），那是测试或特殊构造请求时用的，生产环境不用管它。
- 只设
app.config['MAX_CONTENT_LENGTH']就够了，别去动Request构造参数 - 如果你用了
flask.testing.TestClient写单元测试，上传大文件时会报错，这时要在测试里临时覆盖配置：app.config['MAX_CONTENT_LENGTH'] = 1024 * 1024 - Werkzeug >= 2.1 后，
Request默认启用max_content_length校验，但 Flask 仍以自己的配置为准，不会覆盖
上传成功后，怎么避免临时文件占满磁盘？
request.files['xxx'].save() 会把文件先写进系统临时目录（由 tempfile.gettempdir() 决定），再移动。如果用户上传大量文件又没清理，/tmp 可能爆满——这不是 MAX_CONTENT_LENGTH 能管的事，得主动干预。
- 用
request.files['xxx'].stream.read()直接读二进制流，边读边存（比如写入 S3 或数据库 BLOB），避免落地临时文件 - 如果必须用
.save()，记得加 try/except，并在 finally 里用os.unlink()清理临时路径（前提是知道它在哪） - 更稳妥的做法：上传前用
request.files['xxx'].stream.seek(0, 2)获取长度，再.seek(0)回头读，这样既校验大小又不额外复制
Flask 的 MAX_CONTENT_LENGTH 看似简单，但它只管“总大小”，不管单个字段、不解压、不校验 MIME 类型——真正的防护得靠组合拳：Nginx 限流 + Flask 全局拦截 + 视图内字段级校验 + 存储层流式处理。
