必须用io.limitreader+循环控制分块，因bufio.reader和反复read无法精确控制字节边界，且strings.newreader配合io.copy虽简单但不满足固定大小切分需求。
直接用 strings.NewReader 包裹大字符串再传给 io.Copy 就行，不需要手动分片；但若需按字节上限切分（比如每块 512KB），必须用 io.LimitReader + 循环控制，不能靠 bufio.Reader 或反复 Read。
为什么不能把大字符串转成 []byte 后循环 Write
看似简单，实则危险：每次 Write 都可能只写入部分数据（返回 n ），而标准库的 <code>io.Writer 实现（如 os.File、net.Conn）不保证一次写完。若忽略返回值 n，就会静默丢数据。
-
Write返回n是实际写入字节数，必须校验是否等于预期长度 - 手动循环需处理
io.ErrShortWrite，逻辑易错且重复 - 字符串本身已在内存，再切片复制反而增加 GC 压力——不如让
io.Copy直接调度
用 io.LimitReader 实现固定大小分块写入
这是唯一能精确控制每块字节数、又不加载全文进内存的标准方式。它不移动原 io.Reader 的偏移，适合多次复用或跳过前导内容。
- 构造方式：
io.LimitReader(r, chunkSize)，其中r是strings.NewReader(largeStr) - 每次调用
io.Copy(dst, limitedReader)写入恰好chunkSize字节，或到 EOF 为止 - 返回值
n, err := io.Copy(...)中，n == chunkSize表示写满，n == 0 && err == io.EOF表示源已尽 - 不要在循环里重用同一个
limitedReader实例——它是一次性的，需为每块新建
写入目标是网络连接或管道时的注意事项
http.Request.Body、net.Conn、os.PipeWriter 都接受 io.Reader，但行为差异大：前者会自动流式发送，后者可能阻塞或断连。
- HTTP 请求体不支持
Seek，所以别试图用os.File配合Seek回退重试 - 写入
net.Conn时，务必检查write: broken pipe和connection reset by peer错误，它们不会立刻暴露 - 若目标是
io.MultiWriter（如同时写文件+日志），确保每个 writer 都能承受流式压力，避免某一个慢导致整体卡住
别碰 bufio.Scanner 或 bufio.Reader.ReadString 来处理纯字符串分片
这些工具专为「按行解析」设计，内部有缓冲和状态机。拿它们切固定字节块，要么越界读取破坏后续逻辑，要么因换行符缺失卡死。
-
Scanner.Scan()每次读一行，无法指定字节数；Scanner.Bytes()返回的切片可能指向已释放缓冲区 -
bufio.Reader.ReadString('\n')会一直读到换行符才返回，若字符串无换行，就永远等不到 EOF - 真正需要「按行切分」时，才启用它们；纯字节流场景，
io.LimitReader更轻量、更可控
最易被忽略的是：分块写入不是为了“快”，而是为了“可控”——控制内存峰值、控制单次系统调用大小、控制错误发生位置。哪怕字符串已在内存，也要用 io.LimitReader 把它切成可审计的 chunk，否则一旦目标端中断，你根本不知道卡在哪一块、丢了哪一段。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
