前端 Mock 假数据完整指南：30+ 字段、JSON/CSV/SQL 四种输出、身份证 Luhn 校验位为什么是真的、什么场景绝对不能用

Q: 生成的身份证 / 银行卡 / 统一社会信用代码能通过校验吗？会撞到真人吗？

会通过格式校验，撞真人概率比直觉低估高得多。本工具的校验位算法都是真的：身份证按 GB 11643 加权和 mod 11、银行卡按 Luhn、统一信用代码按 GB 32100 mod 31——它们生成出来能通过任何在线/系统校验器（含很多业务系统的"身份证号合法性校验"）。但本质是伪造：前 17 位是随机抽取地区码 + 随机生日 + 随机顺序码，完整 18 位组合是否对应真实居民完全是概率事件。身份证号空间粗算：地区码（约 3000 个）× 生日（约 50 年 × 365 天 ≈ 18000）× 顺序码（1000）≈ 5.4 × 10¹⁰ = 540 亿组合；全国实际在用 ID 约 14 亿——撞真人概率约 14/540 ≈ 2.6%，远不是"万亿分之一"那种安全级别。1 万条 Mock 数据里平均会有约 250 条跟真人 ID 重合。结论：能用于本地联调、单元测试、SQL 演示；绝对不能用于任何实名 / 风控 / 业务真实场景。

Q: JSON / JSONL / CSV / SQL INSERT 四种输出格式分别什么时候用？

JSON（数组）：前端 fetch mock、MSW 拦截、Postman 响应模板、本地 API mock 服务器——[{...}, {...}] 标准数组结构。JSONL（NDJSON，每行一条 JSON 对象）：大文件流式处理（一行一条好分批读）、灌入 Elasticsearch / BigQuery / DuckDB（这些工具原生支持 NDJSON）、日志格式模拟。CSV：Excel / WPS / Numbers 直接打开看（自带 UTF-8 BOM 中文不乱码）、数据可视化工具（Tableau / PowerBI）导入、给非技术同事看的表格组件 demo。SQL INSERT：数据库压测、迁移演练、新建表的初始数据、SQL 教学。经验：99% 的前端联调用 JSON；CSV 给同事 / 产品 demo；SQL 灌库做性能测试；JSONL 处理超大量级（10 万+）数据时才用。

Q: 自定义正则字段支持到什么程度？什么场景必须用脚本后处理？

支持 90% 常见用法：(1) 字符类 [A-Z0-9]、[a-z]、[一-龥]（汉字 Unicode 段）、[^abc] 否定类；(2) 元字符 \d（数字）、\w（字母数字下划线）、\s（空格）；(3) 量词 {n} / {n,m} / + / * / ?；(4) 字面字符 -、_、汉字、@、连字符等。不支持：分组 (...)、选择分支 a|b、反向引用 \1、前/后顾断言 (?=...)、命名组。典型应用：(a) 订单号 ORD-\d{8}；(b) 验证码 [A-Z0-9]{6}；(c) 优惠券 [A-Z]{4}-\d{4}；(d) 自定义 ID USR\d{6}。必须脚本后处理：(1) 真递增 + 复杂模板——ORD-20250524-001 / 002 / 003 这种日期前缀 + 严格递增，本工具的自增序号只支持纯递增（ORD-1001 / 1002），日期前缀混合用正则得到的是随机三位数；(2) 跨字段关联——如订单总价 = 单价 × 数量，需要导出后用脚本算；(3) 加权抽样——枚举字段虽然能调每项概率，但跨字段加权需后处理。

Q: 1 万条数据生成会卡浏览器吗？要更多怎么办？

主流电脑 1 万条 × 10 字段在 200ms 内完成，纯 JS 计算量没瓶颈。瓶颈在文本渲染——textarea 显示几 MB 文本会卡，所以页面对超过 20 万字符的输出做了截断显示（"前 20 万字符 + 省略"），但"复制全部"和"下载"按钮始终取完整内容，文件下载完整无截断。需要更多怎么办：(1) 10 万条——分 10 次生成 1 万条 → 各下载 .json/.csv 文件 → 用 cat *.json 拼接（CSV 需要去重表头行）；(2) 100 万条以上——浏览器不适合，建议本地跑 Faker.js / @faker-js/faker / Python Mimesis 脚本，能 10x 更快还能自定义；(3) 字段砍少——每条 30 字段改成 10 个核心字段，生成上限可以再翻几倍。

Q: CSV 在 Excel 打开中文乱码 / SQL INSERT 引号转义怎么处理？

CSV 已经处理乱码：下载的 CSV 文件自带 UTF-8 BOM 字节头（EF BB BF），Excel / WPS / Numbers 打开自动识别为 UTF-8，中文姓名、地址、统一信用代码都能正常显示。如果你用 Python / Node.js / cat 读文件发现开头多了个不可见字符（），那是 BOM——读取时去掉即可：Python 用 encoding="utf-8-sig"，Node 用 fs.readFileSync(f, "utf8").replace(/^/, "")。SQL INSERT 引号转义：工具按 SQL 标准对字符串值里的单引号 ' 双写转义、对反斜杠 \\ 转义、对 NULL 直接用 NULL 关键字。但：不同数据库方言略有差异——MySQL / PostgreSQL / SQLite 通吃 '，SQL Server 也支持 '，Oracle 除 ' 外还有 q 引用语法本工具未输出。生成后建议：先小批量（10 条）跑通灌库流程，再批量。

Q: 校验位是真的让生成的数据"以假乱真"——哪些用法已经接近违法？正经联调可以用吗？

接近违法的用法：(1) 真实开户 / 实名认证——伪造身份信息开银行账户 / 注册需要实名的服务（电信卡、互联网金融、平台账号）涉嫌违反《网络安全法》《反电信网络诈骗法》《刑法》第 280 条；(2) 绕过实名风控——电商、游戏、直播平台用生成的身份证号注册多账号，涉嫌违反平台协议，严重时进入诈骗罪范畴；(3) 冒名签订合同 / 业务——伪造身份信息构成欺诈；(4) 写入生产数据库当真实用户——任何外网可见的环境也算"业务数据"，需用脱敏后的真实数据。完全合法的用法：(a) 本地 / 测试环境的接口联调——后端没好前端先 Mock 顶上；(b) 单元测试 / 集成测试样本——CI 跑测试用的固定测试数据；(c) 数据库压测 / 迁移演练——准生产环境性能测试；(d) 教学演示——讲身份证校验算法、SQL 注入演示、CSV 读取教学；(e) 设计稿 / 产品 demo——Figma 拖入"看起来像真的"中文姓名；(f) 培训 / 写文章举例。正经联调放心用——本工具的定位就是这个，底栏已醒目标注"仅供测试，禁止真实业务"。

2026-05-24 · 约 8 分钟 🎲 Mock 数据生成器

后端接口还没好、前端要先做联调；数据库要做压测，需要 1 万条假数据；产品 demo 要”看起来真”的中文姓名手机号——这些场景里你都需要假数据生成器。

需求看起来简单：“生成几条假数据就行”，但写过的人都知道难点在哪：

中文姓名（不能用 John Doe 蒙混）
手机号要符合中国运营商号段
身份证号要能通过校验位算法（业务代码里到处都有”身份证合法性检查”）
银行卡号要符合 Luhn
统一社会信用代码要能通过 GB 32100
输出格式要灵活（JSON 给前端、CSV 给同事、SQL 灌库）

这篇拆开怎么造、造到什么程度算合规、什么场景绝对不能用。

30+ 字段类型一览

分组	字段	关键参数
个人	中文姓名	性别（男 / 女 / 随机）
	英文姓名	–
	手机号	运营商（移动 / 联通 / 电信 / 虚拟 / 随机）
	身份证号	性别 / 年龄段 / 省份（30+ 省级行政区）
	邮箱	–
	用户名	–
地址	省 / 市 / 区	精度（到省 / 到市 / 到区）
	完整地址	含楼栋号
	邮编	按省匹配
公司金融	公司名	–
	统一社会信用代码	–
	银行卡号	银行（工 / 建 / 农 / 中 / 交 / 招 / 中信 / 平安 / 随机）
	价格	min / max / 小数位
车辆	车牌号	省份简称
数字	整数	min / max
	小数	min / max / 小数位
	自增序号	前缀 / 起始 / 步长 / 后缀
文本	UUID v4	–
	中文段落	长度
	Lorem Ipsum	长度
	自定义正则	正则表达式
日期时间	日期	范围 / 格式（自定义）
	时间戳	范围 / 单位（秒 / 毫秒）
枚举布尔	枚举	候选项 + 权重
	布尔	true 概率
网络	IPv4 / IPv6	–
	URL / 域名	–
视觉	HEX 颜色	–
	占位图 URL	尺寸（picsum）

校验位都是真的——这是它最强但也最危险的部分

字段	校验算法	用途
身份证号	GB 11643 加权和 mod 11，映射 `1,0,X,9,8,7,6,5,4,3,2`	校验末位
银行卡号	Luhn 算法（双倍位减 9 + 求和补 10）	校验末位
统一社会信用代码	GB 32100 / mod 31 加权	校验末位
车牌号	无校验位，按省份简称 + 字母数字组合	–
手机号	仅匹配运营商号段，无校验位	–

意味着这些字段生成出来能通过：

✓ 大多数业务系统的”身份证号合法性校验”代码
✓ 银行卡号 Luhn 校验工具
✓ 国家企业信用信息公示系统的格式校验
✓ 在线身份证 / 银行卡 / 信用代码验证器

但：

✗ 不能通过公安部 / 央行 / 工商总局的真伪查询（这些查的是数据库真实记录）
✗ 不能用于实名认证（身份证号需要”号码 + 姓名”双匹配真人记录）
✗ 不能用于真实风控（业务系统会调四要素 / 五要素核身接口）

撞真人概率：远比你以为的高

很多人以为”随机生成的身份证号撞真人概率是万亿分之一”。事实：

身份证号有效组合空间：地区码（约 3000 个）× 生日（约 50 年的天数 = ~18000）× 顺序码（1000）≈ 5.4 × 10¹⁰ = 540 亿
中国人口约 14 亿
占用率约 2.6%——所以你随机生成一个 18 位身份证号，约 2.6% 概率对应真人

10000 条 Mock 数据里平均 260 条会跟真人身份证号重合。这是为什么”绝对不能用于真实业务”——你不只是造假数据，你在生产可能与真人重合的伪造证件信息。

这也是为什么本工具的底栏醒目标注”仅供测试，禁止真实业务”——不是免责声明，是合规要求。

四种输出格式选谁

1. JSON（标准数组）

[
  {
    "name": "张磊",
    "phone": "13800138000",
    "idCard": "110108199012051234",
    "balance": 1234.56
  },
  ...
]

用途：前端 fetch().then(r => r.json())、MSW（Mock Service Worker）拦截、Postman 响应模板、Vite 本地 mock 中间件。99% 的前端联调场景。

2. JSONL（NDJSON，每行一条）

{"name":"张磊","phone":"13800138000"}
{"name":"李娜","phone":"13900139000"}
{"name":"王伟","phone":"13700137000"}

用途：

大文件流式处理（一行一条，分批读不爆内存）
Elasticsearch _bulk API 灌入（要求 NDJSON）
DuckDB / BigQuery 直接 read_json 高效解析
日志格式模拟

对比 JSON 数组：1 万条以上推荐 JSONL，避免一次性读 5 MB 字符串爆内存。

3. CSV（含 UTF-8 BOM）

name,phone,idCard,balance
张磊,13800138000,110108199012051234,1234.56
李娜,13900139000,310105198805210987,5678.90

行首是 UTF-8 BOM（不可见），让 Excel / WPS / Numbers 自动识别编码——中文不乱码。

用途：

Excel / WPS / Numbers 直接双击打开
数据可视化工具（Tableau / PowerBI / Looker）导入
给设计师 / 产品的表格组件 demo（拖进 Figma）
临时分析（pandas / DuckDB read_csv）

Python 读取注意：用 encoding="utf-8-sig" 自动去 BOM，不然第一列名会变 name。

4. SQL INSERT

INSERT INTO mock (name, phone, id_card, balance) VALUES
('张磊', '13800138000', '110108199012051234', 1234.56),
('李娜', '13900139000', '310105198805210987', 5678.90);

关键特性：

字符串里的单引号自动 '' 双写转义
反斜杠 \\ 转义
NULL 用 NULL 关键字（不带引号）
表名可自定义（默认 mock，生产前必须改成不冲突的名字）

用途：

数据库压测（灌 1 万条看索引、分页、JOIN 性能）
迁移演练（验证 schema 改动）
新建表初始数据
SQL 注入教学（演示参数化查询的必要性）

方言注意：

数据库	单引号转义	兼容本工具输出
MySQL	`''` 或 `\'`	✓
PostgreSQL	`''`	✓
SQLite	`''`	✓
SQL Server	`''`	✓
Oracle	`''` 或 `q'[...]'`	✓（标准转义）

自定义正则字段：到什么程度够用

支持的语法（90% 常见用法）：

语法	例子	输出例
字符类	`[A-Z0-9]{6}`	`K3X8M2`
否定类	`[^aeiou]{3}`	`bcd`
元字符	`\d{6}`	`123456`
元字符	`\w{4}-\w{4}`	`aB1c-D2eF`
量词	`[A-Z]{2,4}`	`ABCD`（2–4 随机长度）
字面字符	`ORD-\d{6}`	`ORD-123456`
汉字范围	`[一-龥]{2,3}`	`张磊`

不支持：

(abc)              ❌ 分组
a|b                ❌ 选择
\1                 ❌ 反向引用
(?=...)            ❌ 前后顾断言
(?<name>\d+)       ❌ 命名组

典型应用：

# 订单号
ORD\d{8}              → ORD12345678

# 验证码
[A-Z0-9]{6}           → K3X8M2

# 优惠券
[A-Z]{4}-\d{4}        → ABCD-1234

# 自定义用户 ID
USR\d{6}              → USR000123

# IP 段（粗略）
192\.168\.1\.\d{1,3}  → 192.168.1.42

# 中文标签
[红黄蓝绿白黑]色       → 红色 / 蓝色 / ...

必须脚本后处理的场景：

真递增 + 复杂模板——ORD-20250524-001 / 002 / 003 需要日期前缀 + 严格递增三位数，本工具的”自增序号”字段只支持 ORD-1001 / 1002 / 1003 这种纯递增；混用正则得到的三位数是随机
跨字段关联——订单总价 = 单价 × 数量、用户年龄 = 当前年 - 出生年
加权抽样的复杂逻辑——枚举字段虽支持每项权重，但跨字段联合分布需后处理

后处理脚本示例（Node.js）：

const data = require('./mock.json');
data.forEach((row, i) => {
  row.orderNo = `ORD-20250524-${String(i + 1).padStart(3, '0')}`;
  row.totalPrice = row.unitPrice * row.quantity;
});
require('fs').writeFileSync('./mock-processed.json', JSON.stringify(data, null, 2));

性能与上限

量级	时间（M1 Mac）	文本大小	浏览器表现
100 条	<10 ms	~30 KB	流畅
1000 条	~50 ms	~300 KB	流畅
10000 条	~200 ms	~3 MB	textarea 截断到 20 万字符显示，下载完整
100000 条	不支持单次	~30 MB	建议分 10 次生成，本地 Faker 脚本更合适

瓶颈：

计算（JS）：纯算每条 < 50 μs，10 万条 ~5 秒
渲染（textarea）：3 MB 文本 DOM 操作就会卡半秒
内存：浏览器 tab 默认 ~4 GB 上限，几十 MB 文本无压力

超过 10 万条怎么办：

分批生成——10 万条分 10 次 × 1 万条，每次下载文件，最后 cat *.json | jq -s 'flatten' 拼接
本地脚本——Node 装 @faker-js/faker、Python 装 mimesis，自由度更高
专用工具——databricks dbgen、TPC-H 数据生成器（针对数据库压测）

状态持久化与跨设备

字段定义、数量、输出格式、表名自动存到当前浏览器 localStorage（key toolbox_mock-data_state）：

✓ 刷新页面、关闭浏览器再回来都还在
✗ 换浏览器、清缓存、隐私模式都会丢
✗ 不跨设备同步

重要配置怎么保留：

配置本身重要 → 截屏字段配置表
生成的数据本身重要 → 下载 JSON / CSV 文件
想换设备继续 → 暂无内置导入导出，可能后续加

合规边界：哪些用法接近违法

❌ 违法 / 严重违规

用法	法律风险
真实开户 / 实名认证（电信卡、银行账户、互联网金融）	违反《网络安全法》《刑法》第 280 条伪造身份证件罪
绕过实名风控（电商、游戏、直播、社交平台注册多账号）	违反平台协议，严重时构成诈骗罪
冒名签订合同 / 业务	欺诈罪
写入生产数据库当真实用户	任何外网可见环境都需要脱敏数据，违反《个人信息保护法》
用伪造身份信息进行任何金融、医疗、教育、政务业务	涉嫌伪造、变造身份证件罪

✅ 合法 / 推荐场景

用法	说明
本地 / 测试环境的接口联调	后端没好前端先 Mock 顶上
单元测试 / 集成测试样本	CI 跑测试的固定 fixture 数据
数据库压测 / 迁移演练	准生产环境性能测试
教学演示	讲身份证校验算法、Luhn 实现、SQL 注入演示、CSV 读取教学
设计稿 / 产品 demo	Figma 拖入”看起来真”的中文姓名
培训 / 技术文章举例	需要批量看起来合法但完全虚构的样本

灰色地带

黑盒测试供应商系统的”身份证号合法性校验”是否正确实现 → 严格说是测试行为，合法但需有授权
演示 demo 给客户看 → 内网 / 受控环境合法，公开发布到互联网建议用更虚假的占位数据（如 张三 / 13800000000）
数据科学比赛 → 看比赛规则是否允许合成数据

核心判断：只要数据不离开你的开发 / 测试环境，绝大多数用法都合法；一旦数据被当作”真实用户信息”提交给任何系统（业务、监管、外部 API），就跨过合规边界。

与相关工具配合

生成 JSON 后调试结构 → [[json]] 格式化、[[json-diff]] 对比
转 schema 校验 → [[json-to-schema]] 推断 / [[schema-validator]] 校验
测试身份证号合法性算法 → [[id-card]] 拆解 18 位含义和校验位计算
批量生成二维码当作”产品序列号”演示 → 配合 [[qrcode-batch]] 把生成的 ID 转 QR
生成 UUID + 自增序号当主键 → [[uuid-gen]] 单次生成

总结

核心心态：

假数据要**“假得像真的”**——校验位真、字段格式真、本地化真——才能跑通业务代码的校验逻辑
但绝对不能”真到能用”——真到能开户、能实名、能进生产，就跨过合规边界

工作流速记：

选模板预设当起点（用户 / 订单 / 商品 / 文章）
字段类型按中国化优先挑（专门字段比正则准）
数量 + 格式按消费方设（前端 JSON、SQL 灌库、CSV 给同事）
小批量先跑通字段名 / 类型 / 引号转义，再批量
配置自动存 localStorage，重要的截图备份

红线清单——下列场景一律改用真实脱敏数据或纯虚构数据（如 张三 / 13800000000 / 110000000000000000）：

❌ 任何外网可见的演示 / 公测环境
❌ 任何会接入真实风控 / 实名认证的系统
❌ 任何写入公开数据库的脚本

❓ 常见问题

生成的身份证 / 银行卡 / 统一社会信用代码能通过校验吗？会撞到真人吗？

会通过格式校验，撞真人概率比直觉低估高得多。本工具的校验位算法都是真的：身份证按 GB 11643 加权和 mod 11、银行卡按 Luhn、统一信用代码按 GB 32100 mod 31——它们生成出来能通过任何在线/系统校验器（含很多业务系统的"身份证号合法性校验"）。但本质是伪造：前 17 位是随机抽取地区码 + 随机生日 + 随机顺序码，完整 18 位组合是否对应真实居民完全是概率事件。身份证号空间粗算：地区码（约 3000 个）× 生日（约 50 年 × 365 天 ≈ 18000）× 顺序码（1000）≈ 5.4 × 10¹⁰ = 540 亿组合；全国实际在用 ID 约 14 亿——撞真人概率约 14/540 ≈ 2.6%，远不是"万亿分之一"那种安全级别。1 万条 Mock 数据里平均会有约 250 条跟真人 ID 重合。结论：能用于本地联调、单元测试、SQL 演示；绝对不能用于任何实名 / 风控 / 业务真实场景。

JSON / JSONL / CSV / SQL INSERT 四种输出格式分别什么时候用？

JSON（数组）：前端 fetch mock、MSW 拦截、Postman 响应模板、本地 API mock 服务器——[{...}, {...}] 标准数组结构。JSONL（NDJSON，每行一条 JSON 对象）：大文件流式处理（一行一条好分批读）、灌入 Elasticsearch / BigQuery / DuckDB（这些工具原生支持 NDJSON）、日志格式模拟。CSV：Excel / WPS / Numbers 直接打开看（自带 UTF-8 BOM 中文不乱码）、数据可视化工具（Tableau / PowerBI）导入、给非技术同事看的表格组件 demo。SQL INSERT：数据库压测、迁移演练、新建表的初始数据、SQL 教学。经验：99% 的前端联调用 JSON；CSV 给同事 / 产品 demo；SQL 灌库做性能测试；JSONL 处理超大量级（10 万+）数据时才用。

自定义正则字段支持到什么程度？什么场景必须用脚本后处理？

支持 90% 常见用法：(1) 字符类 [A-Z0-9]、[a-z]、[一-龥]（汉字 Unicode 段）、[^abc] 否定类；(2) 元字符 \d（数字）、\w（字母数字下划线）、\s（空格）；(3) 量词 {n} / {n,m} / + / * / ?；(4) 字面字符 -、_、汉字、@、连字符等。不支持：分组 (...)、选择分支 a|b、反向引用 \1、前/后顾断言 (?=...)、命名组。典型应用：(a) 订单号 ORD-\d{8}；(b) 验证码 [A-Z0-9]{6}；(c) 优惠券 [A-Z]{4}-\d{4}；(d) 自定义 ID USR\d{6}。必须脚本后处理：(1) 真递增 + 复杂模板——ORD-20250524-001 / 002 / 003 这种日期前缀 + 严格递增，本工具的自增序号只支持纯递增（ORD-1001 / 1002），日期前缀混合用正则得到的是随机三位数；(2) 跨字段关联——如订单总价 = 单价 × 数量，需要导出后用脚本算；(3) 加权抽样——枚举字段虽然能调每项概率，但跨字段加权需后处理。

1 万条数据生成会卡浏览器吗？要更多怎么办？

主流电脑 1 万条 × 10 字段在 200ms 内完成，纯 JS 计算量没瓶颈。瓶颈在文本渲染——textarea 显示几 MB 文本会卡，所以页面对超过 20 万字符的输出做了截断显示（"前 20 万字符 + 省略"），但"复制全部"和"下载"按钮始终取完整内容，文件下载完整无截断。需要更多怎么办：(1) 10 万条——分 10 次生成 1 万条 → 各下载 .json/.csv 文件 → 用 cat *.json 拼接（CSV 需要去重表头行）；(2) 100 万条以上——浏览器不适合，建议本地跑 Faker.js / @faker-js/faker / Python Mimesis 脚本，能 10x 更快还能自定义；(3) 字段砍少——每条 30 字段改成 10 个核心字段，生成上限可以再翻几倍。

CSV 在 Excel 打开中文乱码 / SQL INSERT 引号转义怎么处理？

CSV 已经处理乱码：下载的 CSV 文件自带 UTF-8 BOM 字节头（EF BB BF），Excel / WPS / Numbers 打开自动识别为 UTF-8，中文姓名、地址、统一信用代码都能正常显示。如果你用 Python / Node.js / cat 读文件发现开头多了个不可见字符（），那是 BOM——读取时去掉即可：Python 用 encoding="utf-8-sig"，Node 用 fs.readFileSync(f, "utf8").replace(/^/, "")。SQL INSERT 引号转义：工具按 SQL 标准对字符串值里的单引号 ' 双写转义、对反斜杠 \\ 转义、对 NULL 直接用 NULL 关键字。但：不同数据库方言略有差异——MySQL / PostgreSQL / SQLite 通吃 '，SQL Server 也支持 '，Oracle 除 ' 外还有 q 引用语法本工具未输出。生成后建议：先小批量（10 条）跑通灌库流程，再批量。

校验位是真的让生成的数据"以假乱真"——哪些用法已经接近违法？正经联调可以用吗？

接近违法的用法：(1) 真实开户 / 实名认证——伪造身份信息开银行账户 / 注册需要实名的服务（电信卡、互联网金融、平台账号）涉嫌违反《网络安全法》《反电信网络诈骗法》《刑法》第 280 条；(2) 绕过实名风控——电商、游戏、直播平台用生成的身份证号注册多账号，涉嫌违反平台协议，严重时进入诈骗罪范畴；(3) 冒名签订合同 / 业务——伪造身份信息构成欺诈；(4) 写入生产数据库当真实用户——任何外网可见的环境也算"业务数据"，需用脱敏后的真实数据。完全合法的用法：(a) 本地 / 测试环境的接口联调——后端没好前端先 Mock 顶上；(b) 单元测试 / 集成测试样本——CI 跑测试用的固定测试数据；(c) 数据库压测 / 迁移演练——准生产环境性能测试；(d) 教学演示——讲身份证校验算法、SQL 注入演示、CSV 读取教学；(e) 设计稿 / 产品 demo——Figma 拖入"看起来像真的"中文姓名；(f) 培训 / 写文章举例。正经联调放心用——本工具的定位就是这个，底栏已醒目标注"仅供测试，禁止真实业务"。