ctx.MultipartForm() 返回空值主因是前端未设 enctype="multipart/form-data" 或 Fiber 未在读取 Body 前调用该方法；需确保字段名匹配、Nginx 配置 client_max_body_size 并透传 Content-Type 头。
上传文件时 ctx.MultipartForm() 返回空值怎么办
常见现象是调用 ctx.MultipartForm() 后得到的 form 里没有 File 字段，form.File 为 nil 或空 map。根本原因通常是客户端没发对 multipart 请求，或服务端没正确解析。
实操要点：
- 确保前端
<form>的enctype是"multipart/form-data"，不能省略或写成"application/x-www-form-urlencoded" - Fiber 默认不自动解析 multipart，需显式调用
ctx.MultipartForm()—— 且必须在读取ctx.Body()或ctx.FormValue()之前调用，否则底层http.Request.Body已被消费，后续解析失败 - 若使用 Postman 测试，选
form-data类型，并把文件字段设为file（与后端 key 名一致），不要误选binary - 检查字段名是否匹配：前端传的是
avatar，后端却查form.File["file"]，自然为空
保存上传文件时如何避免阻塞和路径注入
直接用 file.Open() + os.Create() 写死路径，既不安全也不高效。Fiber 的 file.Save() 是封装好的安全方案，但仍有细节要注意。
实操建议：
- 永远用
filepath.Join()拼接保存路径，别用字符串拼接，防止../../etc/passwd类路径穿越 - 限制文件大小：在路由前加
fiber.Limit{Max: 10 * 1024 * 1024}或用ctx.Locals()配合中间件预检Content-Length -
file.Save()默认会覆盖同名文件，如需防覆盖，先os.Stat()检查是否存在，或用uuid.New().String()生成唯一文件名 - 不要在 handler 里做耗时保存操作（如上传到 OSS），应异步处理或返回 202 + 任务 ID，否则阻塞 Fiber 的 goroutine
下载文件时 ctx.Attachment() 和 ctx.Download() 怎么选
二者都设置 Content-Disposition 响应头，但行为不同：ctx.Attachment() 强制触发浏览器下载对话框；ctx.Download() 在支持 inline 渲染的格式（如 PDF、PNG）上可能直接打开，取决于浏览器策略。
关键差异：
-
ctx.Attachment("report.pdf")→ 响应头含attachment; filename="report.pdf"，必下载 -
ctx.Download("report.pdf")→ 响应头含inline; filename="report.pdf"，浏览器可自行决定渲染 or 下载 - 若文件路径含中文或特殊字符，务必用
url.PathEscape()处理文件名再传入，否则部分浏览器解析失败 - 大文件下载慎用
ctx.SendFile()（内存加载全量），改用ctx.Stream()+io.Copy()流式传输，避免 OOM
为什么本地测试能传，部署到 Nginx 后就超时或 413
这不是 Fiber 的问题，而是反向代理层拦截了 multipart 请求。Nginx 默认限制请求体大小为 1MB，且不透传原始 Content-Type 头可能导致解析失败。
必须检查的 Nginx 配置项：
-
client_max_body_size 50M;（放在http、server或location块中） -
client_body_timeout 300;防止大文件上传被超时中断 - 确认没配置
proxy_pass_request_headers off;，否则Content-Type: multipart/form-data; boundary=...被丢弃，Fiber 收不到 boundary 就无法解析 - 如果用了
proxy_buffering on;，大文件可能卡在 buffer 里，建议关掉或调大proxy_buffers
真正容易被忽略的是：即使 Fiber 启动时加了 DisableKeepalive: true，Nginx 的 keepalive 设置仍可能影响长连接下的分块上传稳定性。上传逻辑复杂时，优先考虑客户端分片 + 服务端合并，而不是硬扛单次大文件。
