go流处理panic主因是忽略io.reader.read的error而直接操作数据；须检查err并区分io.eof（正常结束）与其他错误；bufio.scanner需检查scanner.err()防errtoolong；json.decoder应循环调用decode解多对象；io.readcloser必须defer关闭防泄漏。
Go 中 io.Reader 流处理时 panic 了，但没看到错误信息
流式处理中 panic 往往是因为忽略了 io.Reader.Read 返回的 error，而直接对返回的 []byte 做操作（比如解码 JSON、解析 CSV），结果遇到 EOF 或网络中断后继续读，触发越界或 nil 指针 panic。
正确做法是每次 Read 后必须检查 err，且区分 io.EOF 和其他错误：
-
io.EOF是正常结束信号，不是异常，应主动退出循环 - 其他
err != nil才该记录、重试或中断 - 别用
defer recover()捕获流中 panic——它掩盖了真正未处理的错误路径
示例片段：
for {
n, err := reader.Read(buf)
if err != nil {
if errors.Is(err, io.EOF) {
break // 正常结束
}
return fmt.Errorf("read failed: %w", err) // 真实错误
}
// 处理 buf[:n]
}用 bufio.Scanner 处理大文件时突然停止，也不报错
bufio.Scanner 默认缓冲区只有 64KB，单行超长（比如日志里带大段 base64）会直接返回 scanner.Err() == bufio.ErrTooLong，但很多人只检查 scanner.Scan() 返回值，漏掉这个隐藏错误。
立即学习“go语言免费学习笔记（深入）”；
解决方式很直接，但容易被跳过：
- 调用
scanner.Err()判断是否因缓冲区不足失败 - 用
scanner.Buffer(make([]byte, 4096), 1 手动扩大最大令牌长度（第二个参数） - 如果数据本身无“行”概念（如连续 JSON 对象），别硬用
Scanner，换json.Decoder或逐块Read
常见误写：
for scanner.Scan() { /* 忽略 scanner.Err() */ }应改为：
动态WEB网站中的PHP和MySQL详细反映实际程序的需求，仔细地探讨外部数据的验证(例如信用卡卡号的格式)、用户登录以及如何使用模板建立网页的标准外观。动态WEB网站中的PHP和MySQL的内容不仅仅是这些。书中还提到如何串联JavaScript与PHP让用户操作时更快、更方便。还有正确处理用户输入错误的方法，让网站看起来更专业。另外还引入大量来自PEAR外挂函数库的强大功能，对常用的、强大的包
for scanner.Scan() {
process(scanner.Text())
}
if err := scanner.Err(); err != nil {
return err // 这里才捕获 ErrTooLong 等
}
json.Decoder.Decode() 在流里解码多个对象失败，只解出第一个
这是典型误解：JSON 流（如 NDJSON / JSON Lines）里每个对象是独立的，但 json.Decoder 默认只解一次。如果源数据是多行 JSON，不循环调用就会停在第一个。
关键点在于「解码器复用」和「错误恢复边界」：
- 一个
*json.Decoder可以反复调用Decode()，无需重建 - 某次
Decode()出错（如字段类型不符），不影响后续调用——除非底层io.Reader已损坏 - 不要把整个流塞进
json.Unmarshal()，它不支持流式，会 OOM
安全写法：
dec := json.NewDecoder(reader)
for {
var v MyStruct
if err := dec.Decode(&v); err != nil {
if errors.Is(err, io.EOF) {
break
}
log.Printf("decode error (skipping): %v", err)
continue // 跳过坏行，继续下一条
}
handle(v)
}错误处理后要不要关掉 io.ReadCloser？
要，而且必须在所有路径上关闭，包括错误分支。流式处理中常见漏关导致文件句柄泄漏或 HTTP 连接无法释放。
最稳妥的是用 defer，但注意作用域：
- 在函数入口拿到
io.ReadCloser后立刻defer closer.Close() - 如果中间有重定向（比如 gzip.NewReader(closer)），新 reader 不负责关底层，原
closer仍需关闭 - 别在循环里 defer —— 它会在函数结束才执行，不是每次迭代后
反例：
resp, _ := http.Get(url)
defer resp.Body.Close() // ✅ 正确位置
dec := json.NewDecoder(resp.Body)
for dec.Decode(&v) == nil {
// ...
}
// 即使 Decode 报错，Body 也已确保关闭流式错误处理的复杂点不在语法，而在错误发生时你是否还掌握当前读取位置、是否能安全跳过并继续、以及底层资源是否真的释放干净——这些都藏在 err 的具体类型和调用时机里。
