Go微服务RPC精度问题根源在于序列化协议、类型定义及传输路径隐式转换；应禁用float/double，改用int64存最小单位或string传标准格式字符串。
Go 微服务中 RPC 调用的数据精度问题，本质不是“RPC 框架本身能控制精度”，而是**序列化协议 + 类型定义 + 传输路径上的隐式转换**共同导致的精度丢失。常见于 float32/float64 在 protobuf 中被截断、JSON 浮点解析歧义、或客户端/服务端对同一字段使用不同数值类型。直接改 float64 变量声明没用，必须从契约层堵住源头。
proto 中避免使用 float/double 类型传精度敏感数据
Protocol Buffers 的 float（32 位）和 double（64 位）在跨语言、跨平台序列化时，无法保证 IEEE 754 行为完全一致；尤其当 Go 客户端用 float64 赋值，Java 服务端用 Double 解析，再经 gRPC wire 编码后，可能触发舍入误差或指数表示差异。
- 货币、金融计算、地理坐标等场景，一律改用
int64存“最小单位整数”：例如金额存“分”而非“元”，经纬度存“微弧度”或“1e7 整数” - 必须传小数时，用
string字段承载标准格式字符串（如"123.456789"），由业务层统一解析 —— 这是唯一能 100% 避免二进制浮点失真的方式 - 不要依赖
google.protobuf.Decimal（非官方标准，go-grpc 不原生支持），它在多数生产环境未被广泛验证
gRPC 客户端和服务端类型必须严格一致
即使 proto 定义用了 int64，如果客户端代码手动把 int64(100) 强转成 float64 再塞进 struct，或者服务端收到后又转回 float64 做运算，精度就已在内存中丢失 —— 这类转换常发生在日志打点、中间件透传、mock 数据构造等环节。
- 检查所有
*_grpc.pb.go生成文件中对应字段的 Go 类型，确认是int64或string，而非float64 - 禁止在 service 层或 handler 中对 RPC 请求字段做
float64(x)或int64(y)隐式/显式转换；如需计算，先转big.Float或decimal.Decimal库处理 - 单元测试里加断言：对比原始输入字符串与序列化后再反序列化的字符串是否完全相等（
reflect.DeepEqual不够，要用字符串比对）
JSON-RPC 或 HTTP 网关层额外引入精度风险
当 Gin 网关通过 gRPC 调用后端服务，再把结果转成 JSON 返回给前端时，json.Marshal 对 float64 的默认行为会截断尾部零、省略指数、甚至在大数时转成科学计数法（如 10000000000000001 → 1e+16），前端 JS 解析后直接变成 10000000000000000。
立即学习“go语言免费学习笔记（深入）”；
- 若网关必须返回 JSON，且字段含高精度数字，用
json.RawMessage或自定义MarshalJSON方法，确保输出为带引号的字符串："123.456789012345" - 避免用
map[string]interface{}中转 RPC 响应 ——interface{}接收float64后，JSON 序列化不可逆 - 前端调用方明确约定：所有精度敏感字段必须按字符串接收并自行解析，不信任 JSON 数值字面量
最易被忽略的一点：etcd 或配置中心里存的“超时阈值”“权重系数”等 float 类型配置项，一旦被 yaml.Unmarshal 加载进 Go 结构体，就可能已发生精度漂移；这类配置建议全量改用整数或字符串表达。
