合理设置队列长度限制需同时配置x-max-length和x-max-length-bytes，并采用drop-head溢出策略，通过Policy统一管控并验证运行时状态。
合理设置队列长度限制是防止 RabbitMQ 内存雪崩的关键防线。它不靠“等内存快爆了再反应”，而是主动给队列划边界，让消息堆积有上限、有策略、可预期。
只限制数量或字节数都不够，要双管齐下
单靠 x-max-length（消息条数）容易在大消息场景失效：比如每条消息 1MB，设了 1000 条，实际占 1GB 内存；单靠 x-max-length-bytes（总字节数）又可能在小消息场景下放行过多条数，加剧连接与索引开销。生产环境建议同时设置：
- x-max-length 控制消息条数上限（如 5000），防高并发小消息撑爆句柄和元数据
- x-max-length-bytes 控制总内存占用（如 10485760 = 10MB），防单条大消息拖垮内存
- 两者任一触发即执行溢出策略，真正兼顾“量”与“体积”
溢出策略必须选 drop-head，别用 reject-publish
reject-publish 要求开启 publisher confirms，且生产者收到 nack 后需自行重试或丢弃——这反而可能引发重发风暴，加重堆积。而 drop-head（默认）直接移除最旧消息，动作原子、无反馈依赖、不阻塞新消息写入，更适合防雪崩：
- 消费者慢但没挂时，ready 消息少，unack 消息多——长度限制只统计 ready 消息，不会误删
- 队列满后自动“滚动更新”，天然保留最新业务状态（如监控指标、用户行为）
- 无需改造生产者逻辑，零侵入落地
必须用策略（Policy）统一管控，别硬编码到客户端
代码里写死 x-max-length 会导致上线后无法动态调优，一旦出问题只能改代码、发版本、重启服务——雪崩时根本来不及。推荐用 rabbitmqctl set_policy 全局生效：
立即学习“Java免费学习笔记（深入）”；
- 命令示例：
rabbitmqctl set_policy max_len "^(?!amq\.gen).*" '{"max-length":5000,"max-length-bytes":10485760}' --apply-to queues - 正则避开
amq.gen.*临时队列，只作用于业务队列 - 字段名用
max-length（无 x-前缀），和 UI/策略系统保持一致 - 策略优先级高于客户端参数，运维可随时调整，不影响应用运行
验证是否生效，不能只看声明参数
队列声明成功 ≠ 长度限制真起作用。必须检查运行时状态：
- 用命令
rabbitmqctl list_queues name messages_ready message_bytes_ready查看实际 ready 消息数和字节数 - 观察
messages_ready是否稳定在设定值附近，突增后回落说明 drop-head 生效 - Web 界面看不到溢出策略，也填不了
x-overflow，仅作辅助，关键靠命令行验证
