serverless中不能直接os.open大文件，因为函数无挂载文件系统、部署包大小受限（lambda≤250mb）、读取会一次性加载内存触发oom或超时，且/tmp空间小、生命周期短，无法可靠存储或访问大文件。
Serverless 环境（如 AWS Lambda、Google Cloud Functions、Vercel Edge Functions）对文件流处理有硬性限制：内存固定、执行时间短、临时磁盘空间有限（通常仅 512MB 以内）、无持久文件系统。直接套用本地 io.Copy 或 os.Open 会失败或超时。
为什么 Serverless 中不能直接 os.Open 大文件
Serverless 函数启动时没有挂载常规文件系统，os.Open("large.zip") 会报 no such file or directory；即使你把文件放在部署包里，也受限于函数包大小（Lambda 最大 250MB），且读取时仍会一次性加载进内存——触发 OOM 或超时。
- 所有输入必须来自 HTTP 请求体、事件参数或外部存储（S3、GCS、DB）
- 临时目录（如
/tmp）可用但容量小、生命周期短，不能依赖它存放大文件 - 函数冷启动后，
os.Stat或os.ReadFile对部署路径的访问常不可靠，尤其在 Vercel 或 Cloudflare Workers 中
如何从 HTTP 请求中安全读取 multipart 文件流
前端用 enctype="multipart/form-data" 提交时，Serverless 函数需绕过 r.ParseMultipartForm() —— 它会把整个 body 加载进内存或临时文件，而 Serverless 的 /tmp 很可能撑不住。
- 改用
multipart.NewReader(r.Body, boundary)手动解析，边读边处理，不缓存整份 body - 先用
r.Header.Get("Content-Type")提取 boundary，再构造multipart.Reader - 对每个
part调用part.Header.Get("Content-Disposition")匹配name="file"字段 - 用
io.CopyN(dst, part, limit)控制单次读取量（如 1MB），避免缓冲区膨胀
示例关键片段：
boundary := parseBoundary(r.Header.Get("Content-Type"))
mr := multipart.NewReader(r.Body, boundary)
for {
part, err := mr.NextPart()
if err == io.EOF {
break
}
if part.FormName() == "upload_file" {
// 直接转发到 S3 或做校验，不落地
_, _ = io.CopyN(ioutil.Discard, part, 10*1024*1024) // 限 10MB
}
}
流式上传到对象存储（S3/GCS）的正确姿势
Serverless 函数不该“保存文件”，而应作为中转：接收流 → 校验/转换 → 直接推送到 S3/GCS。否则临时文件写满 /tmp 就崩溃。
- 用 AWS SDK 的
s3manager.Uploader，传入io.Reader（如part），它内部自动分块上传，支持断点续传 - 避免自己拼
PutObjectInput.Body = bytes.NewReader(data)—— 这又把内容全 load 进内存 - GCS 可用
gcs.NewWriter，设ContentType和ObjectAttrs，然后io.Copy(w, part)，最后w.Close()触发上传 - 务必设超时：
ctx, cancel := context.WithTimeout(context.Background(), 30*time.Second)，防止卡住
容易被忽略的 timeout 和 context 陷阱
Serverless 平台默认超时很短（Lambda 默认 3 秒，可扩到 15 分钟但需显式设置），而流式上传可能因网络慢卡在 io.Copy 里不动，函数却没感知。
-
http.Request.Context()在 Serverless 中往往不传递 deadline，必须自己 wrap 新 context - 所有阻塞调用（
uploader.Upload、io.Copy、gcs.Writer.Close）都要传带 timeout 的ctx - 别依赖
defer file.Close()—— 如果file是从r.MultipartForm拿的，它可能根本没 open 成功；优先用part的生命周期管理 - 错误日志要打全：
err.Error()不够，得加fmt.Sprintf("upload failed: %v, part size: %d", err, part.Size())
真正难的不是怎么读，而是怎么在资源随时被回收的环境里，让流不中断、不泄漏、不超时——每一步都得带 context，每一段都得设上限，每一个 close 都得检查 error。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
