很多毕业设计会把发邮件、生成报表、AI 推理等耗时操作直接放在请求线程里，导致接口响应慢、失败难恢复。消息队列提供异步解耦：生产者写事件，消费者按节奏处理。它适合不需要同步返回结果的场景，如注册后发通知、上传后转码、提交后触发分析。但若业务简单、并发低，直接调用或定时任务可能更合适。引入前先判断是否真需要缓冲、解耦或削峰。
典型场景有一两个即可。订单超时未支付自动取消，可用延迟消息或定时扫描；用户行为日志异步落库，避免拖慢主流程；文件转码、报表生成交给后台消费者；AI 请求排队处理，防止接口被长时间占用。毕业设计不必把所有模块都改成消息驱动，每个场景要能说清“为什么异步比同步好”，否则容易变成为了技术而技术，答辩时也难解释价值。
选型可从学习成本、部署资源、资料丰富度和论文可描述性考虑。RabbitMQ 路由灵活，适合中等消息量；Kafka 适合日志流和高吞吐，但概念较多；Redis Stream 轻量，适合已有 Redis 的项目；RocketMQ 在事务消息方面有特点。毕业设计通常单机部署，用 Docker 启动一个 broker 即可，不必追求集群。论文中要写选型依据和局限，而不是只写“使用了某中间件”。
可靠性要回答：消息会不会丢、会不会重复、顺序是否重要、积压怎么办。生产者可开启确认并处理失败重试；broker 设置持久化；消费者用手动确认，避免失败却已 ack。重复消费难以完全避免，消费者应设计幂等，如业务唯一键去重或状态机判断。多次失败的消息转入死信队列并记录原因。顺序消息只在必要业务使用，并理解分区或队列对顺序的影响。