京公网安备11010502063487号本机3节点集群里开一个事务写3条消息先不提交，验证read_uncommitted立刻读到、read_committed读到0条；提交后read_committed追上来；中止的事务里read_uncommitted瞬间看到过，但read_committed永远看不到。
验证一个读—处理—写循环把输出produce和offset提交塞进同一个事务，模拟处理完但崩溃在提交之前，重试后committed offset和输出内容验证只留下一份结果，没有重复。
用sqlite对比naive双写(DB提交后单独发Kafka，崩溃后事件永久丢失)和outbox模式(订单和待发事件同一事务提交，relay崩溃重试后消息重复但不丢)。
对同一条消息构造三种真实消费方式，验证at-most-once丢失、at-least-once重复、exactly-once物理重试但最终只确认一次的具体差异。
3分区topic用3个key各发10条消息，验证同key消息哈希到同一分区且分区内严格有序，但consumer的跨分区全局到达顺序不等于发送顺序。
直接dump __cluster_metadata内部topic的原始日志，看broker注册、topic创建、故障切换如何变成REGISTER_BROKER_RECORD/TOPIC_RECORD/PARTITION_CHANGE_RECORD等具体记录。
检查本机Kafka 4.3.1安装目录，确认ZooKeeper相关脚本和配置已完全不存在，用老式zookeeper.connect配置启动直接报错缺少process.roles。
kill掉3节点KRaft集群当前的controller quorum leader，验证剩下2/3投票节点完成重新选举，且集群操作在此期间完全未受影响。
客户端只在bootstrap.servers配置一个broker，验证它能学到完整的集群broker列表和分区leader映射，并成功把消息发送到配置里从未出现过的broker。
创建6分区3副本topic观察初始leader的round-robin分布规律，kill一个broker后验证只有受影响的分区换了leader。
kill掉一个同时兼任controller leader和数据分区leader的broker，测量三种操作(受影响分区/无关分区/创建新topic)真实的端到端恢复耗时，都约11秒，对应broker.session.timeout.ms默认9秒。
真实给3节点集群加入第4个broker，验证已有topic完全不受影响，只有新建topic才会用到它；再kill掉它，验证Replicas列表不会自动清理死亡broker id。