Go 调用 HBase 的 Thrift 服务必须使用 Thrift v1 协议，因官方无原生客户端，所有稳定方案均依赖 hbase-thrift 服务且仅支持 v1；需显式指定启动参数、核对 IDL 版本、替换失效的 thrift 依赖，并自行封装带重试和连接池的 Client。
Go 调用 HBase 的 Thrift 服务必须走 Thrift v1 协议
Go 官方生态没有原生 HBase 客户端，所有稳定可用的方案都依赖 HBase 启动的 hbase-thrift 服务，且仅支持 Thrift v1（不是 v2）。如果你看到错误 ProtocolException: Unknown protocol id，基本就是服务端启了 v2、客户端用了 v1 生成的代码，或反过来。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 启动 HBase Thrift 服务时显式指定
-threadpool和-bind，并确认日志里打出的是Starting HBase Thrift server on port 9090 (v1) - 用
thrift --gen go hbase.thrift生成代码前，先核对 HBase 源码里的hbase-thrift/src/main/resources/org/apache/hadoop/hbase/thrift/hbase.thrift版本 —— HBase 1.x 对应 v1，2.x 默认仍为 v1，但部分发行版（如 CDH）可能打过补丁 - 生成的 Go 代码不能直接用
go mod tidy自动拉git.apache.org/thrift.git：该域名已失效，需替换为github.com/apache/thrift并在go.mod中 replace
hbase-go 这类第三方库封装太薄，别指望它自动处理连接池和重试
像 github.com/tsuna/gohbase 或 github.com/dotronglong/hbase-go 确实省去手写 Thrift 调用，但它们只是把 Thrift 方法包了一层，底层仍是单次 RPC 调用。遇到 RegionServer 重启、ZK 临时抖动，就会直接返回 context deadline exceeded 或 EOF，不重试也不换 endpoint。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 自己封装
Client结构体，内嵌*hbase.HbaseClient，并在每个方法（如Get、Put）里加for i := 0; i 循环 + <code>time.Sleep回退 - 不要复用同一个
thrift.TSocket实例跨 goroutine —— 它非线程安全；每次调用前新建 socket，或用连接池（如github.com/panjf2000/gnet简单包装） - HBase 的
get和put都要求传TableName字符串，不是table；若传错（比如少了 namespace，如"mytable"而不是"default:mytable"），会静默返回空结果，不报错
Scan 操作最容易 OOM，必须严格控制 batch 和 caching 参数
HBase 的 scan 在 Thrift 层对应 getScannerResults，它不像 Java 客户端那样自动流式读取。Go 客户端一次调用就试图把整个 scan 结果拉到内存，如果没设限，几万行就能吃光 2GB 内存。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 创建 scanner 时务必设置
Scan.caching = 100（不是默认的 -1），并配合Scan.batch = 100控制单次返回列数 - 手动分页：用
StartRow+StopRow切分范围，比靠getScannerResults循环更可控；例如按 rowkey 前缀"user_202401"扫，stop 设为"user_202402" - 别用
Scan.filterString写复杂过滤（如正则）—— Thrift v1 的 filter 解析能力弱，容易返回IOError: java.lang.UnsupportedOperationException
时间戳和版本控制在 Go Thrift 调用里是隐式陷阱
HBase 行级时间戳（timestamp）和列族级 VERSIONS 设置，在 Thrift 接口里不以参数形式暴露，而是通过 cell 结构体的 timestamp 字段和表定义共同生效。Go 客户端拿到的 Result 里，同一 cell 可能含多个 timestamp 不同的值，但默认只取最新一个 —— 如果你没主动遍历 cell.Timestamp，就根本意识不到旧版本还存在。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
-
Get时想读多版本，必须设Get.maxVersions = 5（不能只靠表的VERSIONS=>5）；否则即使服务端存了 5 个版本，Thrift 只返 1 个 -
Put时不填cell.Timestamp，HBase 会自动打当前服务器时间戳；但如果你在分布式环境下做因果序控制，得自己传纳秒级时间戳，并确保各节点时钟误差 - 删除操作（
Delete）若没指定timestamp，会删掉该 cell 所有版本；若指定了，只删对应时间戳那一条 —— 这点和 Java 客户端行为一致，但 Go 示例代码里常被忽略
真正麻烦的从来不是连上 Thrift，而是 region 分裂后 scanner 持有的 old region location 失效，又没触发自动 reload。这个逻辑得自己在 getScannerResults 返回 IOError 且消息含 "Region is not online" 时捕获并重建 scanner。
