message.max.bytes=5242880 replica.fetch.max.bytes=5242880 kafka-configs.sh --bootstrap-server 127.0.0.1:9092 --alter \ --entity-type topics --entity-name order-event \ --add-config max.message.bytes=5242880
生产端报 RecordTooLargeException: The message is 1523412 bytes when serialized which is larger than 1048576。先别急着动参数，把报错原文和时间点记下来，顺序反了容易白折腾。
原因不复杂，单条消息超过了 topic 的 max.message.bytes 或者 broker 的 message.max.bytes，两级里任何一处拦下都会拒收，只改一边没有用。
围绕「Kafka 消息过大」排查时，命令行跑一遍比在面板里点十次有用，面板会替你做掉不少隐式操作。动手前把原文件复制一份带时间戳，出问题立刻换回去，比现场分析快得多。
一次只改一处，改完立刻验证，几个改动叠在一起，出问题就说不清是谁导致的。先做最小复现，能稳定跑出来的问题，排查成本会低一个数量级。
别只看报错的最后一行，往上看几行，真正的起因通常在上面。
处理上按这个顺序：先量出序列化之后的真实字节数 别拿字符串长度估；broker 和 topic 两级的消息上限要一起调大 缺一个仍然被拦；超过 1MB 的消息改成先存对象存储 消息体里只传地址。
改完只确认一件事：同一条消息重新发送成功，消费端反序列化出来的字段完整没有截断。