brpc 初始化不强制调用brpc::StartDummyServer()，但不调用会导致首次RPC延迟升高且内置服务不可用；推荐在main()开头调用以避免懒启动毛刺。
brpc 初始化必须调用 brpc::StartDummyServer() 吗？
不是必须，但不调用会导致首次 RPC 调用延迟明显升高，且某些内置服务（如 /status、/vars）无法访问。brpc 内部依赖一个“dummy server”来初始化线程池、计时器和网络栈，它在第一次真正使用 RPC 时懒启动，带来不可控的首请求毛刺。
- 推荐在
main()开头就调用brpc::StartDummyServer()，哪怕只是占位 - 若明确不需要 HTTP 管理接口，可改用
brpc::Initialize(&argc, &argv, nullptr, nullptr, 0)并传入空配置，跳过 dummy server 启动 - 注意：调用
brpc::StartDummyServer()后，brpc::Initialize()不能再重复调用，否则 panic 报错"Already initialized"
定义服务接口时，google::protobuf::Service 和 brpc::Server 怎么配对？
brpc 不要求你手写 stub 或继承特定基类；它靠 Protocol Buffer 的 Service 描述自动生成通信逻辑。关键在于：你的 .proto 文件里定义的 service 必须被注册到 brpc::Server 实例上，且实现类要继承 google::protobuf::Service 或用 brpc::ServiceAdaptor 包装。
- 最简方式：让实现类继承
xxx::YourService（protoc 生成的基类），然后重写CallMethod()，再用server.RegisterService()注册 - 更现代写法：用
brpc::ServiceAdaptor<yourserviceimpl></yourserviceimpl>自动桥接，避免手动处理Controller和Done - 别漏掉
.proto编译时加--cpp_out和--brpc_out（后者需 brpc 提供的插件），否则缺少XXX_Stub和 service 注册辅助函数
客户端发请求卡住或超时，controller->ErrorCode() 返回 114 是什么问题？
114 对应 brpc::ERPCTIMEDOUT，但根源常不在网络——多数是服务端未正确设置响应或回调未触发完成。brpc 客户端默认同步等待，如果服务端 handler 里没调用 done->Run()（或没用 RAII 封装的 brpc::ClosureGuard），请求就永远挂起。
- 检查服务端 handler 是否遗漏
done->Run()，尤其在异常分支或 early-return 场景下 - 确认是否误用了异步风格写法（比如在 handler 里开新线程处理，却没把
done捕获进去） - 客户端可临时加日志：
LOG(INFO) log_id() timeout_ms();，配合服务端/bvar/查看连接数、pending 请求量 - 注意：
cntl->Failed()为 true 时才该读cntl->ErrorText()，否则ErrorCode()可能是未定义值
如何让 brpc 服务支持 TLS / HTTPS？
brpc 原生支持 SSL/TLS，但不走标准 HTTPS 协议栈（即不解析 HTTP 头），而是基于 bRPC 自定义协议封装加密。这意味着你不能直接用浏览器访问，但可以用 brpc 客户端或 curl（带 --http1.1 + SNI）测试。
立即学习“C++免费学习笔记（深入）”；
- 服务端启用 TLS：构造
brpc::SSLOptions，填入cert、private_key、verify_mode，再传给server.Start(..., &options) - 客户端需匹配：创建
brpc::Channel时传入相同证书路径，或设ssl_options.verify_mode = ssl_verify_none（仅测试） - 常见坑：
private_key文件权限必须是 600，否则 brpc 初始化失败并静默退出；证书链不全会导致握手失败，错误码常为108 (ECONNREFUSED)或112 (EPROTO) - 不建议混用 HTTP/HTTPS 端口：brpc 的 TLS 是协议层加密，不是 HTTP over TLS，强行套 nginx 反向代理可能破坏帧格式
done->Run() 的调用时机，以及 TLS 下证书路径和权限的组合校验。这些点不踩一遍，很难凭文档猜出来。 
