zookeeper_init 返回 NULL 主因是 host 字符串含 zookeeper:// 前缀或 watcher 回调签名错误（须为 void watcher(zhandle_t, int, int, const char, void*)），且 host 必须是生命周期可控的 C 风格字符串。
zookeeper_init 为什么总是返回 NULL？
zookeeper_init 返回 NULL 通常不是 ZooKeeper 服务不可达，而是传入的 host 字符串格式错误或回调函数未正确声明。C API 要求 host 必须是 "127.0.0.1:2181" 这种纯字符串，不能带 zookeeper:// 前缀；回调函数签名必须严格为 void watcher(zhandle_t<em>, int, int, const char</em>, void*)，少一个参数或类型不匹配都会导致初始化失败（尤其在 C++ 中容易因隐式 this 指针误传而崩溃）。
- 确保
host是 C 风格字符串（const char*），不是std::string直接取c_str()后未保证生命周期 - watcher 回调必须是全局函数或 static 成员函数；若用 class 成员，需通过
void*传this，并在回调内强转 - 初始化后立即检查
zoo_state(zh)是否为ZOO_CONNECTING_STATE，而不是只看指针是否为空
如何安全地注册临时节点（Ephemeral Node）并避免重复注册？
ZooKeeper 的临时节点依赖会话存活，但 zoo_create 不是原子性幂等操作：如果网络抖动导致请求已成功但响应丢失，重试会报 ZNODEEXISTS 错误。不能靠捕获异常（C API 无异常），必须主动检查节点是否存在。
- 先用
zoo_exists检查路径，仅当返回ZNONODE时才调用zoo_create - 创建时 flag 必须含
ZOO_EPHEMERAL，且路径末尾不能有斜杠（/services/app-001/❌，应为/services/app-001✅） - 数据部分建议写入 JSON 或二进制序列化后的 IP:PORT + 启动时间戳，便于发现端解析和超时判断
- 不要复用同一 zhandle_t 多次注册不同路径——每个服务实例应独占一个连接，否则会话中断影响全部注册
watcher 回调里能直接调 zoo_get_children 吗？
不能。C API 的所有 zoo_* 函数都不是线程安全的，且 watcher 回调本身运行在 zookeeper 库的内部线程中。在回调里直接调 zoo_get_children 可能触发死锁或段错误，因为底层可能正在处理同一连接的其他异步响应。
- watcher 回调只做最轻量的事：记录事件类型（
ZOO_CHILD_EVENT）、设置标志位、或往线程安全队列（如std::queue+ mutex）投递任务 - 真正的
zoo_get_children必须在你自己的工作线程中调用，并确保该线程使用同一个zhandle_t - 注意
zoo_set_watcher的默认行为是「单次触发」，每次zoo_get_children后需重新设置 watcher 才能持续监听子节点变化
服务发现时 zoo_get_children 返回的数据怎么解析才可靠？
zoo_get_children 返回的是 struct String_vector，其中 data 是 char** 数组，每个元素是子节点名（不含父路径）。常见错误是直接 printf("%s", strings.data[0]) 而忽略 strings.count 边界，或把节点名当完整路径拼接。
立即学习“C++免费学习笔记（深入）”；
- 必须先检查
strings.count > 0，再遍历；循环上限严格为strings.count，不能用while(*p) - 子节点名只是相对名（如
"app-1"），拼接完整路径要用snprintf(buf, sizeof(buf), "%s/%s", base_path, strings.data[i]) - 若需获取每个实例的元数据，必须对每个子节点再调一次
zoo_get；不要试图从节点名里硬编码解析 IP/PORT，那是反模式
ZooKeeper C API 的坑主要在生命周期管理与线程模型上：zhandle_t 不是线程安全句柄，watcher 不是事件循环入口，临时节点不等于服务健康。真正稳定的注册发现，得靠外层封装状态机+重连逻辑+本地缓存，而不是只堆 API 调用。
