直接用 tikv.RawClient 会连不上集群，因其不自动读取 PD 地址、不做服务发现，仅依赖硬编码的 PD endpoints；若地址错误或未配 TLS/网络不通，连接将超时而非报明确错误。
为什么直接用 tikv.RawClient 会连不上集群
默认配置下，tikv.RawClient 不自动读取 PD 地址，也不会做服务发现 —— 它只认你硬编码的 PD endpoints。如果你只传了 "127.0.0.1:2379" 但实际 PD 在 "10.0.1.5:2379"，连接会卡在 context deadline exceeded，而不是报明确错误。
- 必须显式初始化
tikv.NewRawClient，且第一个参数是[]string类型的 PD endpoint 列表，不能是单个字符串 - PD endpoint 必须带端口，且确保该地址可被 Go 进程直连（Docker 网络、防火墙、TLS 开关都要对得上）
- 如果集群启用了 TLS，得额外传
tikv.WithSecurity，否则握手失败，日志里只显示failed to dial pd client，不提 TLS
RawClient.Put 和 RawClient.Get 的 key 编码陷阱
TiKV Raw API 对 key/value 没有任何编码约定，它原样存你给的 []byte。这意味着：Go 字符串转 []byte 是 UTF-8 编码，但如果 key 里有二进制前缀（比如 \x00\x01）、或你从其他系统（如 Rust 的 Vec<u8></u8>）迁移数据，直接拼接会导致乱序或截断。
- 避免用
string(key) + "_suffix"拼接 key；改用append([]byte(key), '_','s','u','f','f','i','x') -
Get返回的 value 是裸[]byte，别直接fmt.Println(val)—— 遇到不可见字节会打印空或乱码，先用hex.Dump(val)看真实内容 - Raw 模式不支持 TTL，想带过期时间？得自己在 value 里塞时间戳 + 应用层清理，TiKV 不管
并发写入时 RawClient 的连接复用与超时设置
一个 tikv.RawClient 实例是线程安全的，内部用连接池复用底层 gRPC 连接。但默认的 grpc.Dial 参数太保守：短连接、无健康检查、超时设为 3 秒 —— 高频小 key 写入时容易触发 rpc error: code = DeadlineExceeded。
- 初始化 client 时加
tikv.WithGRPCDialOptions(grpc.WithTimeout(10*time.Second)) - 如果压测中看到大量
connection refused或transport is closing，说明 PD 或 TiKV 节点负载高，需调大grpc.WithKeepaliveParams - 不要为每次请求 new 一个
RawClient—— 建立 PD 连接开销大，且可能耗尽本地端口
Raw 模式下没有事务，但仍有写冲突和重试逻辑
Raw API 绕过了 TiKV 的 Percolator 事务层，所以 Put 是单 key 原子写，但不保证多 key 一致性。不过，底层仍可能因 region 分裂、leader 切换导致单次 Put 失败，client 默认会重试 10 次（不可配）。
立即学习“go语言免费学习笔记（深入）”；
- 重试期间 key 可能已被其他 client 覆盖，应用层若依赖“写入即生效”，要自己加 version 字段或 CAS 逻辑
- 如果收到
rpc error: code = Aborted desc = ... epoch not match，说明 region 已分裂，client 会自动刷新路由，但你的上下文可能已 cancel，需检查ctx.Err() - 批量写建议用
RawClient.BatchPut，比循环Put少 90% 的网络往返，但 batch size 别超 1MB，否则被 server 拒绝
Raw 模式省去了事务开销，也扔掉了事务语义 —— key 是否存在、是否被覆盖、是否跨 region，全靠你自己拿捏。稍微复杂点的业务逻辑，不如切回 tikv.Client（也就是普通事务 client），哪怕多点开销，至少语义清晰。
