bulk_create()是Django批量插入首选，性能远超单条save()，但不触发save逻辑、信号及自动字段填充；需手动处理主键、外键映射、auto_now_add字段，并分批提交防内存溢出。
bulk_create() 是批量插入的首选，但要注意主键和信号问题
Django 的 bulk_create() 是处理大批量数据插入最直接的方式，性能远超单条 save()。但它默认不触发模型的 save() 方法、不执行自定义逻辑（比如字段自动填充）、也不触发 Django 信号（pre_save/post_save）。如果你依赖这些机制，得提前绕开或手动补全。
常见错误是传入含主键值的实例后仍期望数据库自增——Django 不会忽略你给的 id 字段，除非显式设 ignore_conflicts=True（仅 PostgreSQL/SQLite 支持）或改用 update_conflicts（Django 4.2+）。Django 3.2 不支持后者。
- 一次最多插入约 1000–5000 条较稳妥（受数据库 max_allowed_packet、事务大小限制）
- 确保所有实例已设置好非空字段，
bulk_create()不做字段校验 - 若模型有
auto_now_add字段，需手动赋值，它不会自动填充
如何避免内存爆掉？分批 + 无状态构造实例
从 CSV 或 API 流式读取几十万行时，别一次性构建全部 Model() 实例再调 bulk_create()——Python 进程内存会陡增。正确做法是边读边建实例、达到批次阈值就提交，然后清空列表。
示例关键片段：
立即学习“Python免费学习笔记（深入）”；
objs = []
for row in large_dataset:
objs.append(MyModel(
name=row['name'],
created_at=row.get('created_at') or timezone.now(), # auto_now_add 手动补
))
if len(objs) >= 1000:
MyModel.objects.bulk_create(objs)
objs.clear() # 必须清空，否则重复插入
注意：objs.clear() 比 objs = [] 更安全，避免引用残留；如果中间有异常，记得加 try/except 并重置 objs。
让 macOS 自动化像说话一样简单 —— 用代码控制你的 Mac，无需学习 AppleScript 系统要求 macOS 14+ (Sonoma) Python 3.9+ 需要开启：辅助功能 + 屏幕录制权限
外键字段怎么填？先查 ID 映射表，别现场 get()
批量插入时若涉及外键（如 user_id），绝不能在循环里对每个对象调 User.objects.get(username=...)——这会产生 N+1 查询，速度断崖式下跌。
正确做法：预先提取所有关联值，一次性查出 ID 映射字典：
usernames = {row['username'] for row in data_rows}
user_map = {u.username: u.id for u in User.objects.filter(username__in=usernames)}
# 然后构造实例时直接用 user_map[row['username']]
如果外键目标不存在，bulk_create() 会直接报 IntegrityError。建议提前用 filter().values_list('username', flat=True) 校验缺失项，而不是靠异常兜底。
MySQL 下 bulk_create() 有时很慢？检查是否启用了 autocommit
Django 默认使用事务包裹 bulk_create()，但在 MySQL 中，如果连接处于 autocommit=False 状态且没显式事务控制，可能意外导致每批都隐式开启新事务，拖慢速度。
验证方式：打开 Django 日志，看是否有大量 BEGIN/COMMIT 交替；优化手段包括：
- 确认数据库配置中
AUTOCOMMIT=True（Django 默认为 True，但某些连接池或中间件可能覆盖） - 手动用
transaction.atomic()包裹整个分批过程，减少事务开销 - MySQL 侧确认
innodb_buffer_pool_size足够，否则大批量写入会频繁刷盘
真正卡住的时候，往往不是 Django 层的问题，而是数据库连接数、锁等待或磁盘 I/O —— 先看慢查询日志和 SHOW PROCESSLIST。
