Ice RPC开发需正确使用slice2cpp（加--all和-I）、初始化Communicator（配InitializationData）、区分ice_timeout与ice_invocationTimeout、自定义类继承Ice::Object并用Ice::ObjectPtr传参。
如何用 slice2cpp 生成可用的 C++ stub/skeleton
生成代码是 Ice RPC 开发的第一道门槛，不是简单跑个命令就行。关键在路径、模块名和 include 顺序——slice2cpp 默认不递归解析依赖，如果 .ice 文件里用了 #include "common.ice"，必须显式传入 -I 指定包含路径，否则报错 error: cannot open include file 'common.ice'。
常见错误现象：生成的 XXX.h 里有未定义的类型，或编译时报 undefined reference to `IceProxy::xxx::yyy::zzz::ice_isA' —— 多半是没加 --all 参数，导致只生成客户端 proxy，没生成服务端 skeleton 和 common 类型定义。
- 务必加
--all，否则服务端无法实现接口 - 用
-I/path/to/ice/includes显式指定所有依赖目录，别依赖当前工作路径 - 生成后检查头文件是否含
#include <Ice/Ice.h>和#include <IceUtil/Shared.h>，缺一则链接失败 - 若用 CMake，需确保
find_package(Ice REQUIRED)后，把${ICE_INCLUDE_DIRS}加进target_include_directories
服务端初始化时为什么 Ice::InitializationData 必须传 communicator 的配置
Ice 不像 gRPC 那样靠 builder 链式配置，所有通信行为（超时、重试、压缩、线程模型）都绑定在 Ice::CommunicatorPtr 实例上。一旦创建完就不可变，所以初始化时漏配，后面没法补。
典型踩坑点：只写了 Ice::initialize(argc, argv)，没传 Ice::InitializationData，结果服务端监听了端口，但客户端连上来立刻断开，日志里只有 connection closed by peer —— 实际是服务端默认启用了 SSL，而客户端没配证书。
立即学习“C++免费学习笔记（深入）”；
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
- 必须显式构造
Ice::InitializationData，再设data.properties = Ice::createProperties() - 关键配置如
data.properties->setProperty("Ice.Default.Host", "0.0.0.0")和data.properties->setProperty("Ice.Default.Port", "10000")要写对，注意 port 是 string - 调试阶段建议加
data.properties->setProperty("Ice.Trace.Network", "2")，不然连不上根本看不到握手细节
客户端调用 ice_timeout() 和 ice_invocationTimeout() 的区别在哪
这两个函数名字太像，但作用域完全不同：ice_timeout() 控制单次网络读写（比如发请求包、收响应包）的 socket 级超时；ice_invocationTimeout() 是整个 RPC 调用周期（包括重试、重定向、序列化反序列化）的总耗时上限。
线上常见问题：设了 ice_timeout(500)，但服务端偶尔卡住 800ms 才返回，客户端却没超时——因为 ice_timeout 只管“最后一次 recv”，而 Ice 默认会自动重试，真正生效的是 ice_invocationTimeout。
- 生产环境必须设
ice_invocationTimeout，否则慢请求会拖垮线程池 -
ice_timeout建议设为ice_invocationTimeout / 3左右，避免单次卡死太久 - 如果服务端部署了负载均衡且支持重定向，
ice_invocationTimeout还要预留重定向开销 - 注意：这两个方法返回的是新 proxy，必须重新赋值，
proxy->ice_timeout(500)不会修改原 proxy
为什么 std::shared_ptr 传参给 Ice 接口方法常导致崩溃
Ice 的 C++ binding 对智能指针有严格要求：所有传入接口方法的自定义类（非基本类型）必须继承自 Ice::Object，且用 Ice::ObjectPtr（即 std::shared_ptr<Ice::Object> 的别名）包装。直接传 std::shared_ptr<MyClass> 会导致 RTTI 错误或析构崩溃。
最典型的错误现象：客户端调用成功，服务端收到参数后一访问成员就 segfault，gdb 显示在 MyClass::_iceWrite 里访问了野指针——因为 Ice 序列化时没走正确的虚函数表，而是按裸指针解引用了。
- 自定义类必须公有继承
Ice::Object，并实现__write/__read或用slice2cpp -G自动生成 - 传参时必须用
Ice::ObjectPtr，不能用裸指针或任意std::shared_ptr - 如果类里有
std::vector<std::shared_ptr<T>>，T 也得是 Ice::Object 子类，否则序列化失败 - 调试时可加
data.properties->setProperty("Ice.Warn.UnknownProperties", "1")，快速暴露序列化问题
