Kafka在Django中需独立于Web生命周期运行：生产者须flush或get确认，消费者须手动commit偏移、用外部进程托管，禁用信号同步调用，序列化统一用UTF-8 JSON，避免与ORM混用。
Kafka 在 Django 中不是“开箱即用”的组件，它不参与请求响应周期，也不该被塞进 views.py 或模型方法里同步调用。真正能落地的消息驱动架构，核心是：**生产者发得稳、消费者跑得久、偏移提交得准、错误不丢数据**。下面直奔实操要点。
怎么配 KAFKA_CONFIG 才不踩偏移重置坑
很多人一上来就设 'auto.offset.reset': 'latest'，结果消费者启动后收不到历史消息，以为“没连上”，其实是 Kafka 默认跳过了所有已存在消息。
-
'auto.offset.reset': 'earliest'是开发/重放场景的底线配置，确保从头消费；上线后若需跳过积压，再切为'latest' -
'group.id'必须全局唯一且稳定——改名会导致 Kafka 认为是新组，重新从auto.offset.reset位置开始读 - 别漏掉
'enable.auto.commit': False：默认自动提交会掩盖处理失败，应改为手动consumer.commit()，只在业务逻辑成功后才提交偏移 - 如果用
confluent-kafka（推荐），'bootstrap.servers'支持逗号分隔多个地址，比如'localhost:9092,localhost:9093'，比kafka-python更健壮
KafkaProducer 发消息时为什么总丢数据
常见现象是调用 producer.send() 后进程退出，但消息根本没到 broker。这是因为 send() 是异步的，返回的是 Future 对象，不是发送完成信号。
- 必须显式调用
producer.flush()（例如在 Django 命令或管理命令结尾），否则缓冲区消息可能丢失 - 不要在 HTTP 请求中直接
send()后就返回响应——万一网络抖动或 broker 拒绝，你完全不知道；应搭配future.get(timeout=5)等待确认，或记录失败日志并走补偿 - 序列化别用
str(obj).encode()：中文乱码、嵌套字典转义错乱；统一用json.dumps(obj, ensure_ascii=False).encode('utf-8') - 大消息（>1MB）要调大 broker 的
message.max.bytes和客户端的max_request_size，否则静默失败
消费者进程怎么长期存活又不重复消费
Django 本身没有“后台常驻进程”机制。把消费者写成 management command 并用 systemd 或 supervisord 托管是最轻量可靠的做法，而不是扔进 ready() 或信号里。
Claw Code Suite (Python-Only Edition)
下载
仅使用 Python 将 Claw Code 虚拟化框架与 OpenClaw 集成，提供 184 种工具和 200 多条命令，用于安全分析和代码质量...
- 消费者循环里必须有异常捕获：网络断开、broker 不可用、反序列化失败都会导致
poll()报错甚至崩溃，没 try-except 就会退出 - 收到消息后，先做业务处理（如更新 DB），**成功后再调用
consumer.commit(message)**；否则重启后会重复处理同一消息 - 别用
while True:+time.sleep(1)轮询——浪费 CPU；consumer.poll(timeout_ms=1000)是阻塞等待，更省资源 - 一个 topic 多个分区时，同一个 group 内消费者数不能超过分区数，否则多出的消费者会空闲；可通过
kafka-topics.sh --describe查分区数
什么时候该用 Django 信号 vs 直接调 KafkaProducer
信号（如 post_save）看起来“自动”，但它是同步执行、共享主线程、无法 retry、难以监控——仅适合低频、非关键、可丢失的旁路通知（比如发个站内信）。
立即学习“Python免费学习笔记（深入）”；
- 关键业务事件（下单、支付成功、库存扣减）必须绕过信号，直接在视图或 service 层调用
producer.send()，并设计幂等性（如用订单 ID 当key） - 如果硬要用信号，接收器函数里必须加
weak=False，否则模块重载后信号自动失效；还要用dispatch_uid防止多次注册 - 信号里发 Kafka 消息，等于把异步通道塞进同步流程，一旦 Kafka 不可用，整个 HTTP 请求就会卡住超时——这不是解耦，是埋雷
