go es bulk失败需检查res.body中items状态，因http 200不等于成功；微服务同步es应优先用业务层hook+内存队列，而非binlog监听。
Go 写 ES 同步逻辑时，bulk 请求失败但没报错？检查 res.IsError() 和 res.Body
ES 的 Go 客户端（比如 elastic/v7 或官方 olivere/elastic）在调用 Bulk 时，HTTP 状态码可能是 200，但实际每条文档的写入结果藏在响应体里。很多人只看 err != nil 就以为成功了，结果数据根本没进 ES。
- 必须显式读取
res.Body并解析 JSON，检查items数组中每个操作的status字段（400、409、500 都算失败） -
res.IsError()只判断 HTTP 层错误，对 bulk 内部部分失败完全不敏感 - 别直接用
json.Unmarshal(res.Body, &v)，先用io.ReadAll读完再解，否则 body 流可能被提前关闭
微服务间数据变更怎么可靠推给 ES？别依赖数据库 binlog + canal，先看业务层能不能加 hook
在订单服务、用户服务这类核心微服务里，硬塞一个 MySQL binlog 监听模块，运维成本高、延迟不可控、还容易丢事件。更轻量的做法是：在业务代码提交事务前，把变更结构体塞进本地 channel 或内存队列，再由单独 goroutine 异步发到 ES。
- 适合变更频率不高（QPS
- 关键点：channel 要带缓冲（比如
make(chan *OrderEvent, 1000)），goroutine 里用for range消费，避免 panic 后丢失事件 - 如果必须跨服务同步，优先走消息队列（Kafka/RocketMQ），而不是直连其他服务的 HTTP 接口——后者一挂就堵死整个写链路
elastic.NewBulkRequest() 的 Index 和 DocumentID 怎么设才不踩坑？
ES 索引名不能含大写字母、下划线开头、或点号，而 Go struct 字段名常是 UserID 或 CreatedAt，直接当索引名或 ID 用会 400 报错。
-
Index建议固定写死（如"order_search_v2"），不要拼接时间或服务名；版本升级时建新索引，用 alias 切换 -
DocumentID强烈建议用业务主键（如order_id），别用uuid.New()—— 否则更新时无法幂等，同一条订单反复同步会生成多份文档 - 如果业务主键是 int64，ES 里存成 string 更安全（避免 Java 客户端解析溢出），Go 里用
strconv.FormatInt(id, 10)
ES 字段类型映射不对，搜不到也 update 不了？Go struct tag 别只写 json:
ES 不认 Go 的 json:"user_name"，它靠 mapping 定义字段类型。如果 Go 结构体字段是 time.Time，但 ES 里对应字段是 text 类型，写入会失败或转成字符串，后续范围查询直接失效。
立即学习“go语言免费学习笔记（深入）”；
- 上线前手动 PUT 一次 mapping，明确指定
"user_name": {"type": "keyword"}、"created_at": {"type": "date", "format": "strict_date_optional_time||epoch_millis"} - Go struct 上除了
json:，建议加自定义 tag 如es:"keyword"，方便后续封装自动建索引工具 - 别让 ES 自动 mapping：一旦某个字段第一次写入是 string，后面写 int 就会 400；宁可初始 mapping 严一点，字段少加，后期再
PUT _mapping补
最麻烦的不是写同步逻辑，而是 mapping 改了之后老数据查不出来、新旧格式混在一起、bulk 响应里 status=400 却没打印具体哪条出错——这些细节卡住三天都调不完。
