System V 消息队列需用POD结构体，首字段为long mtype且>0；msgsnd/msgrcv须设IPC_NOWAIT防阻塞，避免传std::string等非POD类型。
Linux 下用 msgget + msgsnd / msgrcv 发送接收消息
POSIX 消息队列在 Linux 上更常用，但 System V 消息队列（msgget 等）仍是 C++ 项目里最易上手的原生选择——不需要额外依赖，头文件只加 <sys/msg.h> 就行。关键不是“能不能用”，而是“怎么避免阻塞卡死”和“消息体结构怎么设计”。
常见错误是直接传 std::string 或含指针的对象，导致 msgsnd 写入乱码或崩溃；另一个坑是没检查 msgflg 参数，比如忘了加 IPC_NOWAIT，msgrcv 就会永远等下去。
- 消息缓冲区必须是 POD 类型：用
struct手动定义，第一个字段固定为long mtype（不能是int），后续字段按需排布 - 发送前确保
mtype > 0，否则msgsnd返回 -1 并设errno = EINVAL - 接收时若指定
msgtyp = 0，取队列中最早的消息；若msgtyp > 0，只取该类型；若msgtyp < 0，取 - 用完记得调
msgctl(msqid, IPC_RMID, nullptr)清理，否则队列残留（ipcs -q可查）
C++ 封装 mq_open 时为什么总返回 (mqd_t)-1
mq_open 是 POSIX 消息队列接口，返回 (mqd_t)-1 表示失败，但具体原因得看 errno。最常踩的三个坑：路径名没加 / 前缀、O_CREAT 时漏了权限参数、或内核没启用 POSIX MQ 支持。
比如写 mq_open("myq", O_RDWR | O_CREAT) 必定失败——O_CREAT 必须配 mode（如 0644），否则 errno = EINVAL；再比如用 "myq" 而非 "/myq"，errno = ENOENT（POSIX MQ 名字必须以 / 开头，且不能有多个连续 /）。
立即学习“C++免费学习笔记（深入）”；
- 编译时加
-lrt链接librt，否则链接失败 - 检查内核是否支持：
cat /proc/sys/fs/mqueue/msg_max，值为 0 表示被禁用（需改/etc/default/grub加mq_ci=1并重启） -
struct mq_attr中mq_flags默认为 0（阻塞），设为O_NONBLOCK后mq_receive才会立即返回-1并置errno = EAGAIN
跨进程通信时消息体大小怎么控制才不丢数据
System V 消息队列默认最大消息长度是 8192 字节（可通过 /proc/sys/kernel/msgmax 查看/修改），POSIX MQ 则由 mq_attr.mq_msgsize 在 mq_open 时设定。超长消息直接被 msgsnd 或 mq_send 拒绝，返回 -1，errno = EMSGSIZE。
别指望靠分包自动重组——消息队列不保证顺序（除非严格单生产者+单消费者+不跳类型），也不合并消息。实际做法是：预估最大负载，留 128 字节余量给协议头（如版本号、校验字段），然后硬性截断或报错，而不是尝试压缩或 Base64 编码塞进去。
- System V：用
msgctl(msqid, IPC_STAT, &buf)获取当前msg_qbytes（队列总容量）和msg_lspid（最后发送 PID）辅助调试 - POSIX MQ：创建时显式设置
attr.mq_msgsize = 4096，比默认 8192 更可控；读写前用mq_getattr校验实际值 - 字符串字段务必用定长数组（如
char name[256]），不用std::string成员，避免指针悬空
为什么 msgrcv 总是返回 -1 且 errno = EIDRM
EIDRM 意味着消息队列已被删除，但你的进程还在试图接收——典型场景是：发送端先调了 msgctl(..., IPC_RMID, ...)，接收端还没来得及退出就执行 msgrcv。这不是并发 bug，而是生命周期管理缺失。
System V 队列的生命周期独立于进程：只要没被 IPC_RMID，哪怕所有进程都退出，队列仍存在（直到系统重启或手动清理）。所以 EIDRM 几乎只发生在“主动删队列后还继续收”的逻辑错误里。
- 不要在信号处理函数里删队列，
msgctl不是 async-signal-safe 函数 - 接收循环中每次调
msgrcv前，先用msgctl(msqid, IPC_STAT, &buf)检查是否仍有效（成功即未删） - 更稳妥的做法：用
atexit()注册清理函数，确保进程退出前删队列；或干脆让一个长期存活的进程负责管理队列生命周期
消息队列本身不解决序列化、心跳、重连这些事，它只是把一块内存从 A 进程搬到 B 进程。真正难的是确定哪段内存该搬、搬错了怎么发现、搬一半进程挂了怎么办——这些得靠上层协议和日志兜底，不是换套 API 就能绕开的。
