dbus-c++因维护停滞、abi兼容性差、无超时控制且高并发性能低，生产环境应优先选用稳定、功能完备的原生libdbus。
怎么用 dbus-c++ 发送一个简单方法调用
直接用 dbus-c++（即 libdbus-c++）发请求，核心是拿到远程对象的代理（proxy），再调用其方法。它底层封装了原始 libdbus 的繁琐流程，但前提是 D-Bus 服务已启动且接口定义正确。
常见错误现象：DBus::FatalException 抛出、org.freedesktop.DBus.Error.ServiceUnknown、或调用后无响应——基本都是 bus 连接没通、服务名没注册、或路径/接口名写错。
- 确保服务端已运行，并在系统总线（
system）或会话总线（session）上正确注册：用busctl --system list-names | grep your.service.name或dbus-send --session --dest=org.freedesktop.DBus /org/freedesktop/DBus org.freedesktop.DBus.ListNames验证 - 客户端连接必须匹配服务端使用的 bus 类型：
DBus::Connection conn = DBus::Connection::SessionBus()或::SystemBus() - 代理构造时三个参数缺一不可：
conn.request_name("your.service.name")不是必须的（客户端不用占名），但conn.create_interface("your.service.name", "/object/path", "interface.name")中的服务名、路径、接口名必须和Introspect输出完全一致（大小写敏感，含点号） - 方法调用前建议先检查接口是否可用：
if (iface->is_valid()) { ... }，否则直接调用会 crash
dbus-c++ 和原生 libdbus 哪个更稳
dbus-c++ 封装层薄、API 简洁，但长期维护停滞（最后更新在 2014 年左右），在较新 glibc 或 systemd 版本下容易因 ABI 变更或线程模型不兼容而 segfault；而原生 libdbus 虽然写法啰嗦，但稳定、文档全、发行版默认带，且支持异步模式和完整错误码映射。
使用场景：小工具、原型验证可用 dbus-c++；生产环境、需处理超时/重连/权限失败等边界情况，务必切回 libdbus。
-
dbus-c++不支持DBUS_TIMEOUT_USE_DEFAULT以外的超时控制，调用卡住只能 kill 进程 - 它的信号监听依赖轮询（
conn.dispatch()），没做 epoll/kqueue 适配，在高并发 IPC 场景下 CPU 占用明显偏高 - 某些发行版（如 Ubuntu 22.04+）已移除
libdbus-c++包，需手动编译，且与dbus-1.14+链接时可能报undefined reference to dbus_connection_set_watch_functions
如何用 libdbus 同步调用一个方法并读返回值
同步调用本质是发消息 + 阻塞等回复。关键不是“怎么发”，而是“怎么安全收”：必须检查消息类型、序列号、错误字段，不能假设 reply 一定成功。
示例中省略了内存释放和错误跳转，但实际代码里每一步 dbus_pending_call_block() 或 dbus_message_iter_get_arg_type() 后都应判断返回值。
DBusMessage *msg = dbus_message_new_method_call(
"org.example.MyService", // service name
"/org/example/MyObject", // object path
"org.example.MyInterface", // interface
"GetValue" // method name
);
DBusMessageIter iter;
dbus_message_iter_init_append(msg, &iter);
dbus_message_iter_append_basic(&iter, DBUS_TYPE_INT32, &input_val);
DBusMessage *reply = dbus_connection_send_with_reply_and_block(
conn, msg, DBUS_TIMEOUT_USE_DEFAULT, &err
);
if (dbus_set_error_from_message(&err, reply)) {
fprintf(stderr, "D-Bus error: %s\n", err.message);
dbus_error_free(&err);
} else if (reply) {
dbus_message_iter_init(reply, &iter);
int result;
if (dbus_message_iter_get_arg_type(&iter) == DBUS_TYPE_INT32) {
dbus_message_iter_get_basic(&iter, &result);
}
}
dbus_message_unref(msg);
if (reply) dbus_message_unref(reply);
- 别漏掉
dbus_error_init(&err)，否则未初始化的err可能导致段错误 -
dbus_connection_send_with_reply_and_block()在 dbus 1.12+ 默认启用DBUS_TIMEOUT_USE_DEFAULT（约 25s），但若服务端 hang 住，整个线程就卡死——生产中必须设明确 timeout（毫秒） - 返回值类型必须严格匹配接口定义，
dbus_message_iter_get_arg_type()返回DBUS_TYPE_INVALID很可能是服务端没填 reply 或类型写错
为什么 dbus-send 能通，C++ 程序却连不上
最常被忽略的是 bus 类型和地址不一致。dbus-send 默认走会话总线，但 C++ 代码如果硬编码了 dbus_bus_get(DBUS_BUS_SYSTEM, &err)，而服务只在 session 注册，自然连不上；反之亦然。
另一个高频坑是 SELinux 或 systemd user session 权限限制：普通用户进程无法访问 session bus 的某些服务，除非服务配置了 AllowSendMessages 规则。
- 查当前程序看到的 bus 地址：
echo $DBUS_SESSION_BUS_ADDRESS，然后在 C++ 里用dbus_connection_open()显式连接该地址，而非依赖dbus_bus_get() - 用
dbus-monitor --session "type='method_call',interface='org.example.MyInterface'"抓包，确认你的程序是否真的发出了消息（有时 connect 成功但 send 失败静默丢弃） - 服务端若用
gdbus或sd-bus实现，注意它们默认不兼容老式libdbus的线程模型——需在服务端显式调用dbus_connection_set_exit_on_disconnect(conn, FALSE)
真正麻烦的从来不是“怎么调通一次”，而是“怎么让调用在服务重启、总线重载、权限变更后依然可靠”。这些细节不写进日志、不加断言、不跑压测，上线后第一周就出问题。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
