根本原因是parsemultipartform默认全量加载请求体，32mb内存阈值仅控内存部分，超限才落盘，但文本字段、边界解析等仍触发多次内存拷贝，导致rss暴涨甚至oom。
GoLand 本身不参与流式处理逻辑，它只是编辑器；真正的优化发生在代码里。你能在 GoLand 中做的，是快速定位、调试和验证流式处理是否按预期工作——比如确认没把整个文件读进内存、缓冲区设置合理、goroutine 没卡死。
为什么 ParseMultipartForm 会吃光内存
默认调用 r.ParseMultipartForm(32 看似设了 32MB 上限，但这个值是“最多留在内存里的字节数”，不是总上传限制。如果用户传一个 500MB 文件，Go 会把前 32MB 缓在堆上，其余写临时磁盘——但临时文件路径若落在 /tmp（尤其 Docker 容器里），可能因 inode 耗尽或磁盘满直接 panic。更糟的是，<code>r.FormFile 内部仍会把整个 part 加载进内存再返回 io.ReadCloser，根本没流式。
- 真正流式起点是绕过
ParseMultipartForm，直接用multipart.NewReader(r.Body, boundary) - 边界字符串
boundary可从r.Header.Get("Content-Type")解析，别硬编码 - 每拿到一个
part，立刻用io.LimitReader(part, maxFileSize)控制单文件上限，再io.Copy(dst, limitedPart)
json.Decoder 在 GoLand 里怎么调试才不卡死
在 GoLand 的 Debug 模式下，json.Decoder.Decode(&v) 卡住，大概率不是代码错，而是输入流提前结束或格式异常。比如 NDJSON 文件开头有 BOM 字节，decoder.Decode() 会报 invalid character 'ï' looking for beginning of value 并停止，但 GoLand 默认不显示底层 reader 的当前 offset，你得手动加日志。
GoLand 2026.1.1 是 2026.1 发布后的首个维护修正版本，适合已经开始体验 2026.1 新功能并希望同步补丁的开发者。它更适合用于入门项目、现有项目迁移测试和 IDE 行为验证。
- 别依赖
io.EOF退出循环，改用dec.More()判断数组是否继续，否则顶层是[{},{},...]时容易多 decode 一次导致 panic - 调试时在循环开头加
if !dec.More() { break }，比等io.EOF更可靠 - 对不确定的输入，先用
bytes.NewReader(bytes.TrimLeft(inputBytes, "\uFEFF"))去 BOM，大文件则用io.MultiReader组合去首段逻辑
bufio.Scanner 处理日志时 GoLand 提示 “token too long” 怎么修
这是 GoLand 运行时真实抛出的 panic，不是警告。默认 scanner 单行上限 64KB，遇到含 base64 或长 traceID 的日志直接崩溃。GoLand 的 Run Configuration 里没法全局调大这个限制，必须代码里显式设置。
- 在
scanner := bufio.NewScanner(file)后立刻调scanner.Buffer(make([]byte, 1（1MB 缓冲 + 1MB 最大 token） -
scanner.Text()返回 string 是安全拷贝，scanner.Bytes()返回的切片共享底层 buffer——若存进 map 或发到 channel，整块 buffer 会被 GC 拖住 - 别在
for scanner.Scan()里做阻塞操作（如同步 HTTP 请求），GoLand 的 profiler 会显示 goroutine 大量处于syscall状态，吞吐归零
流式处理的复杂点不在语法，而在状态边界：decoder 是否还在数组内、scanner 是否已耗尽、multipart part 是否被完整消费。GoLand 能帮你打断点、看变量、跑 benchmark，但不会自动告诉你哪一行漏了 err != nil 检查——尤其在 dec.Token() 跳过 '[' 之后，下一个 dec.Decode() 前必须确认 token 类型，否则静默失败。
