golang 服务器处理上传时，如果 form 文件过大，居然会往/tmp 目录写文件，要怎么优雅的处理呢？

定期重启一下

服务本身不处理，丢给 s3 去存

这块是标准库的代码，好像是有处理的。

https://cs.opensource.google/go/go/+/master:src/net/http/server.go;l=1719;drc=c0e149b6b1aa2daca64c00804809bc2279e21eee

@wunonglin 本来就是传给 s3 的，但是 golang 的 multipart-form 在文件大于一个值时默认行为就是往/tmp 目录下写文件。如果没主动去调用 RemeveAll 他居然就留着/tmp 下文件不管了...

@hingle 好像还真是，所以归根到底问题是 gin 框架的？他自己没有调用 RemoveAll?

@zihuyishi gin 用的就是标准库的 http.Server ，会调用 RemoveAll 的啊

是不是你客户端那边一直没断开连接？或者出现一些异常导致没发送 FIN 之类的。

@hingle 我在 debug/pprof 里面看链接都断开了呀，而且上传请求也都是正常的返回，难道有些 middleware 会改变一些默认行为？

不考虑直传给 s3 吗（中转各方面也不划算）？

流处理可不可以，哦对了，form 表单好像不行

python 也这样吧

如果你能预估出来上传的文件大小范围，而且内存充足，可以调大 MaxMultipartMemory ，可以减少临时文件使用，默认是 32MB 。

1. 这一块是标准库实现的逻辑，当 HTTP 请求响应结束后，会自动删除临时文件，无需手动调用 RemoveAll 。
2. 虽然可以手动控制 req.ParseMultipartForm(maxMemory int64) 参数来缓解，但是无法根治该问题。
3. 上传的临时文件越来越多，竟然没有自动删除，我觉得你需要排查一下这个问题。

自动删除逻辑： https://github.com/golang/go/blob/0f8ab2db177baee7b04182f5641693df3b212aa9/src/net/http/server.go#L1718-L1720

我在 gin 那看到你提的 pr 和 issue 了，我发现自己的项目也有这个问题，起初我以为是 gin 的 bug ，后来排查下来发现其实是我自己引起的，确实很隐蔽
先说结论，你可能跟我一样在 middleware 里使用了 ctx.Request = xxx 的操作，导致 http.serve 创建的 req 变掉了
而自动清理临时文件是在 finishRequest 方法调用，依赖的是 w.req.MultipartForm != nil ，如果你在前面覆盖了 req ，那就和这里 w.req 指向不一样了，
MultipartForm 最开始是没有初始化的，算是按需初始，也就是执行完 middleware 到了 handler 后打算获取 file 的时候，初始化后赋值给 req ，但是这时候已经是新的 req 了，而 finishRequest 还在调用旧的 req

@FrankAdler #13 你这个方向靠谱

不要用自带的，自己用 mutilpart form 解析就不会写临时文件了。

@FrankAdler 好像还真是这个，我为了加 opentelemetry 自己替换了一个 request. 所以我还是要自己主动在替换掉的地方处理一下？

@zihuyishi #16 知道根因了，你自己想办法解决吧，无非就是去掉替换 Req 或者主动调用 RemoveAll 了，或者加一个 middleware 在最后也来个 req.MultipartForm != nil

@FrankAdler 再加一个 middleware 去最后调用 RemoveAll 好像也不是太稳妥，因为可能最后拿到的 Request 不是持有 MultipartForm 的 Request ，可能还是原地改 Request 的去调用比较好？

@zihuyishi #16 我没用过 opentelemetry ，不太理解为什么加 opentelemetry 要替换原来的 Request ，看看有没有什么写法：再不替换原来的 Request 情况下加入 opentelemetry 。

@bv #19 替换 Request 容易给自己埋坑，你发现了 File 没删除你需要打补丁去删除 MultipartFile ，过几天又发现 req.Body 没有自动 Close ，是不是还要打补丁