直接用 Faker().name() 循环百万次会卡死，因默认实例每次调用有轻量级开销，叠加后解释器、字符串拼接、locale 切换等拖慢；应单例初始化、显式设 locale、禁用无关 provider、固定 seed。
为什么直接用 Faker().name() 循环百万次会卡死？
因为默认的 Faker 实例每次调用都做轻量级随机计算，但百万次调用叠加后，Python 解释器开销、字符串拼接、内部 locale 切换（尤其启用了多语言）会明显拖慢。更关键的是，如果没禁用 seed 或重复初始化实例，生成的数据可能意外重复或分布不均。
- 避免在循环里反复创建
Faker()实例——只初始化一次 - 显式设置
locale='en_US'（或你实际需要的语言），否则默认加载全部 locale，内存暴涨 - 关闭不需要的提供器（provider），比如不用地址就别加
faker.address()，减少内部方法注册开销 - 用
fake.seed_instance(42)固定种子，方便复现和比对，但正式压测时建议去掉或轮换
如何让 insert_many 不因单条 SQL 崩溃？
直接把百万个 dict 丢给 cursor.executemany() 或 ORM 的 bulk_create，常触发内存溢出或数据库连接超时。根本问题不在 Faker，而在批量写入策略没分片。
- 按 5000–10000 条为一批调用
executemany()，太大易 OOM，太小 IO 次数太多 - 确保数据库连接未设
autocommit=False且事务未嵌套——否则每批都在积累锁和 WAL 日志 - PostgreSQL 用户注意：
INSERT ... VALUES (...), (...), ...比逐行INSERT快 5–10 倍，可用psycopg2.extras.execute_batch()替代原生executemany - SQLite 用户必须先执行
PRAGMA journal_mode = WAL和PRAGMA synchronous = OFF（仅测试环境！）
字段类型不匹配导致 IntegrityError: NOT NULL constraint failed 怎么查？
不是 Faker 生成了空值，而是你映射字段时漏写了非空字段的生成逻辑，或者数据库 schema 里某列定义了 NOT NULL 但 Faker 没覆盖到（比如 fake.pystr(max_chars=10) 可能返回空字符串）。
- 对必填字段，强制指定生成方式：
'email': fake.email(), 'age': fake.pyint(min_value=18, max_value=99) - 用
fake.pybool()代替手动写random.choice([True, False])，前者更稳定 - 日期字段慎用
fake.date_this_decade()——它可能生成未来日期，而某些数据库字段类型（如DATE）虽接受，但业务逻辑校验会失败 - 检查 ORM 模型中
blank=True/null=True是否与数据库实际约束一致，Django 用户尤其注意迁移后是否真正生效
生成速度上不去？试试 fake.profile() + 字段裁剪
fake.profile() 一次性返回包含 15+ 字段的 dict，比挨个调用 fake.name()、fake.email() 快 3–4 倍，因为它复用了内部随机状态和缓存。但你通常只需要其中 5–6 个字段，直接取子集即可。
立即学习“Python免费学习笔记（深入）”；
- 先调用
profile = fake.profile()，再用字典推导式提取：{k: v for k, v in profile.items() if k in ['name', 'email', 'job', 'address']} - 若需自定义字段（如添加
user_id自增整数），用itertools.count()配合生成器，避免在循环里做i += 1 - CPU 成瓶颈时，可考虑用
multiprocessing.Pool分批生成数据（注意Faker实例不能跨进程共享，每个 worker 需独立初始化）
真正卡住的往往不是 Faker 本身，而是你没关掉数据库日志、没调批次大小、或字段映射漏了空值兜底。跑前先用 1000 条验证全流程，比盲目冲百万条更容易发现问题。
