必须流式切分+异步压缩+带头上报，因设备I/O慢、内存小，等日志写满再压缩会导致OOM、阻塞写入、服务端拒收、无断点续传；需用logrotatelogs轮转+gzip.NewWriter压缩并强制Close，上报时设Content-Encoding: gzip且配置http.Transport防弱网卡死。
本地日志实时压缩与上报不能靠“一次写完再压缩”，必须流式切分 + 异步压缩 + 带头上报，否则在设备端或边缘节点上极易卡死或 OOM。
为什么不能等日志文件写满再压缩上报
设备端磁盘 I/O 慢、内存小，且日志是持续追加的。若等 example.log 写到 500MB 再调用 compressLogFile()，会触发以下问题：
- 单次
os.Open()+io.Copy()占用大量内存（尤其是大文件），GC 频繁抖动 - 压缩过程阻塞日志写入协程，导致新日志丢弃或缓冲区溢出
- 上报时整个文件作为 body 发送，服务端可能因超时或大小限制直接拒收（如阿里云 IoT 网关对解压后 payload 有 ≤1MB 硬限制）
- 无断点续传能力：压缩中崩溃 → 文件损坏，无法恢复
用 logrotatelogs + compress/gzip 实现带时间窗口的切分压缩
核心思路是：按时间（如每小时）或大小（如 10MB）自动轮转日志文件，轮转后立即启动异步压缩，并触发上报。不依赖外部定时器，由库自身事件驱动。
- 使用
logrotatelogs.New创建轮转器，设置WithRotationTime(1 * time.Hour)或WithMaxSize(10 * 1024 * 1024) - 轮转回调中启动 goroutine 调用
compressAndUpload(filename)，避免阻塞主日志流 - 压缩前先检查文件是否已存在
.gz版本，防止重复压缩（os.Stat(filename + ".gz")） - 压缩时用
gzip.NewWriter包裹os.Create目标文件，写完必须gz.Close()，否则尾部 CRC 缺失，解压失败报invalid checksum
示例关键片段：
立即学习“go语言免费学习笔记（深入）”；
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
rotator, _ := logrotatelogs.New(
"logs/app.%Y%m%d%H.log",
logrotatelogs.WithRotationTime(1*time.Hour),
logrotatelogs.WithLinkName("logs/current.log"),
)
rotator.SetRotateHandler(func(src string) {
go func() {
if err := compressAndUpload(src); err != nil {
log.Printf("compress fail: %v", err)
}
}()
})上报请求体必须带 Content-Encoding: gzip 且 Body 不可复用
很多开发者把压缩后的文件读成 []byte，再用 bytes.NewReader 构造 req.Body，却忘了设头 —— 服务端收到二进制数据但没 Content-Encoding，直接当明文解析，必然失败。
- 必须显式调用
req.Header.Set("Content-Encoding", "gzip") - 同时保留
Content-Type: text/plain; charset=utf-8（或application/json，取决于日志格式） - 不要复用同一个
bytes.Reader多次发请求 ——req.Body是单次读取的，第二次读会返回io.EOF - 推荐用
os.Open打开.gz文件构造req.Body，天然支持多次重试（只要 reopen）
错误示范：req.Body = ioutil.NopCloser(bytes.NewReader(buf.Bytes())) —— buf 是临时 buffer，压缩后已丢弃，这里引用的是旧地址。
弱网下必须配置 transport 防握手/响应卡死
边缘设备常跑在 4G/LoRa 等不稳定网络，Go 默认 http.Transport 对移动场景极不友好：
-
MaxIdleConnsPerHost默认为 2，高并发上报时连接池迅速耗尽，后续请求排队等待 -
ResponseHeaderTimeout默认为 0（不限时），服务端 TLS 握手慢或网关排队时，goroutine 永久挂起 -
TLSHandshakeTimeout缺失，弱网下 TLS 握手可能卡住 30 秒以上
务必显式配置：
client := &http.Client{
Transport: &http.Transport{
MaxIdleConnsPerHost: 10,
ResponseHeaderTimeout: 5 * time.Second,
TLSHandshakeTimeout: 3 * time.Second,
IdleConnTimeout: 30 * time.Second,
},
}压缩和上报链路里最容易被忽略的，是 gzip.Writer.Close() 的调用时机 —— 它不是可选的“收尾动作”，而是写入最终 8 字节校验信息的强制操作；漏掉它，服务端解压必然失败，且错误提示模糊（常为 unexpected EOF 或 invalid compressed data）。
