为什么每个开发者都需要占位文本与 Mock 数据
打开任何一个前端原型、设计稿、接口文档、单元测试，你都会看到它们：
- 设计稿里密密麻麻的 “Lorem ipsum dolor sit amet…”
- 接口文档里
{"name": "张三", "email": "test@example.com"} - 单元测试里
const users = [{ id: 1 }, { id: 2 }, { id: 3 }] - 数据库种子脚本里 100 条虚构用户记录
这些就是占位文本与Mock 数据。它们看似不起眼，却是软件开发中最高频的”基础设施”之一。好的占位文本能让设计评审聚焦版式而非内容；好的 Mock 数据能让接口测试覆盖边界情况；好的随机生成器能让测试用例不重复。
本文从工程实践出发，讲清楚占位文本与 Mock 数据的设计原则、实现要点与工具协同。
配套工具：占位文本与 Mock 数据生成器
一、Lorem Ipsum 的前世今生
1.1 拉丁文假文章的起源
Lorem Ipsum 不是无意义的乱码，而是一篇真实的拉丁文。它源自公元前 45 年西塞罗的《善恶极》（De finibus bonorum et malorum）第一卷第 32-33 节。16 世纪某位印刷工人为了展示字体样张，把这段文字拼凑成”假文章”，因为其字母分布接近真实英文，能让观者专注于版面而非语义。
直到今天，Lorem Ipsum 仍是设计、印刷、Web 领域的占位文本事实标准。Adobe InDesign、Figma、Bootstrap 文档默认占位都是它的变体。
1.2 为什么不直接用”测试测试测试”
你可能会问：占位文本随便写什么都行，为什么非要拉丁文？
答案在于字母分布。真实英文文本的字母频率并不均匀（e/t/a/o/i/n/s/h/r 占 60%+），而 “测试测试测试” 或 “test test test” 的字母分布极度失真。这会导致：
- 设计稿里行宽、字间距、断行点与真实内容差异明显
- 字体渲染测试无法反映真实阅读体验
- 段落高度、首行缩进、悬挂标点等排版细节无法验证
Lorem Ipsum 的拉丁文字母分布接近真实英文，是”看起来像文章但不打扰阅读”的最佳折中。
1.3 三种粒度：段落、句子、单词
本工具支持三种粒度：
- 段落：3-6 句组成一段，适合填充文章正文区
- 句子：单个句子，适合卡片标题、列表项、表单提示
- 单词：单个拉丁词，适合标签、按钮、短标题
不同粒度覆盖不同场景。例如做新闻列表原型，用句子粒度生成 20 条标题；做博客首页原型，用段落粒度生成 5 篇摘要。
二、中文排版的占位困境
2.1 拉丁字母不适合中文
直接把 Lorem Ipsum 用在中文站点会有明显问题：
- 字宽不同：拉丁字母是变宽（i 窄、m 宽），中文是等宽（每个字 1em）
- 行高不同：中文行高通常 1.6-1.8，英文 1.4-1.5 即可
- 断行规则不同：中文可在任意字间断行，英文只能在单词间断行
- 标点不同：中文全角标点占 1em，且有避头尾规则
用 Lorem Ipsum 测试中文排版，得到的结果几乎无效。
2.2 中文占位的常见方案
业界有几种中文占位方案：
- 乱数假文：从常用字库随机抽字，分布均匀但语义混乱
- 古诗片段：用《滕王阁序》《岳阳楼记》等经典，文辞优美但过于眼熟
- 现代散文模板：从预设句子库随机组合，兼顾分布与可读性
- 千字文：天地玄黄宇宙洪荒，每字不重复，适合字间距测试
本工具采用方案 3：从 20 句模板库（含古诗、散文、现代文）随机组合成段落。这样既保证字母分布接近真实中文，又避免古诗过于眼熟导致观者分心。单词粒度则从常用字库随机选取单字，用于字间距、行高测试。
三、Mock 数据的工程价值
3.1 前后端并行开发的基石
现代 Web 开发的典型流程：
产品经理 → 接口契约（OpenAPI Schema）→ 前端 / 后端并行开发
↓
前端用 Mock 数据先开发
↓
后端实现接口 → 联调替换 Mock前端开发阶段，后端接口可能尚未实现。此时需要 Mock 数据填充界面，验证布局、交互、状态流转。Mock 数据的质量直接决定前端开发效率——如果数据格式与真实接口不一致，联调时要返工重做。
3.2 测试用例的边界覆盖
单元测试不仅要测”正常路径”，还要测边界情况：
- 空字符串、超长字符串、特殊字符
- 0、负数、最大值、NaN
- null、undefined、空数组、空对象
- 闰年、月末、跨年、跨时区
手动构造这些边界数据费时易错。用 Mock 数据生成器批量生成，再人工挑选边界值，效率高得多。
3.3 数据库种子数据
新项目初始化时，通常需要往数据库灌入一批种子数据用于演示：
- 10 个用户、50 篇文章、200 条评论
- 不同角色（管理员、普通用户、访客）
- 不同状态（已发布、草稿、已删除）
用 Mock 生成器导出 CSV 或 SQL，直接导入数据库，比手写 INSERT 语句快 10 倍。
四、11 种 Mock 数据类型的设计
本工具支持 11 种常用数据类型，覆盖 90% 的 Mock 场景：
| 类型 | 格式 | 示例 | 设计要点 |
|---|---|---|---|
| 中文姓名 | 姓+1-2字名 | 王晓明 | 百家姓 + 吉祥字，50% 单字名 |
| 英文姓名 | First Last | James Smith | 30 个 First + 30 个 Last |
| 邮箱 | name@domain | james123@gmail.com | 6 个常用域名 |
| URL | https://domain/path | https://www.example.com/about | 5 个域名 + 8 条路径 |
| 中国手机号 | 1[3-9]xxxxxxxxx | 13812345678 | 符号工信部号段规则 |
| UUID v4 | 8-4-4-4-12 | 550e8400-e29b-41d4-a716-446655440000 | 基于 crypto.randomUUID |
| IPv4 | a.b.c.d | 192.168.1.100 | 排除 0.x 与 255.x |
| 颜色 | #RRGGBB | #2b6cff | 三通道独立随机 |
| 日期 | YYYY-MM-DD | 2024-06-15 | 2000-2025 范围，日用 28 避免越界 |
| 数字 | 1-999 | 42 | 整数，可扩展为范围参数 |
| 布尔 | true/false | true | 等概率 |
4.1 为什么手机号要限定 1[3-9] 开头
中国手机号格式由工信部规定：第 1 位固定为 1，第 2 位为 3-9（13x、14x、15x、16x、17x、18x、19x 号段）。如果直接生成 1 + 10 位随机数，可能产生 10xxxxxxxxx、12xxxxxxxxx 这种非法号段，导致表单校验失败。本工具严格按号段规则生成，保证通过常见的手机号正则校验。
4.2 为什么日期用 28 而不是 31
不同月份天数不同（1/3/5/7/8/10/12 月 31 天，4/6/9/11 月 30 天，2 月 28 或 29 天）。如果日期随机 1-31，生成 2024-02-30 这种非法日期会破坏测试。本工具日期统一用 1-28，保证所有月份都合法。如需测试月末边界（如 2 月 29 日闰年），可手动构造。
五、CSPRNG vs PRNG：随机数质量决定数据质量
5.1 Math.random 的问题
JavaScript 的 Math.random 是伪随机数生成器（PRNG），基于 xorshift128+ 算法。它有两个关键缺陷：
- 可预测：给定连续输出，可以反推内部状态，预测后续所有”随机”数
- 分布不均：在高精度取模时存在模偏差（modulo bias）
对于占位文本，这两个问题无所谓。但对于 UUID、密码、密钥，可预测性是致命的——攻击者可以枚举出你生成的所有 UUID，撞库窃取数据。
5.2 crypto.getRandomValues 的优势
浏览器提供的 crypto.getRandomValues 是密码学安全随机数生成器（CSPRNG），基于操作系统熵源（Linux 的 /dev/urandom、Windows 的 CryptGenRandom）。它：
- 不可预测：即使知道所有历史输出，也无法预测下一个数
- 分布均匀：基于硬件中断、键盘鼠标时序等物理熵源
- 性能足够：浏览器实现通常比 Math.random 慢 5-10 倍，但对于工具类应用完全够用
本工具的所有 Mock 数据生成都优先使用 CSPRNG，保证 UUID 碰撞概率约 2^-122（需要生成 2.71×10^36 个 UUID 才有 50% 碰撞概率）。这与 密码生成器 共享同一套随机源哲学。
5.3 降级策略
在不支持 crypto.getRandomValues 的环境（如非 HTTPS 页面、旧浏览器），本工具自动降级到 Math.random。这保证了兼容性，但 UUID 质量会下降。生产环境务必启用 HTTPS。
六、四种输出格式的场景适配
6.1 纯文本
每项一行，最简格式。适合：
- 粘贴到笔记、文档作为示意
- 作为命令行输入（如
curl测试 URL 列表） - 喂给其他工具处理（如
sort、uniq）
6.2 JSON 数组
2 空格缩进的 JSON 数组。适合：
- 前端 Mock 接口返回值（直接
fetch本地 JSON 文件） - 配置文件示例（如
users.json） - 喂给 JSON 工具 格式化、校验、树形查看
[
"赵伟",
"孙芳",
"李娜"
]6.3 CSV
type,value 两列。适合：
- 导入 Excel 做数据分析
- 数据库批量导入（
LOAD DATA INFILE） - 喂给 CSV/JSON 工具 转 JSON、校验格式
type,value
name-cn,"赵,伟"
name-cn,孙芳注意：含逗号、换行、双引号的值会用双引号包裹并转义内部双引号（标准 CSV 规则）。本例中 “赵,伟” 因含逗号被包裹。
6.4 Markdown 表格
| # | value | 格式。适合：
- 写入 README、文档站点
- 提交到 GitHub Issue、PR 描述
- 喂给 Markdown 工具 渲染预览
| # | value |
| --- | --- |
| 1 | 赵伟 |
| 2 | 孙芳 |
| 3 | 李娜 |七、工具矩阵联动
本工具与其他工具形成「数据生成 → 处理 → 校验」的协同链路：
7.1 与 Markdown 工具联动
本工具的 Markdown 表格输出可直接粘贴到 Markdown 工具 渲染预览，验证表格语法是否正确、列宽是否合理。反向场景：在 Markdown 工具里写表格太慢，用本工具生成 10 行 Mock 数据再粘贴，效率提升 5 倍。
7.2 与 JSON 工具联动
本工具的 JSON 数组输出可粘贴到 JSON 工具 格式化、树形查看、搜索过滤。例如生成 50 个邮箱，用 JSON 工具检查是否有重复、是否符合预期域名分布。
7.3 与 CSV/JSON 工具联动
本工具的 CSV 输出可粘贴到 CSV/JSON 工具 转 JSON，进一步用于接口 Mock。反向场景：手头有一份 CSV 真实数据，想快速 Mock 一份结构相同的测试数据，可用本工具生成 CSV 再合并。
7.4 与 UUID 工具联动
本工具生成的 UUID v4 可粘贴到 UUID 工具 查看版本号、变体位、时间戳（v1 才有）。这有助于理解 UUID 的内部结构，以及为什么 v4 适合做数据库主键（无序、不可预测、碰撞概率极低）。
7.5 与密码生成器联动
本工具的 CSPRNG 与 密码生成器 共享同一套随机源哲学：密码学安全、不可预测、分布均匀。理解了 CSPRNG 的价值，你就能明白为什么密码不能用 Math.random 生成，以及为什么 UUID v4 可用于会话令牌。
八、扩展阅读
- Lorem Ipsum 生成器原文与历史
- RFC 4122 - UUID 规范
- Web Crypto API - getRandomValues
- 密码强度与熵：CSPRNG 与拒绝采样
- UUID 生成原理与版本对比
- Markdown 实用语法指南
总结
占位文本与 Mock 数据是软件开发的基础设施，质量直接影响设计评审、接口联调、测试覆盖的效率。本工具的核心设计原则：
- 分布真实：Lorem Ipsum 字母分布接近英文，中文模板库接近真实中文
- 格式合规：手机号符合号段规则，日期避免越界，UUID 符合 RFC 4122
- 随机安全：优先 CSPRNG，保证 UUID 不可预测，降级策略保证兼容
- 输出灵活：四种格式覆盖前端、后端、文档、数据库场景
- 工具协同：与 Markdown / JSON / CSV / UUID / 密码工具形成完整链路
下次需要 Mock 数据时，别再手写 test1、test2、test3 了——用工具生成 100 条高质量数据，专注业务逻辑而非数据构造。