iLoveDevTool测试数据的三种来路
给测试环境造数据，无非三条路：真实数据脱敏（合规成本高、脱敏不净就是事故）、编程库造数（faker.js/markdownify，灵活但要写代码）、在线生成器（粘贴即得）。低频与一次性任务——本地开发库灌点数据、演示环境要些像样的用户、接口 mock 要份返回——第三条路成本最低。
这篇讲清楚在线造数时的字段规则与格式实践，让生成的数据「形态真实、内容无害、格式正确」。
字段类型：形态真实就够了
假数据的第一原则是形态真实、内容无害——每个字段类型要保真的是它的「形状」：
- 姓名：中文测试里 Zhang San 满天飞是英文 faker 的老问题——中文系统该用中文姓名（姓+名组合，两到四字的自然长度）
- 邮箱：
user@example.com是 RFC 2606 的保留域写法，适合文档示例；造数场景更常用真实域名的随机组合（形态像真邮箱），但要记住它可能恰好撞上真实邮箱——只作占位，别发信 - 手机号：保真的是 1[3-9] 开头 11 位的形态；随机组合可能命中在用号码，同样只作占位
- 城市/公司：常用池抽取——形态自然即可，不需要真实行政区划
- 数字：区间很重要——订单金额 0-1000 和积分 0-10^7 是两个世界，min/max 是字段定义的一部分
- 日期：见下文的坑
安全边界：做与不做的区分
不是所有「能生成」的字段都该做。判断标准是生成物能否通过真实的校验流程：
| 字段 | 有无校验场景 | 结论 |
|---|---|---|
| 姓名/城市/公司 | 无 | 做 |
| 邮箱/手机号 | 形态校验（非实名） | 做（占位用途可控） |
| 身份证/银行卡/护照 | 有校验位算法，可通过实名初筛 | 不做 |
证件号按算法生成的假号是「合法形态」——能过前端校验、能过部分实名接口初筛，挪用风险实质存在。这是负责任的假数据工具的边界线。
日期生成的经典坑
「2020-2025 随机日期」最容易写错的方式是年、月、日三个数独立随机——2023-02-30 就这么来的。正确姿势是 day-of-year 算法：在范围的天数跨度里随机一个偏移，从范围起点加上偏移再格式化。闰年、大小月全部自动正确。
边界也要写死：「2020 到 2025」含不含两端，测试断言里差一天就是失败。
三种输出格式的实践
JSON：夹具与 mock 接口
数组对象是最通用的形态，单元测试夹具、mock server 的返回体直接可用。中文值不需要转义成 \uXXXX——现代工具链都按 UTF-8 处理，原样可读性更好。
CSV：表格与导数工具
RFC 4180 是底线：值里含逗号、引号、换行时要引号包裹且内部引号双写。数字与布尔不加引号——加了引号，下游的类型推断（比如 CSV 转 JSON 工具的动态类型）会把它们全当字符串。
SQL：直接灌库
完整的 SQL 输出包含 CREATE TABLE（列类型从字段类型推导：整数 INT、日期 DATE、其余 VARCHAR）和分批的 INSERT。两个易漏点：列名要做清洗（用户输入 order/user 这类保留字会让建表语句直接报错）和值内单引号的 '' 转义。生成后想看排版更清楚的语句，接一手 SQL 格式化即可。
把 schema 变成数据
假数据生成器把上述规则做全：11 种字段类型逐行定义（数值配区间），预置用户表 schema 一键载入，1-1000 行即时生成，JSON/CSV/SQL 三格式输出（SQL 含建表与转义），中英数据集切换——中文系统的姓名城市不再是英文 faker 的违和输出，全程浏览器本地。生成的 JSON 要检查结构时接 JSON 在线解析，SQL 要排版用 SQL 格式化工具——造数到用数的工作流一站串起来。
常见问题
测试假数据常用哪些字段类型？
主流的 11 种：姓名、用户名、邮箱、手机号、城市、公司、整数、小数、日期、UUID、布尔。覆盖了用户表/订单表等业务表的常见列——更复杂的字段（地址全文、经纬度、嵌套结构）可以由这些基础类型组合或后处理得到。
为什么身份证号不该用工具生成？
身份证号带校验位算法：按 GB 11643 规则生成的假号能通过多数前端的格式校验，甚至部分实名接口的初筛——这类「合法形态」的假证件号存在被挪用于注册和欺诈的实质风险，负责任的工具不应提供。手机号没有校验位场景、仅形态真实，占位用途风险可控，这是做与不做的边界。
假数据输出 JSON、CSV 还是 SQL 好？
看用途：JSON 直接作单元测试夹具或 mock 接口返回；CSV 贴表格、导数据工具；SQL（建表+插入语句）适合往数据库里灌数——本地开发库跑一遍 INSERT 就有了一千行数据。三者的转义规则不同（CSV 要处理逗号引号、SQL 要处理单引号与保留字列名），选对格式比自己手工转义省事。
随机日期生成有什么坑？
最大的坑是「年月日独立随机」会产出 2 月 30 日这类非法日期——正确做法是先在范围内随机一个天数偏移再格式化（day-of-year 算法），闰年自动正确。其次是边界含混：说「2020 到 2025」要写清是否含两端，写进测试断言时差一天就是失败。