ES bulk请求需手动控制分片大小（建议5–15MB），显式调用Do(context)并检查Errors重试失败项，优先使用json.RawMessage避免序列化开销。
bulk请求必须手动控制分片大小，否则容易触发ES熔断
Go客户端本身不自动拆分大bulk请求，直接把几万条数据塞进一个bulk请求里，ES很容易返回429 Too Many Requests或触发circuit_breaking_exception。这不是Go代码写得不对，是ES服务端的内存保护机制在起作用。
- 单个bulk请求建议控制在
5–15MB之间（不是文档条数），具体看每条文档平均大小 - 用
len([]byte(docJSON))预估每条体积，累计到10 * 1024 * 1024就切一刀 - 别依赖
len(docs)来切分——1000条小文档可能才2MB，100条嵌套字段多的文档就超15MB - ES默认
indices.breaker.total.limit是JVM堆内存的70%，超了就拒掉整个bulk
用elastic/v7时bulk操作必须显式调用Do(context)
很多新手卡在“没报错但数据没进去”，其实是忘了执行。v7+版本的bulk对象是惰性构建的，Index().Id().Doc()只是往缓冲里加动作，不发HTTP请求。
- 必须最后调用
bulk.Do(ctx)，且要检查返回的*elastic.BulkResponse和error -
ctx建议带超时：ctx, cancel := context.WithTimeout(context.Background(), 30*time.Second)，避免bulk卡死阻塞goroutine - 不要用
bulk.String()调试——它只返回DSL片段，不反映实际发送内容 - 如果用
elastic.NewBulkIndexRequest()，记得.Index("xxx")设对索引名，否则默认发到twitter（v7示例里的占位名）
批量失败要解析BulkResponse.Errors并重试失败项
bulk不是全成功或全失败，ES会返回每个子请求的结果。忽略response.Errors == true就等于放任部分数据丢失。
- 检查
response.Errors布尔值，为true时遍历response.Items - 每个
item是个map，例如item["index"]["error"]存在说明这条失败，取item["index"]["status"]看HTTP状态码 - 常见可重试错误：
409（版本冲突）、429（限流）、503（节点忙），其他如400（mapping不符）需改数据再试 - 重试时建议用新
bulk实例，别往原对象里追加——原bulk已执行过，内部状态不可复用
用json.RawMessage避免重复序列化，尤其处理动态结构
如果文档结构不固定（比如日志字段随时变），用struct定义再json.Marshal会多一次拷贝和反射开销，还容易因tag写错导致字段丢弃。
立即学习“go语言免费学习笔记（深入）”；
- 直接接收原始
[]byte或用json.RawMessage字段存未解析体，bulk时直接写入bulk.Index().BodyJson(raw) - 这样跳过Go层解码-编码流程，实测10万条可省30%+ CPU时间（尤其字段多时）
- 注意
json.RawMessage必须是合法JSON片段，开头不能有BOM，末尾不能多逗号 - 如果要用
elastic.NewBulkIndexRequest().Doc()，传参必须是interface{}，json.RawMessage符合要求；传[]byte会出错
真正麻烦的不是发bulk，是判断哪条失败、为什么失败、要不要重试、重试几次、失败后怎么降级——这些逻辑几乎每次都要重写，没有银弹。
