应同时设置x-max-length和x-max-length-bytes双参数，推荐3000–10000条与5–20MB，配合drop-head溢出策略，并通过Policy动态配置，最后用rabbitmqctl验证运行时状态。
限制单个队列的最大消息容量，核心是同时控制“消息条数”和“总字节数”，不能只设一个。
必须双参数协同设置
只设 x-max-length（如 5000 条）容易在大消息场景失控：一条 2MB 的消息占满 10MB 限额，但条数才 5 条；只设 x-max-length-bytes（如 10MB）又可能让上万条小消息挤爆元数据内存。生产环境应两者都配：
- x-max-length：建议设 3000–10000，防高并发小消息撑爆连接与索引
- x-max-length-bytes：建议设 5–20MB（如 10485760），防单条大消息拖垮内存
- 任一条件触发即执行溢出策略，真正兼顾“量”与“体积”
溢出策略选 drop-head，别用 reject-publish
默认 drop-head 是最稳妥的选择：
- 自动删最老消息，为新消息腾空间，动作原子、无反馈依赖
- 不阻塞生产者，也不引发重发风暴
- 天然保留最新业务状态（比如实时指标、用户最近操作）
- 注意：它只作用于 ready 状态的消息，unack 消息不受影响
优先用 Policy 动态管理，别硬编码
在代码里写死参数会导致上线后无法调优。推荐用命令行统一配置策略：
- 命令示例：rabbitmqctl set_policy max_len "^(?!amq\.gen).*" '{"max-length":5000,"max-length-bytes":10485760}' --apply-to queues
- 正则避开临时队列（amq.gen.*），只作用于业务队列
- 字段名用 max-length（无 x-前缀），和管理界面一致
- 策略优先级高于客户端声明，运维可随时调整，应用无需重启
验证是否真生效，不能只看声明
队列声明成功 ≠ 限制起作用。必须检查运行时状态：
- 执行：rabbitmqctl list_queues name messages_ready message_bytes_ready
- 观察 messages_ready 是否稳定在设定值附近，突增后回落说明 drop-head 已触发
- Web 管理界面看不到溢出策略，也填不了具体数值，仅作辅助参考
