Kratos性能取决于transport选型、中间件配置、proto定义及压测方式；kratos run开发模式会严重拖慢压测，需改用go run或二进制启动，并关闭trace、调低日志等级、优选gRPC或fasthttp transport。
Kratos 框架本身不直接决定性能上限，真正影响压测结果的是你用它怎么组织 transport、中间件、序列化和底层 runtime——它提供的是可调优的骨架，不是开箱即爆的“性能盒子”。
kratos run 启动方式对压测结果有致命影响
默认 kratos run 会加载完整开发态配置：日志全量输出、链路追踪全采样、debug 模式开启、config 热重载监听全开。这些在压测中全是 CPU 和 GC 的隐形杀手。
- 压测前必须改用生产启动方式：
go run main.go或构建二进制后运行，跳过kratos run的 wrapper 层 - 确认
config.yaml中关闭非必要组件：tracing: { sampler: { type: "const", param: 0 } }（关掉 trace）、logger: { level: "warn" } - HTTP transport 默认用
net/http，若需更高吞吐，得手动替换为fasthttp实现（Kratos 支持 transport 替换，但不内置）
gRPC vs HTTP transport 压测差异远超预期
同一 Kratos 服务，仅切换 transport 协议，QPS 和 P99 延迟可能差 3 倍以上——这不是框架问题，而是协议层成本差异。
- gRPC（基于 HTTP/2 + Protobuf）在高并发下更省连接、复用帧、压缩高效，适合内部服务间通信；压测时注意客户端要复用
grpc.ClientConn，否则建连开销会淹没真实处理能力 - HTTP（JSON over HTTP/1.1）调试友好但序列化/反序列化开销大，P99 容易被 GC 拖累；若必须压 HTTP，建议把
encoding/json换成json-iterator/go，实测降低 15%~20% 反序列化延迟 - Kratos 的
transport/http和transport/grpc是并行实现，不共享中间件栈——比如你加了recoverymiddleware 到 HTTP transport，gRPC transport 不会自动生效
proto 定义不当会直接拖垮压测数据
Kratos 强依赖 Protobuf IDL，但很多人只把它当“接口声明”，忽略了它对序列化性能和内存分配的实际影响。
- 避免在 message 中嵌套过深或使用 repeated 字段存大量数据，Protobuf 解析是递归+反射开销，深度 >5 层时 P99 明显上扬
- string 字段未加
(validate.rules).string.min_len等约束，会导致运行时校验走通用反射路径，比预编译校验慢 3~5 倍 - 错误码定义别滥用
enum：Kratos 生成的错误码判定逻辑会为每个 enum 值生成 switch case，枚举项超 20 个后，errors.Is()调用延迟上升明显
对比压测时最容易忽略的控制变量
拿 Kratos 和 go-zero、sponge 做横向对比，如果没统一这些，数据毫无参考价值。
- 所有框架都禁用 trace/metrics/exporter，只留基础 metrics（如 Prometheus 的
http_request_duration_seconds）用于采集，否则 sidecar 或 exporter 自身就成瓶颈 - 客户端必须用同一种压测工具（推荐
k6），且脚本里禁用默认的 cookie jar、禁用 TLS 证书验证（tlsAuth: { insecureSkipVerify: true }），否则网络层干扰太大 - 服务端部署环境一致：同一台机器、相同 GOMAXPROCS、关闭 CPU 频率调节（
echo performance | sudo tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor）
真正卡住 Kratos 性能的，往往不是框架本身，而是 transport 层选型、proto 编写习惯、以及压测时没意识到那些“默认开启”的可观测性组件正在后台疯狂分配内存。压测不是比谁框架名字响，而是比谁先把干扰项清干净。
