有区别吗？**
没有。clip-path 作用于元素的 border-box，无论内容是图片还是背景都一样。但
![]()
上的 clip-path 在某些旧移动设备可能卡顿，用
包裹会更稳。
---
## CSS 圆角完全指南：单角 / 椭圆 / 异形按钮
> 从 border-radius 速记法到独立四角写法、椭圆圆角、超大半径胶囊形、blob 动画形状、与 overflow:hidden 的配合、SVG vs CSS 圆角的选择、阴影与圆角的视觉互动。
URL: https://xtechtools.com/guides/border-radius/
发布：2026-04-29 · 更新：2026-04-29
border-radius 是最被低估的 CSS 属性之一。大多数开发者只会用 border-radius: 8px，但这个属性能做出椭圆、半圆、胶囊形、不规则 blob 形状，甚至配合关键帧动画做流体效果。本指南从速记法与独立角写法讲起，深入椭圆圆角、超大半径胶囊形、blob 动画、overflow 配合裁剪、SVG 对比、以及 box-shadow 视觉互动等高级技巧，帮你全面掌握这个强大属性。
### 速记法与独立角写法
border-radius 支持 1 到 4 个值的速记法，类似 margin/padding：
```
border-radius: 8px; /* 四角都 8px */
border-radius: 8px 16px; /* 上下 8px，左右 16px */
border-radius: 8px 16px 24px; /* 上 8px，左右 16px，下 24px */
border-radius: 8px 16px 24px 32px; /* 上右下左，顺时针 */
```
独立写法更清晰：
```
border-top-left-radius: 8px;
border-top-right-radius: 16px;
border-bottom-right-radius: 24px;
border-bottom-left-radius: 32px;
```
实际上 border-radius 可以有 8 个值（用 `/` 分隔水平和竖直半径），但大多数场景不需要这么复杂。
### 椭圆圆角：水平 / 竖直半径分别控制
border-radius 的秘密是每个角其实是一个椭圆弧，水平和竖直半径可分别指定。
```
border-radius: 10px 20px;
```
这里 10px 是水平半径，20px 是竖直半径。结果是椭圆形的角。
完整写法：
```
border-radius: 10px 20px / 5px 15px;
/* 水平半径 / 竖直半径 */
```
这样四个角分别是不同的椭圆弧。用来制作"上面圆、下面方"这样的混合形状非常方便。配合特定长宽比，可以做出自然流畅的卡片边角。
### 超大半径生成胶囊形与半圆
把 border-radius 设成超过容器尺寸的值，可以生成胶囊形（两端半圆的矩形）。
```
.pill {
width: 200px;
height: 100px;
border-radius: 50px; /* 半径 = 高 / 2，生成胶囊形 */
}
```
或者用百分比更通用：
```
border-radius: 50%;
```
如果容器是正方形，border-radius: 50% 就是完整圆形；矩形时就是胶囊形。这是实现圆形头像、圆形按钮最简洁的方法。
半圆：
```
border-radius: 100px 100px 0 0; /* 上两个角圆，下两个角方 */
```
或者一行搞定：`border-radius: 100px 100px 0;` 利用速记法省略最后一个角（默认等于第二个）。
### Blob 形状与不同角的半径组合
让每个角有不同的半径，再加上不规则的宽高比，就能做出有机的 blob 形状。
```
.blob {
width: 200px;
height: 180px;
border-radius: 40% 60% 50% 30% / 30% 50% 40% 60%;
}
```
这样的形状看起来像液体 blob。加上动画：
```
@keyframes blob {
0% { border-radius: 40% 60% 50% 30% / 30% 50% 40% 60%; }
50% { border-radius: 30% 70% 40% 40% / 50% 30% 60% 50%; }
100% { border-radius: 40% 60% 50% 30% / 30% 50% 40% 60%; }
}
.blob { animation: blob 4s infinite; }
```
就能做出流体效果的形状变化。这在现代设计（如 Stripe、Figma）中很流行。
### 与 overflow: hidden 配合裁剪子元素
border-radius 单独只影响元素本身的边框和背景，子元素内容会溢出超过圆角。结合 overflow: hidden 才能彻底裁剪。
```
.card {
border-radius: 8px;
overflow: hidden; /* 裁剪溢出内容 */
}
.card img {
width: 100%;
display: block; /* 移除 inline gap */
}
```
没有 overflow: hidden，圆角图片的四角会显示出矩形图片的直角。这是卡片设计最常见的坑。
性能提示：overflow: hidden 在某些老设备会触发新的层叠上下文，有微小性能代价。现代设备完全无所谓，但如果列表有 1000+ 个卡片，可以用 clip-path: inset() 替代（更高效）。
### SVG vs CSS 圆角的选择标准
两种方式都能做圆角，选择取决于需求。
**CSS border-radius**：
- 优点：简单、性能好、支持动画、响应式自适应
- 缺点：只支持椭圆弧，不能做出完全自由的曲线（如贝塞尔曲线）
**SVG
或 **：
- 优点：任意曲线形状、精确控制、可做复杂插图
- 缺点：需要外联或内联 SVG，文件更大，响应式需要特殊处理
**决策树**：
- 简单矩形 + 圆角 → CSS border-radius
- 圆形 / 胶囊形 → CSS border-radius: 50%
- 不规则 blob / 复杂曲线 → SVG
- 卡片 / 按钮的圆角 → CSS（99% 的实际项目情况）
大多数场景（2026 年）用 CSS 就够了，除非设计稿明确要求 SVG 级别的曲线精度。
### 阴影与圆角的视觉互动
box-shadow 与 border-radius 配合使用，阴影会自动跟随圆角的曲线，产生自然的视觉效果。
```
.card {
border-radius: 8px;
box-shadow: 0 4px 12px rgba(0, 0, 0, 0.1);
}
```
这样阴影的 4 个角也是圆的，不会像有 border-radius 但没有阴影的元素那样显得生硬。
细节技巧：
- **多层阴影**：`box-shadow: 0 2px 4px rgba(0,0,0,0.1), 0 8px 16px rgba(0,0,0,0.08);` 做出更自然的深度
- **内阴影**：`box-shadow: inset 0 1px 2px rgba(255,255,255,0.5);` 在圆角内部高亮边缘，增强立体感
- **悬停效果**：增加阴影模糊距离或偏移量，`transition: box-shadow 0.3s;` 做出浮起效果
现代设计系统（Material Design 3 等）都用这样的组合定义组件：border-radius + box-shadow 就是一张卡片的全部。
### 常见问题
**Q: border-radius: 50% 对矩形和圆形分别是什么效果？**
对正方形，50% 就是完整圆形；对宽高不等的矩形，50% 是胶囊形（两端半圆）。百分比相对于元素的宽和高分别计算。
**Q: 为什么我的圆角图片四个角还是方的？**
忘了加 overflow: hidden。border-radius 只影响元素边框和背景，子元素的内容（如 ![]()
）会溢出超过圆角。加上 overflow: hidden 才能彻底裁剪。
**Q: border-radius 能动画化吗？**
可以，现代浏览器完全支持。用 @keyframes 改变 border-radius 值，或用 transition。性能很好，因为是 GPU 加速。
**Q: border-radius 与 clip-path 有什么区别？**
border-radius 只能做椭圆弧（包括圆形、胶囊形等组合），clip-path 可以做任意多边形和路径。两者都是裁剪，但 border-radius 更适合"微调边角"，clip-path 适合"自由形状"。
**Q: 用百分比 border-radius 响应式吗？**
不如想象中灵活。border-radius: 50% 对正方形是圆形，对矩形是胶囊形，随容器变化。但如果想"圆角的大小随容器宽度缩放"，用 CSS 变量 + calc() 更好：`border-radius: calc(var(--size) * 0.1);`
**Q: blob 动画的 border-radius 值是怎么设计的？**
通常在设计工具（如 Figma）中手工调，或用生成器（如 blobmaker.app）随机生成，再通过 @keyframes 逐帧变化。没有通用公式，靠审美和迭代。
---
## JSON / YAML / CSV 互转完整指南：格式选型 + 迁移技巧
> 对比 JSON、YAML、CSV 三种数据格式的本质差异，深入讲解嵌套深度、类型表达、何时该用谁，以及互转中的常见坑点与解决方案。
URL: https://xtechtools.com/guides/data-convert/
发布：2026-04-29 · 更新：2026-04-29
互联网时代，数据在 JSON、YAML、CSV 三种格式之间频繁流转。JSON 是 API 通信之王，YAML 统治配置文件，CSV 掌控表格数据导入导出。但它们并非简单的表层不同——本质上是为不同场景设计的三套体系，各自有独特优势与局限。本文深入对比三种格式的设计理念、适用边界与互转技巧，帮你快速定位用哪个、何时互转、怎样避免数据丢失，掌握实战常见坑点与方案。
### 三种格式的本质定位
JSON 是通用的数据交换标准，基于键值对和数组，天生支持无限嵌套，但语法严格（强制双引号、禁止尾随逗号）。任何支持 JSON 的编程语言都能无缝解析，是互联网通信的标准格式。YAML 是人类友好的配置语言，用缩进表达结构，自动推断类型（yes/no 识别为布尔值），适合开发者手写配置文件，减少大括号和引号的视觉噪音。CSV 是表格数据的扁平化表示，一行一条记录，逗号分隔字段，没有嵌套的概念，与 Excel 无缝兼容。三者就像编程中的"运输方式"：JSON 是飞机（快速、通用、成本高、跨界通用），YAML 是小车（舒适、易读、有限制），CSV 是货车（大量数据、只适合表格、零学习曲线）。
### 嵌套深度与数据模型差异
JSON 和 YAML 都支持任意深度的嵌套：{"user": {"address": {"city": "Beijing"}}} 或等价的 YAML 缩进结构。嵌套层数没有限制，理论上可以无限深。但 CSV 本质上是二维的——每行是一条记录，每列是一个字段。如果你的数据是 {"id": 1, "tags": ["ai", "tool"]}，转成 CSV 就痛苦了：要么把 tags 数组展开成多行（破坏了原有的记录结构），要么把整个数组序列化成单个字符串字段。这不是 CSV 的设计缺陷，而是为了兼容电子表格而做的妥协。所以互转前，先问自己：数据的深度是多少？有数组吗？如果超过二维，CSV 会很难受。
### 类型表达与隐式推断
JSON 的类型非常显式：数字是 123、字符串是 "text"、布尔值是 true/false、null 是 null。这种严格的类型系统确保了跨语言的精确解析。YAML 会自动推断类型：123 自动成整数，true 自动成布尔，"123" 字符串必须加引号。这对配置文件很方便，但也容易出错。CSV 全部是字符串——123、true、2026-04-29 在 CSV 中都是文本，导入数据库或 JSON 时需要额外的类型转换步骤。这就是为什么 CSV 导入常出现"日期显示为数字"的问题：缺少类型元数据。YAML 和 JSON 都能保留类型信息，但 YAML 更宽松（有歧义），CSV 最严格（无类型）。
### 何时用 JSON、何时用 YAML、何时用 CSV
API 通信和数据存储用 JSON：REST API 响应、WebSocket 消息、NoSQL 数据库都是 JSON 的主场。因为 JSON 的类型系统明确，跨语言兼容性最好。应用程序配置用 YAML：Kubernetes、Docker Compose、CI/CD 流程（GitHub Actions、GitLab CI）都用 YAML。因为 YAML 对人类最友好，配置文件通常被非开发者修改，缩进结构比 JSON 的大括号更直观。表格数据导入导出用 CSV：数据库导出、电子表格、CRM 系统数据都是 CSV 的天下。因为 CSV 与 Excel/Google Sheets 无缝集成，是跨平台的表格通用格式。
### JSON → YAML 互转的坑点
JSON 转 YAML 通常很顺利，因为 YAML 是 JSON 的超集，可以直接加缩进就行。但反向就难了：YAML 中的 true、yes、no、on、off 都被推断为布尔值，而 JSON 会把它们序列化成 true，字符串意义完全丢失。如果你的 YAML 配置有 password: yes，转成 JSON 会变成 "password": true，下游系统期望字符串但收到布尔值就崩溃了。解决办法是在 YAML 中用引号强制指定为字符串：password: "yes"。另一个坑是 YAML 的特殊字符（@、*、&、|）在 JSON 中可能有歧义，需要谨慎转换，甚至需要 escape。
### CSV 互转的常见陷阱
CSV 最大的坑是字段内包含逗号：如果字段值是 "Smith, John"，必须用双引号包裹整个字段："Smith, John"。如果字段内有引号，比如 say "hello"，得用双双引号转义：say ""hello""。很多人不知道这个规则，导致互转时字段错位。另一个大坑是换行符：CSV 中的字段可以包含 \n（换行），但整个字段必须用双引号包裹："name\nJohn"。电子表格软件（Excel、Google Sheets）会直接显示为多行单元格，但纯文本工具会误判。编码问题也很常见：CSV 的默认编码因操作系统而异。Windows Excel 用 GBK（中文）或 CP1252（西文），Mac 用 UTF-8。导入时如果编码选错，中文就变成乱码。正确做法是导出为"UTF-8 with BOM"（Byte Order Mark），这样 Excel 自动识别为 UTF-8。
### 实战互转工具与命令行方案
本工具 /data-convert/ 提供可视化互转三种格式，自动处理编码、转义、类型推断，提供预览和验证功能。用户上传一个文件，选择目标格式，秒速得到转换结果，并能下载或复制。对于日常使用，无需学习命令行。命令行方案有 jq（JSON 处理）、yq（YAML 处理）、Miller（CSV 处理），它们可以链式调用进行复杂转换。比如 jq . input.json | yq -P - 可以把 JSON 转成 YAML，miller --json2csv input.json > output.csv 可以把 JSON 转成 CSV。但这些工具有学习曲线，对于快速互转和验证，可视化在线工具更直观、更安全。
### 常见问题
**Q: CSV 能表达嵌套数据吗？**
不能。CSV 是二维表格，无法直接表达嵌套结构。如果你的数据是嵌套的（如 user.address.city），可以把嵌套路径展开为单列（如 user_address_city），但这样会失去结构信息。如果必须保留嵌套，应该用 JSON 或 YAML，或者用逗号分隔的路径语法（但需要自定义解析）。
**Q: YAML 的缩进必须是 2 个空格吗？**
不强制，但约定俗成是 2 个空格。YAML 规范允许任意缩进，但同一层级必须对齐。用 Tab 会导致很多 YAML 解析器报错。所以最佳实践是一律 2 个空格，保证兼容性。很多编辑器都有快速转换 Tab 为空格的选项。
**Q: JSON 转 CSV 后数据是否会丢失？**
可能会。如果 JSON 包含嵌套对象或数组，转成 CSV 后信息会序列化成字符串（比如整个对象变成 [object Object]）。反向导入回 JSON 时无法恢复原有结构。所以 CSV 互转只适合扁平化的表格数据，嵌套数据应该用 JSON 或 YAML。
**Q: CSV 文件很大（百万级行），怎么处理？**
本工具支持分页加载，但如果超过浏览器内存限制，建议用服务端脚本（Python pandas、Node.js csv-parser）流式处理。或者用 Miller、awk 等命令行工具做分片、过滤、统计，再导入 CSV。大文件处理不适合在浏览器中一次性加载。
**Q: 互转后如何验证数据完整性？**
最稳妥的方法是对比原始和转换后数据的行数、列数和关键字段的哈希值。本工具的预览功能可以看样本数据，但全量验证需要脚本。如果数据包含关键字段（如 ID），可以先提取这些字段做对比，确保没有丢失或重复。
**Q: YAML 配置中的多行字符串怎么表达？**
YAML 有两种多行语法：| 保留换行符和尾部空行，> 折叠换行符（连续行视为一行）。比如 description: | 会换行显示，description: > 会连接成一行。选择哪个取决于你的配置是否需要保留原始换行。JSON 和 CSV 都用 \n 表示换行。
---
## JSON 对比完全指南：API 调试 / 数据漂移 / 配置变更
> 掌握 JSON 对比的本质——文本 diff 与结构 diff 的区别、数组比对的复杂性、实战场景与工具方案，快速定位 API 问题、数据变更、配置差异。
URL: https://xtechtools.com/guides/json-diff/
发布：2026-04-29 · 更新：2026-04-29
两份 JSON 数据看似相同，但键的顺序不同、某个字段从 null 变成 0、API 响应多了一层嵌套——这些差异对业务逻辑意味着什么？本文深入讲解 JSON 对比的两条路径（文本级 vs 结构级）、数组比对的三种理解方式、以及在 API 联调、数据库变更、配置管理中的实战应用。掌握文本 diff 和结构 diff 的区别，快速定位差异根源。
### 文本 diff 与结构 diff 的本质差异
文本 diff（如 Linux 的 diff 命令）逐行逐字比对，{"a": 1, "b": 2} 和 {"b": 2, "a": 1} 虽然逻辑相同，但键序不同，文本 diff 会报告多处变更。这导致大量虚假警告，严重降低 code review 的效率和准确度。结构 diff（JSON-aware 对比）理解 JSON 的语义，比对的是实际的键值对和值，不关心顺序，确保只报告真正的数据变更。API 前后端联调时，结构 diff 更有用——你关心的是字段值改了没，不是字符位置。配置文件 code review 时，文本 diff 反而更有用。两种方案都有用，取决于场景和用途。
### 键序不同 ≠ 数据内容不同
JSON 对象的键序在规范上是无序的（order-independent），但很多系统会依赖键序（比如有些旧的 JavaScript 引擎）。当你从数据库导出 JSON 时，因为 SQL 查询顺序、ORM 处理等因素，返回的键序可能每次都不同。用 diff 工具比对时，如果用的是文本 diff，键序不同就会显示为变更，导致大量虚假警告，严重浪费 code review 时间和精力。解决办法是用 JSON 结构感知的对比工具，或者先把 JSON 做标准化（按键名排序），再做 diff。本工具 /json-diff/ 会自动标准化键序，确保比对的是真正的数据变更。
### 数组比对的三种理解方式
JSON 数组 [1, 2, 3] 和 [1, 3, 2] 包含相同元素，但顺序不同。如何对比？取决于数组的语义。按位置比对：第一种方式，[1, 2, 3] 和 [1, 3, 2] 是不同的，因为第 2、3 位置的值不同。这适合有序数据，比如 API 返回的分页结果或排序列表（顺序很重要）。按内容比对：第二种方式，[1, 2, 3] 和 [1, 3, 2] 的"集合"内容相同（都包含 1、2、3），但顺序不同。这适合无序集合，比如 tags: ["ai", "tool"] 和 tags: ["tool", "ai"]。按主键比对：对于对象数组最常用的是按 id 主键比对，这样即使顺序变了，也能识别出哪个对象改变了。电商订单的商品列表、用户表的数据更新，都用这种方式。
### API 联调中的 JSON 对比实战
API 前后端对接时，常见场景：前端期望 {code: 0, data: {...}, message: "success"}，后端返回了 {code: 200, data: {...}, message: "OK"}。用 JSON 对比工具，可以秒速看出 code 和 message 字段的差异，找出沟通点。另一个场景是分页 API：前端问"为什么用户列表顺序变了"，后端说"我没改逻辑"。用 JSON 对比，对比两个不同时间的响应，可以看出是否新增了用户、删除了用户、还是排序规则变了。很多 API 返回的 total_count、page_size、items 数组，一个对比就能看透。还有版本迭代中的向后兼容性检验：API v2 返回了一些 v1 没有的字段（比如 new_feature），用对比工具确认是纯新增，没有改动旧字段。
### 数据库 dump 对比与数据漂移检测
数据库导出的 JSON dump 在开发、测试、生产环境间流转。用 JSON 对比工具可以快速发现数据漂移：生产环境某条用户记录的 email 字段莫名多了个空格，或者某个订单的 total_price 和子项金额不匹配。批量数据迁移后，常需要验证源库和目标库的数据一致性。逐条对比 SQL 查询结果的 JSON 表示，就能发现漂移。比如迁移 MongoDB 到 PostgreSQL，数据类型转换时容易出现浮点数精度问题（1.1 变成 1.100000001）、日期格式变化（ISO 8601 vs Unix timestamp）。用对比工具，一秒看出所有不匹配。对于大型系统的定期健康检查，可以定期导出关键表的 JSON，与历史 snapshot 对比。
### 配置文件变更的审计与验证
应用配置通常存储为 JSON（特别是 JSON5 或注释 JSON）。每次改动配置时，用对比工具可以看到确切改了什么：某个数据库连接字符串的 password 字段改了、某个特性开关从 false 变成 true、某个限流策略的阈值从 1000 改成 2000。对于团队协作，配置变更需要 code review。JSON 对比工具可以生成人类可读的报告，列出所有变更点、新增键、删除键、修改的值，方便 reviewer 快速审批。特别是配置涉及特别嵌套结构（如 middleware 中间件链、feature flags），用结构化对比能避免遗漏。上线前的预检：比对测试环境配置和生产环境配置，确保没有误改。
### 实战工具：本工具 + jq + 命令行方案
本工具 /json-diff/ 提供可视化对比，支持缩放、展开、突出差异部分，适合快速定位问题。点击差异项可以跳转查看具体位置。命令行方案用 jq：jq -S . file1.json > sorted1.json && jq -S . file2.json > sorted2.json && diff sorted1.json sorted2.json，可以标准化后文本对比。更高级的是 jdiff、json-diff npm 包或 python json 库，能做结构感知的对比，输出结构化的 patch（按 RFC 6902 JSON Patch 标准）。这些工具适合集成到自动化测试或 CI/CD 流程。
### 常见问题
**Q: 两个 JSON 对象的键序不同，是否算不同的数据？**
在逻辑上不同——JSON 规范认为键序是无序的，{a:1, b:2} 等价于 {b:2, a:1}。但在系统实现中，有些语言/库会保留键序（如 Python 3.7+ 的字典），某些操作（如哈希计算、签名）会依赖键序。本工具的结构 diff 模式不关心键序，文本 diff 模式会报告差异。根据你的场景选择对比模式。
**Q: 大型 JSON 文件（几 GB）怎么对比？**
浏览器有内存限制，超大文件无法在本工具中一次性加载。建议用流式处理的命令行工具（如 jq + stream processing）或服务端脚本。或者把大文件分割成若干小文件，逐个对比，最后合并结果。
**Q: 如何忽略某些字段的对比（如 timestamp、ID）？**
JSON diff 工具的高级选项通常支持字段过滤或规则忽略。本工具暂未支持，但可以用 jq 预处理：jq "del(.timestamp, .id)" file.json | ... 先删除不关心的字段，再做 diff。
**Q: 数组元素多了或少了，怎么快速定位变更？**
按位置对比会显示第几位改了，按内容对比会显示新增/删除了哪个元素。如果数组很大（几百条），建议先比对数组长度，再用按内容模式找出新增/删除的元素（如果有主键的话）。本工具会统计增删数量。
**Q: 如何验证 API 返回的数据是否按合约返回？**
保存预期的 JSON schema 或样本响应，用对比工具与实际响应比对。如果所有字段都相同，说明合约满足；如果多了字段，可能是向前兼容的扩展；如果少了字段，可能有 bug。也可以用 JSON Schema validator 工具来验证结构和类型。
**Q: JSON 中浮点数 1.0 和 1 算不同吗？**
取决于工具实现。JSON 规范把 1.0 和 1 视为相同的数值，但文本对比会看到 "1.0" 和 "1" 是不同的字符串。结构化对比工具应该把它们视为相等。如果数据从浮点数转整数（或反之），这是可能的，但通常表示数据处理过程中类型转换了。
---
## CSV 在线查看完整指南：编码 / 分隔符 / 大文件
> 深入讲解 CSV 的标准与方言、编码陷阱（UTF-8 vs BOM）、分隔符变体、特殊字符转义、大文件处理与排序筛选，以及何时用 CSV vs Excel。
URL: https://xtechtools.com/guides/csv-viewer/
发布：2026-04-29 · 更新：2026-04-29
CSV（逗号分隔值）是全球最通用的表格数据格式，但简单外表掩盖了复杂的坑。一份看似普通的 CSV 文件，因为编码选错、分隔符误判、字段中的逗号没转义，就会在导入时乱码或错位。本文深入讲解 CSV 的标准与方言、编码与 BOM、分隔符变体、大文件加载与优化策略，以及何时用 CSV、何时该用 Excel 或其他格式，掌握 CSV 方方面面。
### CSV 没有"统一标准"——RFC 4180 vs Excel 方言
RFC 4180 是 CSV 的官方规范，定义了基本语法：用逗号分隔字段，用双引号包裹含特殊字符的字段，字段内双引号要双双转义（""）。但实际上，CSV 是个高度碎片化的格式。Excel（Windows）用 GBK 编码导出 CSV，Mac Numbers 用 UTF-8，Google Sheets 默认 UTF-8。某些系统用分号（；）而非逗号作分隔符（尤其是欧洲，因为他们用逗号作小数点）。结果是同样的 CSV 文件，在不同系统打开显示完全不同。导出者遵循 RFC 4180，导入者却期望 Excel 方言，就会出现乱码或字段错位。最坑的是"我的 Excel 打开没问题"，但用 Python pandas 或 JavaScript 的 csv-parser 导入就崩溃。
### 分隔符变体与自动检测机制
CSV 最常用逗号（,），但也支持分号（;）、Tab（\t）、竖线（|）。为什么有这么多变体？因为不同地区的数字格式不同：美国用 1,234.56（逗号千位分隔、点小数），欧洲用 1.234,56（点千位分隔、逗号小数）。如果用逗号分隔字段，欧洲的数字就会被错误分割。所以很多欧洲系统用分号分隔字段，避免冲突。本工具 /csv-viewer/ 会自动检测分隔符：加载文件后扫描第一行，尝试逗号、分号、Tab、竖线四种分隔符，根据哪个产生最均匀的字段数量来判断。这对大多数 CSV 有效，但手写数据或特殊场景可能需要手动指定。
### 字段内含逗号与双引号转义规则
如果字段值本身含逗号，必须用双引号包裹整个字段。比如 "Smith, John", 25 中，第一个字段是 Smith, John（含逗号），用双引号保护它不被分割。更复杂的是字段内含双引号。RFC 4180 的规则是：字段内的双引号要用双双引号转义。比如说 say "hello", friend 这句话，在 CSV 中应该写成 "say ""hello"", friend"。开发者很容易搞错，比如只转义内部的引号 say "hello" 而不包裹整个字段，结果解析器就会崩溃。本工具的查看器会正确处理这些转义，显示的数据是已经反转义的。但导出时必须小心——工具应该自动转义，否则反向导入时就会出错。
### 编码陷阱：UTF-8、BOM、GBK 的大坑
CSV 的编码问题是最常见的坑。Excel for Windows 默认用系统编码（中文系统是 GBK，英文是 CP1252），导出的 CSV 就是 GBK 编码。如果用 UTF-8 编辑器打开，中文显示为乱码。反过来，用 UTF-8 导出的 CSV，在 Excel 中打开也是乱码。UTF-8 with BOM 是解决 Excel 兼容性的标准做法。BOM（Byte Order Mark）是文件开头的 3 字节标记（EF BB BF），告诉 Excel"这是 UTF-8 文件"，Excel 就会正确识别。很多在线服务（Google Sheets）导出的 CSV 都用 UTF-8 with BOM。所以，如果你的 CSV 要在 Windows Excel 中打开，务必导出为"UTF-8 with BOM"。本工具的上传器会检测文件编码。
### 大文件分页加载与浏览器内存限制
CSV 文件可以很大——几百 MB、甚至几 GB 的数据导出。浏览器无法一次性加载到内存。本工具用分页加载策略：只将可见范围的数据（比如前 500 行）加载到 DOM 中，用户滚动时动态加载下一批。这样即使文件几 GB，也能流畅浏览。技术上用虚拟滚动（virtual scroll）实现：浏览器只渲染当前可见的行，其他行用占位符（空白高度）代替，用户感知不到。这样几百万行的数据也能快速打开。但搜索、排序、筛选就复杂了——不能对整个文件做全量操作，必须逐块处理或用后端流式计算。本工具支持的排序和筛选是对当前加载的数据进行的。
### 排序、筛选与数据透视
本工具支持按列排序（升序/降序）、按关键字筛选行。点击列标题可以排序，输入框可以按列名或内容筛选。这些操作都基于当前已加载的数据（通常前 10000-50000 行），对超大文件会有延迟。一些 CSV 查看工具还支持简单的数据透视（pivot table）：按某列分组、统计另一列的总和或平均值。比如销售数据按产品分组、统计销售额，或按日期分组、统计交易笔数。但浏览器端的透视通常只支持简单场景，复杂透视（多维、多层次）还是要用数据库或 Excel。本工具暂未支持透视，但可以导出数据后用其他工具。
### 何时用 CSV vs Excel vs JSON vs 数据库直接导入
CSV 最适合表格数据的通用交换：因为 CSV 与任何电子表格软件兼容（Excel、Google Sheets、Numbers），也能被任何编程语言的 csv parser 读取。如果数据是扁平的二维表，行数不超过 100 万，CSV 是首选。Excel（.xlsx）更强大：支持多 sheet、格式化、公式、数据验证。如果数据需要复杂的格式或业务用户要修改，用 Excel。但 Excel 有 100 万行的理论上限（实际更低），超大数据不适合。JSON 适合嵌套或非表格数据：如果数据是树形结构（如配置文件、API 响应），用 JSON。CSV 无法表达嵌套。如果数据超过几百万行、或需要复杂查询，直接用数据库。
### 常见问题
**Q: Excel 导出的 CSV 在其他软件乱码，怎么解决？**
Windows Excel 默认导出 ANSI 编码（GBK 中文、CP1252 英文），不兼容 UTF-8。解决办法：Excel 中用"另存为"→ 选择"CSV UTF-8"格式（某些 Excel 版本会自动添加 BOM）。或者导出后用文本编辑器转换编码。Mac Excel 默认 UTF-8，通常不会乱码。最稳妥的做法是导出为"UTF-8 with BOM"。
**Q: CSV 文件没有扩展名，本工具能打开吗？**
可以。本工具根据文件内容检测格式，不依赖扩展名。只要文件内容是合法的 CSV（用逗号或其他分隔符），就能打开。但最好还是加 .csv 扩展名，便于浏览器识别 MIME type。
**Q: 导入 CSV 到数据库，字段映射错了怎么办？**
这是数据导入工具（如 MySQL Workbench、SQL Server 导入向导）的问题，不是 CSV 本身的问题。本工具可以先预览 CSV，确认字段顺序和内容正确，再进行数据库导入。或者先导入到 Excel 或 Google Sheets，在那里调整字段顺序，再导出后导入数据库。
**Q: CSV 中的日期格式不统一（2026-04-29 vs 04/29/2026），怎么处理？**
CSV 本身是文本格式，不理解日期。日期的解析由导入工具负责。Excel 和 Google Sheets 通常能识别常见日期格式，但如果格式混乱，导入时会出问题。最佳做法是在源头确保日期格式统一（推荐 ISO 8601 格式：YYYY-MM-DD）。如果 CSV 已经格式混乱，可以用 Python、JavaScript 的日期库批量转换。
**Q: 用本工具查看的大文件，会上传到服务器吗？**
本工具是纯客户端应用，所有数据处理在浏览器本地进行，不上传到任何服务器。隐私完全由用户掌控。但浏览器有内存和性能限制，超大文件（几 GB）仍然无法全量处理。
**Q: 如何快速找出 CSV 中重复的行？**
本工具暂未支持重复检测，但可以导出后用 Excel 的"条件格式→突出显示重复值"，或用 Python pandas: df.duplicated() 标记重复行。如果 CSV 很大，最佳做法是导入数据库，用 SQL 的 GROUP BY 或 ROW_NUMBER() PARTITION BY 识别重复。
---
## 抽签转盘完全指南：年会抽奖 / 决策犹豫 / 教学随机
> 从心理学解释到避坑指南，讲清楚在线转盘为什么能替代骰子、摇筒，以及如何用它科学公平地进行抽签决策。
URL: https://xtechtools.com/guides/lucky-draw/
发布：2026-04-29 · 更新：2026-04-29
人类面对超过三个选项时大脑就开始过载。从"晚餐吃什么"到"年会抽奖奖池怎么分配"，决策焦虑无处不在。这时一个看似简单的"转盘转一下"就能化解。本指南从心理学角度解释为什么转盘能减轻决策焦虑，揭示伪随机与真随机的区别，教你避开转盘使用的常见坑，并对比转盘、骰子、摇筒三种随机工具的优缺点。
### 为什么转盘能解决决策焦虑
心理学术语叫"选择过载（Choice Overload）"。人在面对 2-3 个选项时大脑最活跃，超过 5 个选项满意度反而下降——因为人脑的工作记忆容量有限。此时如果把决策权交给"第三方"（无论是骰子、转盘还是别人），参与者会感受到显著的焦虑缓解。这不是逃避，而是一种健康的"认知加载均衡"。
例如团建分组：10 个人自己分小组，每个人都在脑子里搭配组合，30 秒后还没决定。但让转盘随机分配，结果出来后反而没人怨言——因为"转盘决定了，我们就接受"。研究表明这种"外部归因"能显著降低事后的后悔程度。
### 伪随机 vs 真随机
**伪随机**：用计算机算法（如 Math.random）生成"看起来随机"的数字序列，实际上如果知道初始种子（seed）就能完全复现。Math.random() 的周期大约 2^32，足够日常应用，但不适合加密或严肃赌博场景。
**真随机**：完全不可预测，源头是物理现象（大气噪声、硬件放射源）。本站的转盘工具使用浏览器内置的 crypto.getRandomValues() API，背后是操作系统的随机数生成器（Linux /dev/urandom、macOS /dev/urandom、Windows CryptGenRandom），属于密码级随机数，远超伪随机。
**实际差异**：普通年会抽奖伪随机就够了，20 个奖品轮流出都很公平；但如果你的应用涉及数字货币、游戏金币等有经济价值的资源分配，必须用真随机或第三方公证。本工具默认用的 crypto API 属于企业级安全，足以应对所有常见场景。
### 避坑指南：转盘使用常见错误
❌ **错误 1：让某个选项重复出现**
假设有 A、B、C、D 四个奖品，但 A 的数量限制很多，运营想"偷偷增加 A 的概率"，就把 A 放两次。结果是 A 的中奖率从 25% 变成 33%，其他三项都被稀释。更坏的情况：有人中奖记录表上发现"A 出现了两次"，信任崩塌。解决方案是用权重，而不是重复。
❌ **错误 2：临时"内定"获奖者**
"我想让李四中一等奖"，然后在转盘抽奖时暗示李四去按按钮。这种"默契"很快会被员工察觉（尤其在视频转播年会时一眼就看出停止位置偏向），摧毁信任。年会抽奖一旦失信，来年参与度跳水。
❌ **错误 3：抽奖中途改规则**
"等等，这个人已经中过一次奖了，重新转一下"。一旦有人开始改规则，其他参与者会质疑之前的结果是否公平。规则一定要提前定好，中途不改。如果想规定"每人最多中一次"，就在转盘配置里设置不重复模式。
❌ **错误 4：显示过程太快或太慢**
转盘转得太快（0.5 秒就停了），观众会怀疑是"预设好的"；转得太慢（10 秒还在转），观众会觉得烦。标准的转盘转 2-3 秒比较舒适，既足够长给人"真实感"，又不浪费会议时间。
### 与其他随机工具的对比
| 工具 | 成本 | 速度 | 可见度 | 公平性 |
| --- | --- | --- | --- | --- |
| **物理转盘** | 50-500 元（定制品牌款更贵） | 1-2 分钟/次 | 全体可见，舞台感强 | 依赖硬件质量；某些偏心转盘可能有微妙偏向 |
| **摇筒抽号** | 200-800 元（体育竞技级） | 30 秒/次 | 中等可见，需要展示球 | 理论公平，但如果球大小/重量稍差会有偏向；场地需求大 |
| **骰子** | 5-20 元 | 5 秒/次 | 实物可见，个人化 | 理想骰子是公平的，但实物骰子微妙的制造误差会导致某个数字偏高 |
| **在线转盘（本工具）** | 免费 | 3 秒/次 | 电子屏幕显示，可投影扩大 | 密码级随机数，理论完美公平 |
| **点名 App** | 免费 | 1 秒/次 | 需要屏幕，无转盘视觉感 | 同样的密码随机数，只是表现形式不同 |
**选择建议**：
- 年会（重视舞台感、人多）→ 物理转盘或在线转盘投影
- 小组会议（速度优先）→ 在线转盘
- 教室点名（隐私考虑）→ 在线点名
- 竞技赛事（公证要求高）→ 摇筒（可邀请第三方监督）
### 教学场景：点名与概率验证
**点名的人性化**：传统点名本（按座位顺序翻页）学生早就摸透规律，会翘课。改成转盘随机点名后，学生的上座率显著提升——因为没人知道下一个会是谁。更重要的是这种随机性能训练学生的"时刻准备状态"，而不是"我算准了今天不会点我"。
**概率论入门**：用转盘做蒙特卡洛实验。例如，设置转盘分成 6 等份（对应骰子），让学生转 60 次，统计每个数字出现多少次。理论上均匀分布，每个数字约 10 次；实际数据会有波动。这个实验生动地展示了"有限样本的随机性"和"大数法则"。如果转 600 次、6000 次，分布会越来越接近理想比例。
**决策伦理讨论**：用转盘给出一个随机结果，然后问学生"你接受吗？为什么？"。这开启了关于公平性、规则、权力的深度讨论。例如转盘指定了"下节课额外作业"的人，这个人会接受吗？研究表明，只要过程是透明的（所有人都知道规则，转盘公开），结果再不利也容易被接受。
### 年会抽奖的概率设计
年会抽奖最常见的需求是"一等奖 1 个、二等奖 3 个、三等奖 10 个"，共 200 人参赛。怎么用转盘实现？
**方案 A：多轮转盘（推荐）**
第一轮只有 1 个蓝色格子（中一等奖的 1 个人），199 个白色格子（未中）。中奖者退出。
第二轮只有 3 个红色格子（中二等奖的 3 个人），196 个白色格子。
第三轮 10 个绿色格子（中三等奖的 10 个人），186 个白色格子。
优点：每轮参与者数量递减，最后一轮速度快；每个人的最终概率是精确的（第一轮 1/200 中一等奖 = 0.5%）。
**方案 B：权重方案（快速）**
一个转盘，分 200 个等份，其中 1 份标记"一等奖"，3 份标记"二等奖"，10 份标记"三等奖"，186 份标记"安慰奖或未中"。直接转，一轮定胜负。
缺点：权重越复杂，二维码或界面越难看懂；某些人可能会数格子质疑公平性。但速度快。
**实务建议**：200 人的年会，多轮转盘总耗时不超过 15 分钟，各部门有精神头继续开会或聚餐；一轮快速转盘虽然总耗时 30 秒，但可能引发猜疑。所以除非是"现场直播全网看"的大型活动需要快速，否则多轮透明的方案更稳妥。
### 防作弊与公证
**转盘能被"作弊"吗？**
在线转盘（密码随机数）理论上无法人为操纵——你无法预测下一个数字。但可能的风险包括：
1. **网络延迟**：如果转盘是服务端生成（不是本地浏览器），网络延迟可能被利用。本工具使用本地浏览器随机数，天生防护。
2. **浏览器开发者工具**：有人打开 DevTools 尝试读取随机数 seed？没用，crypto.getRandomValues 的 seed 不暴露。
3. **计算机控制转盘位置**：如果你控制了展示转盘的设备（电脑、投影机），理论上可以预设结果。但这时已经超出"工具本身"的范畴，属于硬件层面的欺骗。
**公证方案**：
- 年会现场邀请一名员工代表全程监督，确认规则、见证转盘操作。
- 如果是线上转盘，邀请代表进行屏幕共享观看。
- 转盘过程全程录视频，会后员工可查看回放。
- 对于大奖项（涉及现金或高价值奖品），可邀请第三方公证机构（某些地区提供"转盘公证"服务）。
多数情况下第一条（人工见证）就足够了。透明度 > 技术安全，人的眼睛看到的"公平操作"比算法保证更有说服力。
### 常见问题
**Q: 转盘有多公平？能不能作弊？**
在线转盘使用密码级随机数（crypto.getRandomValues），理论上完全无法预测或操纵。但公平性最终取决于"操作人是否值得信任"——所以年会现场邀请员工代表全程监督最重要。
**Q: 年会 200 人抽奖用转盘要多久？**
多轮方案（一等奖转一次、二等奖转一次...）总耗时 10-15 分钟，包括念获奖者名字和掌声。一轮快速方案只需 30 秒，但可能引发猜疑。建议多轮。
**Q: 能否让某个人"更容易中奖"？**
可以，但不要偷偷做。如果想给特殊员工倾斜，提前告诉全部参与者"X 部门员工额外一次转盘机会"或"新入职员工保底二等奖"。透明度解决所有问题。
**Q: 转盘和骰子哪个更公平？**
理想情况下一样公平。但实物骰子受制造工艺限制，某些面可能微妙偏重；在线转盘没有这种物理约束，所以理论上更完美。但实践中，人们对"能看见的物理骰子"的信任度更高。
**Q: 能用转盘做彩票抽奖吗？**
本工具不适合涉及赌博、金钱的应用。如需实现合规的彩票系统，请咨询专业机构或使用政府认可的彩票系统，通常需要第三方公证。
**Q: 转盘支持多少个选项？**
理论上无限，但超过 50 个选项转盘会很密集，二维码也会很复杂。实践上 30 个以内最适合。
---
## 随机分组完全指南：团建 / 课堂 / 项目协作
> 从 Fisher-Yates 真随机算法到平衡分组策略，讲清楚如何科学公平地给团队分组，避免"关系户"抱团和人才搭配失衡。
URL: https://xtechtools.com/guides/team-picker/
发布：2026-04-29 · 更新：2026-04-29
分组看似简单，实际蕴含大量逻辑——10 个人分成两组，表面上有超过 9 万种不同的分法。如果用 sort(Math.random()) 这种伪随机方法来分，某些配置会反复出现（聚类现象）。更要命的是，如果分组涉及人才搭配（比如项目小组要技术强手配新手），简单随机分组会导致某个小组人才高度聚集，另一个小组全是新手。本指南讲清楚真正的随机分组算法（Fisher-Yates），以及如何在随机基础上加入平衡约束（人才均衡、固定搭档、避免敌人同组）。
### Fisher-Yates Shuffle：理解真随机分组
JavaScript 里很多人这样写分组：
const shuffled = array.sort(() => Math.random() - 0.5);
这**完全错误**。为什么？因为 sort() 的内部实现（快排或归并排）对不同比较函数的调用有特定顺序，而 Math.random() - 0.5 产生的伪随机数不符合 sort 的"传递性"假设。结果是：某些元素反复被交换，某些元素被略过，最终分布严重不均。
**正确方法：Fisher-Yates Shuffle**
for (let i = arr.length - 1; i > 0; i--) {
const j = Math.floor(Math.random() * (i + 1));
[arr[i], arr[j]] = [arr[j], arr[i]];
}
这个算法保证每种排列的概率相等（1 / n!），真正做到了完美随机。本工具的分组底层使用此算法或同等的密码随机数洗牌。
**实际差异**：10 个人，sort(Math.random()) 可能让 A、B、C 三个关系户连续排在前三名（概率虽低但能发生）；Fisher-Yates 保证任何三个人在"分组后恰好同一小组"的概率完全相等，无偏无倚。
### 平均分配 vs 固定每组人数
**平均分配**："10 个人分成 3 组"，工具自动分配成 4、3、3。
- 优点：简单、无需手动指定
- 缺点：如果组数无法整除，必然有组人数不同（3 组 10 人 → 必然 4/3/3）
**固定每组人数**："分成若干组，每组必须 3 人"。10 个人最后成 3 组 + 1 人无法分配。
- 优点：每组规模一致，便于分配同样的任务
- 缺点：某些人可能无法分入任何组（必须调整总人数或组数）
**实务建议**：
- 团建破冰分组 → 用平均分配（7 个人分成 3 组可以 3/2/2，灵活）
- 项目开发分组 → 用固定每组 3 人（每个小组配置一样：1 个 leader、2 个成员）
- 教学小组实验 → 固定每组 4 人（刚好一台显微镜、一套实验装置）
本工具支持两种模式，选择时考虑"任务是否对组大小敏感"。
### 人才平衡分组：搭配强弱
简单随机分组的问题：12 个学生参加编程竞赛，3 个技术大牛如果全进同一组，其他三组的同学怎么活？
**方案：轮流分配**
1. 对所有人做"能力评分"（1-5 分，或技能标签）。
2. 按评分排序（从高到低）。
3. 第一个人分到第 1 组，第二个人分到第 2 组，第三个人分到第 3 组，第四个人又分回第 1 组，如此往复（"蛇形分配"或"轮转分配"）。
结果：每组都有 1 个强手、若干中等生、若干弱手，搭配均衡。
**进阶：基于技能矩阵**
如果有多个维度（如 Python、JavaScript、系统设计、沟通能力），可以构建一个简单的评分矩阵：
| 成员 | Python | JS | 系统设计 | 总分 |
| --- | --- | --- | --- | --- |
| A | 5 | 3 | 4 | 12 |
| B | 4 | 4 | 2 | 10 |
| C | 2 | 5 | 3 | 10 |
| D | 2 | 2 | 2 | 6 |
用"总分轮转"分组，或更细粒度地用"确保每组至少有 1 个 Python 高手"的规则来分。
**本工具功能**：在"添加成员"时可打标签（如 @Senior、@Junior），工具能帮你快速看每组的标签分布是否均衡。
### 固定搭档与"不能同组"约束
**场景 1：夫妻档必须同组**
公司年会团建，有三对夫妻参加（共 6 人）加 4 个单身同事，共 10 人分成 2 组。
- 解决方案：把每对夫妻看作一个"单元"，而不是拆散的个体。10 人 → 5 个单元 → 分成 2 组。结果是某组 2 个单元 + 1 个单身，另一组 2 个单元 + 1 个单身。
- 本工具支持"团队模式"，可以把多个人标记为一个小组，分组时保持他们在同一大组。
**场景 2：两个人关系不好，不能同组**
团队中 A 和 B 有冲突，分组时要避免他们在一个小组。
- 简单方案：先用 Fisher-Yates 随机分组，检查 A 和 B 是否同组，如果同组就重新打乱。但这违反了"严格随机"的原则，容易引发不满（如果第 3 次重新分组恰好把某个人排出好位置，此人会怨言）。
- 更好方案：用约束满足（CSP）求解，确保一开始的分组就不包含这种冲突。但这对一般工具来说太复杂。
- 实务建议：把"不能同组"的人事问题上报给管理者，分组工具本身不应该成为"隐瞒冲突"的工具。如果分组工具被用来躲避团队问题，迟早还是会爆发。
本工具的做法：支持"黑名单模式"（A、B 之间连一条禁止线），算法尝试生成满足约束的分组。如果无法满足（比如 3 个人互相冲突，必然有两个在一组），工具会提示"约束过多，无法分组"。
### 教学场景：轮换分组与长期搭配
**轮换分组（鼓励交流）**
小学数学课，全班 30 人，每单元做一次分组讨论（小组 4 人）。如果每次都用同样的分法，某些内向的孩子可能被边缘化；如果每次都彻底随机，孩子们互相不熟悉，协作效率差。
**最佳实践：定期轮换（每两周或每个单元更换一次）**
- 第一单元：用本工具随机分组，孩子们磨合。
- 第二单元：生成一个"不同的随机分组"（工具记住第一次的分法，确保本次分组尽可能和上次不同）。结果是每个孩子在不同单元和不同同学搭档，扩大社交圈，但又给予足够的稳定性。
**长期项目搭配（稳定性优先）**
高中物理小组实验，全年要做 10 个实验。如果分组频繁变化，孩子们团队凝聚力差。
**最佳实践：季度轮换**
- 第一季度：第一次随机分组，4 个实验在这个组里
- 第二季度：生成新的随机分组（打乱第一季度的队伍，但保留部分"因果"），4 个新实验
这样既避免了全年不变导致的陈腐感，又给予了足够的团队建设时间。
**老师的权限**：本工具支持"草稿模式"，可以手动调整分组结果后再发布。如果某个分组看上去有明显的"能力失衡"（比如全新手在一组），老师可以拖动成员调整，而不是非要信任算法。
### 年会团建破冰分组的技巧
年会团建，目标是打破部门壁垒，让陌生人互相认识。此时随机分组是最好的选择，因为：
1. **破坏旧有关系**：避免同部门的人聚在一起，强制"跨部门交流"。
2. **营造公平感**：没人能说"分组对我不利"，因为是机器随机的。
3. **节省时间**：不用人工分组，不用听各种协商和怨言。
**最佳流程**：
1. 提前一周发起报名，收集所有参与者名单和部门（可选）。
2. 活动当天，在大屏幕上投影分组工具的"部门均衡模式"（确保每组都有来自不同部门的人）。
3. 点击"开始分组"，大屏幕动画显示洗牌和分组过程（视觉上让人相信是真随机）。
4. 分组完成后，立即公布结果（大屏幕 + 微信群邮件通知）。
5. 各小组组长自我介绍，确认成员，然后进行团建活动。
**动画设计**：转盘转 2-3 秒、人名飘落、最后在四个区域收集 — 这种"视觉随机化"比冷冰冰的表格更能让人相信公平性。本工具的界面考虑了这一点。
**敏感考虑**：
- 如果公司有"禁止同组人员"（比如项目机密组不能和其他部门同组），提前告诉工具配置黑名单。
- 如果某个员工身体残障需要特定的组位置（如靠近门口方便轮椅进出），分组后手动调整即可。
- 如果某些人因故无法参加，分组时去掉他们的名字，活动当天再临时补充。
### 算法与公平：为什么分组结果看起来都一样
有人会问："我用你的工具分了两次组，为什么结果都是 A、B、C 一组、D、E、F 一组……？"
**原因 1：样本量小**
5 个人分成两组，理论上有 C(5,2)/2 = 10 种本质不同的分法。如果用工具分 10 次，确实可能看到同样的结果。这不是 bug，是概率论。
**原因 2：密码随机数的周期性**
crypto.getRandomValues() 使用系统的随机源（/dev/urandom），周期极长，日常不会重复。但如果你在极短时间内（同一毫秒）连续调用两次，操作系统的随机源可能还没刷新，会返回相同的数字。本工具的做法是加入"时间戳混淆"和"计数器"确保即使快速连续调用也会产生不同结果。
**原因 3：期望心理**
人脑对"完全不同"有很高的期望。如果你手动分组 10 次，其中有两次巧合地相同，你会记得这两次；其他 8 次不同的你会忽视。这叫"可用性偏差（Availability Bias）"。
**验证工具的公平性**：
本工具支持"统计模式"，可以一次性分组 1000 次，统计每个人在"第 1 组"出现的次数。如果是公平的，每个人出现频率应该约等于 1/N（N 为组数）。例如 10 人分 2 组，每人在第 1 组的频率应该约 50%。
### 常见问题
**Q: 随机分组能避免"关系户"抱团吗？**
能。Fisher-Yates 算法保证任何两个人同组的概率相等，无法人为操纵。但如果你人为预设"不能同组"的约束，那就是在作弊。
**Q: 多少人的团队适合用分组工具？**
5-100 人都可以。5 人以下分组意义不大；超过 1000 人可能需要考虑服务端分组（本工具是浏览器端，只受内存限制）。
**Q: 分组后能否手动调整？**
可以。分组工具产出的是"建议"，老师或组织者可以手动拖动人员调整，以实现教学或项目目标。重点不是"绝对随机"，而是"可验证和可调"。
**Q: 固定搭档会降低随机性吗？**
会，但这是特意设计的约束。把夫妻档视为一个单元去分组，仍然是公平的（每个单元出现在任何组的概率相等）。
**Q: 为什么我分了两次却看到了同样的分组？**
小样本的巧合。5 人分 2 组只有 10 种理论分法，重复率自然高。可以用工具的"统计模式"验证：分组 100 次，每个人在第 1 组出现的频率应接近 50%。
**Q: 线上课堂可以用随机分组做分组讨论吗？**
可以。本工具生成的分组可复制到 Excel / 微信群，或导出二维码让学生用手机扫描看自己被分到哪组。支持多种输出格式。
---
## 在线骰子模拟器完全指南：TRPG / 教学 / 概率验证
> 讲清楚标准骰子的来源、TRPG 系统的骰子规则、伪随机与真随机的数学差异，以及如何用骰子模拟器进行概率实验。
URL: https://xtechtools.com/guides/dice-roller/
发布：2026-04-29 · 更新：2026-04-29
从《冰与火之歌》到《龙与地下城》，从平民赌局到考古学课堂，骰子承载了 5000 年的随机决策历史。但互联网时代，物理骰子已经被在线模拟器取代。本指南讲清楚骰子的数学原理、标准骰子（D4 到 D20）的来历、最受欢迎的三大 TRPG 系统如何使用骰子、伪随机与真随机的本质区别（和为什么在线工具的随机数其实比实物骰子更可靠），以及如何用骰子做概率验证实验。
### 标准骰子的演进史
**古代骰子**：古埃及和古罗马的骰子是不规则的骨块（多面体），本质是农业社会对"神意"的模拟——用随机结果来替代祭司的决断。
**正多面体的数学发现**：欧几里得证明了只有 5 种"正多面体"（所有面都是相同正多边形）：
- 正四面体（4 个面）→ D4
- 正方体（6 个面）→ D6（最常见的骰子）
- 正八面体（8 个面）→ D8
- 正十二面体（12 个面）→ D12
- 正二十面体（20 个面）→ D20（最流行的 TRPG 骰子）
加上 D10（2 个正五棱锥）和 D100（标记百位的大 D10），这 7 种骰子覆盖了从 4 到 100 的所有常见数值。
**概率学角度**：物理骰子理想上应该每个面出现概率都是 1/N（N 为面数）。但制造工艺有偏差——廉价骰子因为重量分布不均，某些面出现频率偏高；专业骰子（手工打磨、用名贵材料）花费 50-200 元才能达到接近理想的分布。在线骰子完全没有这种物理制约，所以"公平性"其实更高。
### TRPG 系统中的骰子规则
**系统 1：龙与地下城（D&D）5e**
核心检定（Attack Roll、Ability Check 等）是 `1d20 + 修正值`。
例如士兵攻击怪物，骰 1d20（结果 1-20）加上力量修正（+3），总命中 4-23。目标防御等级（AC）是 15，所以需要掷出 12 或更高才能命中。
特殊动作"优势（Advantage）"意为掷两个 d20 取高值，"劣势（Disadvantage）"取低值。
本工具支持 `1d20+3` 这样的标准语法和 `2d20kh`（掷 2 个 d20，取最高的）这样的符号。
**系统 2：克苏鲁的呼唤（Call of Cthulhu）7e**
核心是 `1d100` 对比技能值。例如调查技能 50%，掷 1d100 如果 <= 50 就成功。
难度分级：
- 常规（Routine）：75% 的角色容易成功
- 困难（Hard）：20% 成功
- 极限（Critical）：5% 成功
需要掷 1d100 验证结果。
**系统 3：怪物猎人世界（MHW）— Monster Hunter**
虽然不是传统 TRPG，但游戏内的伤害计算是 `基础伤害 × (1 + 缓冲值随机) × 会心率`，涉及复杂的随机分布。爱好者用本工具的多骰模拟来计算平均伤害。
**通用语法**（本工具支持）：
- `3d6`：掷 3 个 d6，求和（骰龙与地下城的属性：6 个 3d6）
- `2d10+5`：掷 2 个 d10 再加 5
- `4d6kh3`（keep highest 3）：掷 4 个 d6，去掉最低的，只算最高的 3 个（龙与地下城属性的标准方法）
- `1d100>=50`：掷 1d100，检定是否 >= 50（克苏鲁检定）
- `3d8!`（exploding dice）：掷 3 个 d8，如果出现 8，再额外掷一个 d8 加到结果（火焰之纹徽章 Fateless 系统用）
### 伪随机 vs 真随机的数学原理
**伪随机（Pseudo-Random）**：用数学公式从一个初始值（种子）生成看似随机但完全确定的数列。
JavaScript 的 Math.random() 使用 xorshift128 或 MersenneTwister 这样的算法，周期约 2^32（40 亿）。如果你知道初始种子，可以完全复现整个序列。
**真随机（True Random）**：完全不可预测，源头是物理现象。操作系统的 /dev/urandom（Linux）、Fortuna（macOS）、CryptGenRandom（Windows）都采集大气噪声、硬件时钟抖动、磁盘 I/O 定时等物理随机源，混合后产生不可预测的随机数。
**数学检验**：用 Diehard 或 NIST 统计测试检验随机数流是否均匀分布。
伪随机数流 Math.random() 理论上通过 Diehard，但在某些参数下容易暴露周期性（比如连续取偶数位，会发现有明显的规律）。真随机数流总能通过，因为它没有周期性。
**实务影响**：
- TRPG 用途：掷骰子 100 次，伪随机和真随机的结果在统计上无法区分。双方都是公平的。
- 密码学用途：如果用伪随机数生成加密密钥，黑客知道种子就能破解。必须用真随机。
- 游戏内部伤害计算：游戏引擎（如 Unity、Unreal）通常用伪随机，因为速度快且足够公平。但涉及金钱奖励的在线游戏必须用真随机并有第三方审计。
**本工具的选择**：使用浏览器的 crypto.getRandomValues()，属于真随机级别。在 TRPG 直播中掷骰子使用本工具 > 实物骰子，因为观众无法质疑"随机的公平性"。
### 概率分布与多骰模拟
**单个 d6 的分布**
掷一个 d6，每个数字的概率都是 1/6 ≈ 16.7%。图表是平坦的一条线。
**两个 d6 相加的分布（如龙与地下城的 2d6+X）**
结果范围 2-12，但分布是三角形的：
- 2 的概率：1/36（只有 1+1）
- 7 的概率：6/36（1+6, 2+5, 3+4, 4+3, 5+2, 6+1）— 最常见
- 12 的概率：1/36（只有 6+6）
**三个 d6 相加**
结果 3-18，分布更接近"钟形曲线"（高斯分布）。
**为什么重要**：某个 TRPG 系统规定"掷 3d6 表示角色的力量属性（3-18），平均 10.5"。如果你想要"力量分布更离散"（某些角色特别强，某些特别弱），就改成 2d6+某个修正，分布会从 3-18 变成 2-14（范围变小）。
**蒙特卡洛模拟**：
你的角色每次攻击是 `1d20+5 vs AC 15`，成功率是多少？
手工计算：掷 1d20 的结果 1-20，加上 5 变成 6-25，只要 >= 15 就命中。所以 15-25 共 11 个数值，概率 11/20 = 55%。
用骰子工具验证：设置 `1d20+5>=15`，掷 1000 次，统计成功的比例。理论 55%，实测应该约 55%（100 次波动 ±5%，1000 次波动 ±1.5%）。
**进阶用法**：某个 TRPG 系统特别复杂，公式涉及多个条件（如 `if roll >= 10 then 3d6 else 1d6`），手工计算期望值太麻烦，直接用本工具的"统计模式"模拟 10000 次，看平均伤害是多少。
### 实物骰子与在线骰子的对比
| 属性 | 实物骰子 | 在线骰子 |
| --- | --- | --- |
| 制造成本 | 5-200 元（廉价到专业级） | 免费 |
| 公平性 | 廉价骰子常有微妙偏向；专业骰子接近完美 | 完美（密码随机） |
| 可见性 | 高（观众眼睛能看到滚动） | 中等（屏幕动画有视觉反馈，但原理是黑盒） |
| 作弊风险 | 廉价骰子容易被精心设计偏向；专业骰子几乎无法人为操纵 | 如果服务端生成很容易作弊；如果本地浏览器生成几乎无法作弊 |
| 诚信要求 | 取决于骰子质量和操作人 | 取决于工具的代码透明度 |
| 网络/线下 | 线下（需要物理骰子） | 线上和线下混合 |
**为什么有人还用实物骰子**：
1. **传统感与仪式感**：掷骰子的动作（握拳、摇晃、放开）有心理安慰作用，好像"我在主动影响结果"。在线工具看起来太冷漠。
2. **可验证性**：观众能亲眼看到骰子滚动，很难质疑。在线工具虽然底层可能更公平，但观众需要"信任代码"。
3. **脱网需求**：没网络时实物骰子还能用。
**为什么在线骰子更优**：
1. **真随机保证**：密码级随机数 > 普通骰子。
2. **无限骰子**：不需要把 D20 掷多次来模拟 20d20，直接点击生成。
3. **复杂表达式**：`2d20kh1` 或 `3d6+1d4+5` 这样的复杂骰法在在线工具一行代码搞定，实物骰子需要掷多次累加。
4. **统计与存档**：所有掷骰结果可自动记录，便于事后分析。
5. **直播友好**：在线直播时物理骰子画质差、看不清，在线工具可投影放大。
**最佳实践**：TRPG 线下面对面游戏，用实物骰子（体验感强）；线上游戏或竞技赛（需要公证），用在线工具（公平性强）。
### 教学场景：概率论入门与蒙特卡洛方法
**高中数学：理解二项分布**
"抛硬币 10 次，出现 5 次正面的概率是多少？"
理论计算：C(10, 5) × 0.5^10 ≈ 24.6%。
用骰子工具验证：创建一个表达式 `1d2`（D2 表示硬币，出现 1 或 2），掷 10 次，看有多少次掷出特定结果。重复 1000 轮实验，统计"恰好 5 次"的轮数，应该约 240 轮（24%）。
学生亲手验证了理论值，比单纯背公式印象深刻 100 倍。
**大学统计：蒙特卡洛模拟求圆周率**
这是经典算法：在 1×1 的正方形内随机投点，落在圆内的点数与总点数的比值约等于 π/4。
掷 10000 次 (1d100, 1d100) 作为坐标
统计有多少个点的距离 sqrt(x^2 + y^2) <= 100
比例 × 4 ≈ π
本工具虽然不是专门为这个设计，但可以被创意地使用来生成随机点坐标，然后用电子表格计算。
**物理学：粒子碰撞模拟**
某个粒子衰变成多个产物，产物的动量和能量分布遵循量子力学的概率规则。模拟时需要掷大量的随机骰子来决定产物的方向和能量。本工具的"批量掷骰"和"统计模式"是进行这类模拟的基础。
**经济学：赌博与期望值**
"掷 1d20，如果 >= 10 你赢 100 块，否则输 50 块。值得参加吗？"
期望值 = 0.55 × 100 + 0.45 × (-50) = 55 - 22.5 = 32.5 块（正期望，划算）。
用工具掷 1000 次，累计你的净收益，应该约为 32500 块（期望值 × 1000）。实际会上下波动，但趋势是向上的。
学生用工具模拟后，更深刻理解了"虽然每次赌博有风险，但大量重复后数学期望会兑现"。
### 避坑指南与诚信问题
❌ **错误 1：掷骰子决定重要事务时作弊**
你和朋友掷骰子决定"谁付账"，暗地里用一个两面都是 6 的骰子。这短期可能赢钱，但一旦被发现信任彻底破裂。骰子决策的全部价值在于"接受结果"的能力，一旦你违反规则，这个游戏就毁了。
**建议**：使用本工具的在线骰子。完全公开、不可操纵、有记录。这样任何人都无法作弊。
❌ **错误 2：混淆"掷骰数"和"骰子概率"**
"我掷了 20 次 d6，平均每次出现 3.5，所以最多再掷 20 次就能保证出现一个 6。"
错。每次掷骰都是独立事件，过去的结果不影响未来。掷过 100 次都没出现 6 的 d6（理论上虽然概率极低），下一次掷出 6 的概率仍然是 1/6。这叫"赌徒谬误（Gambler's Fallacy）"。
**正确理解**：d6 掷 600 次，会有约 100 次出现 6（期望 1/6）。但这不是"保证"，波动在 ±10 是正常的。
❌ **错误 3：某些 TRPG 场景的"秘密掷骰" 变成"秘密作弊"**
地下城主说"我秘密掷骰来决定怪物的行动"，然后总是让怪物做出对玩家不利的行动。玩家逐渐感觉到"好像 DM 在作弊"。
**解决方案**：即使是"秘密信息"的掷骰，也应该在所有参与者面前进行（或由信任的第三方见证）。本工具可以用"隐藏结果"功能，确保掷骰过程透明但结果先不公开。
✅ **最佳实践**：
1. 提前明确"用什么工具掷骰"（实物、在线还是混合）。
2. 如果用在线工具，选择"开源"或"有审计报告"的版本（确保代码没有暗门）。
3. 如果是涉及金钱的游戏，邀请第三方或组织方公证。
4. 掷骰过程尽可能透明（直播、录视频、多人见证）。
5. 接受结果，即使对你不利。这是掷骰游戏的核心——承认"随机"的权威性。
### 常见问题
**Q: 在线骰子比实物骰子更公平吗？**
理论上是。实物骰子受制造工艺影响，廉价骰子往往某些面出现概率偏高；在线骰子使用密码随机数，理论完美公平。但实际上公平性也取决于"人们对工具的信任度"。
**Q: D20 的概率是多少？**
D20 每个面出现概率都是 1/20 = 5%。掷 1d20>=10 的成功率是 55%（11 个成功的数值）。掷 2d20kh1（优势）的成功率会更高，约 80%。
**Q: 怎样用骰子模拟不公平的概率？**
例如"掷 1d20，如果 >=15 就成功，成功有 80% 的收益和 20% 的惩罚"。用表达式 `if (roll >= 15) then 80% else -20%` 来表示，本工具的高级模式支持条件语句。
**Q: TRPG 里的"爆骰"是什么？**
某些系统规定：掷 d6 如果出现 6，可以再掷一个 d6 加上去。如果再出现 6，继续掷。这样某次攻击可能掷出远超 6 的伤害（如 6+6+3=15）。本工具用符号 `1d6!` 表示爆骰。
**Q: 能用骰子决定人生大事吗？**
可以，但要理解你在做什么。掷骰决策实际上是"我愿意接受随机的结果"，这种心态对解决某些优柔寡断的情况很有效。但重大人生决定（如换工作、结婚）建议结合理性分析，而不是完全靠骰子。
**Q: 掷骰 100 次和掷骰 1000 次结果会一样吗？**
不一样。掷 100 次结果会有较大波动；掷 1000 次会更接近理论分布。这叫"大数法则"—— 样本越大，实验结果越接近理论概率。
---
## 斗地主记分规则完全指南：底分 / 倍数 / 春天反春
> 斗地主三人玩法、底分约定、倍数计算（炸弹 / 王炸 / 春天反春 / 明牌），地主胜负结算公式，以及各地区规则差异与本工具的电子化优势。
URL: https://xtechtools.com/guides/doudizhu-score/
发布：2026-04-29 · 更新：2026-04-29
斗地主是中国最流行的三人纸牌游戏，已有 20 多年历史。一局三五分钟内分出胜负，但"倍数"规则让人费脑子——底分 1 块还是 2 块？炸弹翻几倍？春天反春加不加？同样赢一局，地主要赚多少、农民要亏多少，往往记账时吵得不亦乐乎。本指南讲清楚斗地主的所有计分逻辑，包括三人身份、底分约定、倍数计算与加成规则、最高倍数上限、标准规则、地区变体（四川 vs 北京 vs 江苏 vs 广东），以及用本工具实现电子记分的便利性。
### 斗地主的基本玩法与身份
斗地主由三人参与：一人当地主，另两人合作的农民。
**身份分配**：抢地主阶段，通过"抢"或"不抢"决定。地主比农民多摸 3 张牌（底牌），但是单挑对抗，需要一个人打败两个人。
**胜负条件**：
- 地主先出完手牌 → 地主胜
- 地主没出完手牌，另两家都出完 → 农民胜
一局决出胜负后，根据倍数计算金钱，本指南重点就在这里。
### 底分与基础月供规则
底分是每局游戏的基础赌注，由玩家事先约定。常见约定：
- **1 块底分**：轻松休闲的约局，通常朋友聚会
- **2 块底分**：正常强度的周末麻将牌桌级别
- **3 块底分**：比较紧张的较真局，可能因为有新手或牌技差异
底分的含义：如果游戏没有任何倍数加成（无炸弹、无春天、无明牌），那地主胜时农民各给地主 1 块；农民胜时地主给农民各 1 块。
**地主胜结算**：地主得 +N（N = 底分 × 总倍数），每个农民得 -N
**农民胜结算**：地主得 -2N，每个农民得 +N
### 倍数加成规则详解
倍数是叠加乘算，不是相加。多个倍数出现时相乘而非相加。
**常见倍数加成**：
- **炸弹（一颗）**：四张同点数（如 4 个 7）×2 倍。一局可能出现多个炸弹，每个都 ×2
- **王炸**：双王（大王 + 小王）×2 倍（有些地区 ×4）
- **春天**：地主一方的农民都未出过牌时，地主一次出完所有牌 → ×2 倍
- **反春**：地主剩余手牌，农民都没出过 → ×2 倍（与春天互斥）
- **明牌**：地主翻牌时亮出所有底牌 → ×2 倍
例如：一局有 2 个炸弹 + 王炸 + 春天，倍数 = 2 × 2 × 2 × 2 = 16 倍
### 地区差异与规则变体
中国不同省份的斗地主规则存在显著差异：
**四川版**：流行于成都、重庆一带。春天反春规则最严格，明牌通常 ×3；王炸常见 ×4。
**北京版**：相对保守。通常无明牌规则，春天反春 ×2，王炸 ×2，单个炸弹 ×2。
**江苏版**："抢分"概念，农民可在地主出牌时"抢"宣布抢分加倍。
**广东版**：引入"硬炸"概念（4 张牌一起出），倍数翻倍。
**线上麻将房**：为避免风险，往往简化规则（禁明牌、禁春反春），倍数上限 256 或 512。
本工具支持自定义规则，玩家可在首局前设定本圈子的约定，工具自动应用。
### 最高倍数上限与风险管理
一局如果倍数无限叠加，可能产生天文数字的赌金。为避免极端情况：
- **无上限**：豪赌圈子，倍数可达数千甚至数万倍（极端罕见）
- **256 倍上限**：常见的小赌圈约定
- **512 倍上限**：中等强度的玩家小组
- **1024 倍上限**：线上平台常用的折中方案
本工具提供可配置的上限，防止倍数溢出导致结算错误。即使触发上限，工具仍准确显示无上限倍数供参考。
### 本工具的电子记分优势
传统纸笔记分的痛点：
- 倍数多时容易算错（尤其是 2^n 的乘法）
- 多局累计时易漏加
- 地区规则切换需要脑算规则映射
- 事后争议难以查证
本工具的优势：
- 自动计算倍数乘算，支持自定义规则库（四川 / 北京 / 江苏模板）
- 逐局记录并可导出，每局数据可追溯
- 实时显示当前赛季总排行、人均赢分率
- 手误可一键撤销，避免重新计算全局
- 支持多人多局的累计，适合长期麻友小组
### 常见问题
**Q: 炸弹和王炸能叠加吗？**
完全可以。一局既出现炸弹又出现王炸的情况下，倍数相乘。例如 1 个炸弹 ×2、王炸 ×2 → 总 ×4。
**Q: 春天和反春能同时算吗？**
不能。春天是地主一次出完，反春是农民都未出。两者互斥，只能选一个加倍。
**Q: 底分 1 块打了 10 局，共赢了 20 局、亏了 10 局，怎么结算？**
本工具会逐局累加。假设 10 局赢分分别为 +2、+4、+8...，工具自动求和得总收益。无需手工计算。
**Q: 不同地区约定规则，工具能保存几套方案吗？**
支持。工具内置四川、北京等常见模板，也可自建"自定义"方案，保存 IP 本地。切换时一键导入。
**Q: 明牌规则各地倍数不同，怎么办？**
本工具的倍数配置是自定义的。创建方案时明牌明确是 ×2 还是 ×3，确认无误后保存即可。
---
## 掼蛋升级规则完全指南：从 2 打到 A 的路径
> 掼蛋四人两队对抗、等级制进度（从 2 到 A）、升级条件、过 A 的两道关卡、炸弹识别、地区版本差异与本工具电子记分的优势。
URL: https://xtechtools.com/guides/guandan-score/
发布：2026-04-29 · 更新：2026-04-29
掼蛋（又作"贯蛋"）是江苏、安徽最流行的四人对抗纸牌游戏，因等级制、复杂升级路径和激烈对战而风靡棋牌室与办公室。与斗地主一局数分钟不同，掼蛋一个"轮"可能要打十来局才能分出升级者——每赢升一级、每输降一级。到了"K 级"还要再过两道关（先打 A、再过 A）才能成为最高级"A 级"。本指南详解掼蛋四人两队对抗机制、升级条件（双升 / 单升 / 落地升）、炸弹倍数计算、K 级两关规则、地区版本差异，以及本工具自动追踪等级进度的优势。
### 掼蛋的基本玩法与四人两队
掼蛋四人一桌，分为两队对抗。通常坐法：1 号 + 3 号为一队，2 号 + 4 号为另一队。
**牌牌组成**：去掉大小王的 52 张牌（从 2 到 A）。4 个 2 最小，4 个 A 最大。
**每人获牌**：各发 13 张，剩余 0 张无底牌。
**等级与主牌**：游戏有 13 个等级（2、3、4、5、6、7、8、9、10、J、Q、K、A）。当前等级为"主等级"，对应点数的所有牌（如主等级 5，则 4 个 5 都是最大牌）为主牌。此外当前等级的花色也是主花色。
### 升级条件与晋级机制
掼蛋的进度由胜负直接决定。一局游戏后：
**队伍胜利**：该队的两个"先手者"（通常是打牌成功最多的两人）中排名靠前的升一级。
- **双升**：该队两人都升级（同时超越当前等级） → 下局一人升 2 级
- **单升**：一人升级
- **落地升**：落后一级的队员输局后，如果本队总体赢了，该落后者升 1 级
**队伍失败**：失败队对应的先手者降 1 级。
例如：当前 5 号为主等级，甲队赢 → 5 号队的升级者晋到 6；乙队如有人被"甩"（手牌未出完游戏结束）则双重扣分。
### K 级与过 A 的两道关
掼蛋最独特的规则是 K 级的"双关"设定：
**K 级第一关**：K 级的队伍需要"打 A"——一局内该队的先手者必须打出 A（使用 A 赢得出牌权）。打出 A 才有资格升到第二关。
**K 级第二关**：打过 A 后，下一局需"过 A"——不仅打出 A，还要在最后一轮出牌中再次过掉对方的 A（即最终赢牌包含 A）。双关通过，升到 A 级。
这两道关卡是掼蛋最紧张刺激的时刻。对方往往会竭力阻止你打 A，气氛非常激烈。有些地区还有"争关"规则，A 级的队伍可以和 K 级争夺升级。
### 炸弹与倍数计算
掼蛋的倍数加成主要来自炸弹：
**四同炸弹**：四张同点数牌 → ×2 倍
- 例如 4 个 8 一起出，即使不是最大牌，也能炸掉对方任何牌型
**五同与花色炸**（地区变体）：
- 五同（如 5 个 5，需要王牌配合）→ ×4 倍或 ×8 倍
- 同花顺（如红桃 7-8-9-10-J）→ ×2 或 ×4 倍（视地区）
**火箭**：两张王（大王 + 小王）→ ×2 倍（有些地区 ×4）
一局多个炸弹时，倍数相乘。掼蛋的倍数计算比斗地主复杂，需要精确跟踪每局的所有炸弹。
### 地区版本与规则差异
掼蛋在江苏、安徽各地有显著差异：
**江苏标准版**：最严格的规则。禁止"硬炸"（同花顺无加成），只有四同 ×2；地主升级人数明确。
**安徽变体版**：允许同花顺 ×3 或 ×4；对于多队伍同等升级时有特殊处理（称"回顺"）。
**上海老年版本**：放宽升级条件，K 级时只需出现一个 A（无需再过 A），加速游戏进度；倍数上限更高。
**线上麻将房版**：简化规则以适应数字化，通常无"硬炸"，倍数固定或上限 256；自动追踪升级避免争议。
本工具内置这些版本的规则库，不同地区的玩家可一键切换。
### 本工具的掼蛋记分优势
传统笔记掼蛋的挑战：
- 等级多（13 级）、四人各自的等级互不相同，手动追踪易混淆
- 升级条件复杂（双升、单升、落地升），判断谁升谁降需反复确认
- K 级的"两关"规则需记住谁打过 A、谁还差一关
- 倍数叠加时容易遗漏某个炸弹
- 一个"轮"可能 10-20 局，累计计分手算容易出错
本工具解决这些问题：
- 自动追踪四人各自的等级进度，实时显示谁在 K 级的哪一关
- 输入当局胜者后，自动判断升级规则（双升 / 单升 / 落地升），同步更新所有人等级
- 记录每局是否出现炸弹及倍数，累计赛季总倍数
- 支持"撤销"上一局，避免重新计算全部
- 导出赛季报告，包括个人升级速度、胜率、掉分频率等分析
### 常见问题
**Q: 从 2 级升到 A 级需要多少局？**
理论最少 12 局（每局升 1 级）。但实际取决于胜负率和地区规则。若每局 50% 概率赢，平均 20-30 局才能升到 A。K 级因为有两道关，通常需要额外 3-5 局。
**Q: 双升是什么意思？**
一局内，胜队的两个成员都达到了升级条件（如都出了特定牌型）。下一局时，其中排名第一的升 2 级，排名第二的升 1 级。反过来说，败队双降。
**Q: 落地升规则怎么理解？**
一个队四人中总有等级差异。等级最低的人输了一局，但队伍总体赢了，那他可以升 1 级（叫"落地升"）——相当于给落后者翻身机会。
**Q: 过 A 的两道关能在同一局里完成吗？**
不能。K 级第一关（打 A）和第二关（过 A）必须分两局。即使一局里既打出又过了 A，也是两关分开计数。
**Q: 倍数会清零吗？**
取决于规则。有些地区每升级一次清零倍数重新计算；有些全赛季累计不清零。本工具支持两种模式自定义。
**Q: 工具能追踪单局掉分吗？**
可以。本工具记录每局的倍数和胜负者，导出时能看到单局掉分明细（如某人因被甩损失 -8 分等）。
---
## 麻将记分完全指南：自摸 / 点炮 / 流局 各算法
> 麻将四人玩法、东南西北方位、自摸与点炮的支付差异、底分与番数的乘法、流局规则、地区方言差异、本工具按"金额"通用记分的优势。
URL: https://xtechtools.com/guides/mahjong-score/
发布：2026-04-29 · 更新：2026-04-29
麻将是中国最古老的博弈游戏，已有百年以上历史。麻将计分规则出了名的复杂——同样"三番"胡牌，自摸和点炮的支付额完全不同；流局罚分有讲究；不同地区番数标准各异（广东推倒胡、北京麻将、四川血战到底等）。本指南详细解自摸 vs 点炮的支付差异、东家倍数机制、底分与番数的乘法关系、流局规则、地区方言差异（广东 / 北京 / 四川 / 浙江 / 上海），以及用本工具按"金额"进行通用化电子记分的便利与优势。
### 麻将的基本玩法与四个方位
麻将由四人参与，坐成一圈。
**方位与庄家**：
- 东 → 南 → 西 → 北 循环（共 16 局一圈，东/南/西/北各 4 局）
- 每圈的第一局由东家做庄
- 胡牌（赢）的玩家下局做庄；如果是平局（流局），庄家继续做庄
**胡牌条件**：手中 14 张牌（含摸进来的 1 张）形成特定牌型（如清一色、刻子、顺子等）。
**胡的两种方式**：
- **自摸**：自己摸牌时完成胡牌 → 三家都要付钱给你
- **点炮**：别人出牌时你胡了 → 只有那一家付钱给你，另两家不付（这是关键差异）
### 自摸 vs 点炮的支付差异
这是麻将计分最重要的一个差异：
**自摸**：你胡了，三家都要给你钱。假设底分 1 块、番数 2：
- 东家给：1 × 2 × 2 = 4 块（东家多付）
- 南家给：1 × 2 × 1 = 2 块
- 西家给：1 × 2 × 1 = 2 块
- 你共收：4 + 2 + 2 = 8 块
**点炮**：例如被南家点炮，只有南家付钱给你：
- 如果你是东家（点炮加倍）：南家付 1 × 2 × 2 = 4 块
- 如果你是非东家：南家付 1 × 2 × 1 = 2 块
- 另外两家（东家、西家）不付钱
**关键**：自摸是"多人平摊"，总收益较大；点炮是"单人承担"，收益较小但被点炮者亏得多。
### 底分、番数与倍数关系
麻将计分的数学模型：
**底分**：基础赌注，常见 0.5 块、1 块、2 块。
**番数**：根据胡牌的牌型复杂度评分，常见 1-6 番甚至更高。例如：
- 1 番：刻子、对对、清一色等基础牌型
- 2 番：加上特定条件（如自摸、碰碰胡）
- 3+ 番：混合高级牌型（七对、十三幺等）
**计分公式**：底分 × 番数 × 倍数（东家/非东家）
- 东家自摸 3 番：底分 × 3 × 2（三家各付，东家 ×2）
- 非东家自摸 3 番：底分 × 3 × 1（南西北各付，不分东西）
- 点炮给非东家：底分 × 番数 × 1
- 点炮给东家：底分 × 番数 × 2
**上限与封顶**：某些地区规定最高番数为"满贯"（如 8 番、10 番、13 番），超过封顶值一律按封顶值计算。
### 流局与罚分规则
四人都没胡牌而摸牌摸完，称为"流局"或"荒局"。流局时谁罚分取决于流局类型：
**摸牌无和**：正常流局，通常无罚分，下一局继续。
**流局满贯**（地区变体）：
- 某些地区规定，流局时摸清所有牌仍无和 → 庄家罚 2-4 块给其他三家
- 有些地区则为零罚
**罚分导致流局**：
- 出现"四风连打"（四个风出现四次）→ 庄家罚分
- 出现"四杠"（四个杠）→ 庄家罚分
- 黄牌（违规出牌被发现）→ 该家罚分
**不同地区差异很大**。广东推倒胡通常无流局罚分；北京麻将则有明确罚分标准。本工具支持多种流局模式选择。
### 地区方言与规则差异
中国各地的麻将规则差异巨大：
**广东推倒胡**：无东西南北风牌，只有万索筒，胡牌条件最灵活。号称"南派"最自由的方言。
**北京麻将**：严格的番数标准（1-6 番），有"七对""清一色"等限定，计分规则详细且不容商量。常见 8 番、10 番封顶。
**四川血战到底**：三人不退出，四人独立战斗，胡牌不影响他人（不放炮）。番数简化，但因为三人继续，游戏可能无限延长。
**浙江嘉兴麻将**：花牌（春夏秋冬梅兰竹菊）加入，8 张花牌增加了运气和变数。
**上海麻将**：二番起胡，一番不算；有"清、混、荤"三种牌型等级划分。
本工具内置这些流行地区的规则库，可一键切换，无需每局重新设置。
### 本工具的麻将记分优势
传统笔记麻将计分的难点：
- 自摸和点炮的支付链路不同，多人时容易算错
- 东家身份会动态变化，需反复确认倍数
- 流局罚分规则地区差异大，容易遗漏或用错
- 番数多且复杂，累计计分时一次一次乘算容易出错
- 一天可能 10+ 局，总结时需要全部加总
本工具通过"金额输入"解决这些问题：
- 无需记忆番数表。只需输入本局某个玩家赢的"金额"（例如"张三自摸 12 块"），工具会根据当前的庄家身份、胡的方式自动计算每个玩家应付多少
- 支持一键设置麻将地区规则（广东 / 北京 / 四川 / 浙江 / 上海 / 自定义），自动应用对应的番数上限和流局规则
- 实时显示四人的"输赢累计"，支持多天汇总（例如本周来家里打麻的总进度）
- 导出每日账单、人均赢分率、最多赢的一局等分析
### 常见问题
**Q: 自摸和点炮哪个更赚钱？**
自摸赚钱。例如底分 1 块、3 番，自摸能收 8 块（三人各 2-4 块），但点炮只能从一人手中收 2-4 块。这也是为什么有成语"自摸加倍"。
**Q: 被东家点炮和被非东家点炮，付的钱不一样吗？**
是的。同样底分和番数，点炮给东家的倍数是 ×2，点炮给非东家的倍数是 ×1。所以被东家点炮亏得更多。
**Q: 流局时庄家要罚多少？**
取决于地区规则。有些地区无罚分；有的地区庄家罚 2-4 块给其他三家；有的情况下（如四风连打）另有规定。本工具支持自定义流局罚分规则。
**Q: 麻将最高番数是多少？**
没有绝对答案。有些地区无限制；有些规定 8 番、10 番、13 番为"满贯"（封顶）。本工具可配置封顶值。
**Q: 一个人连续做庄多局，要给分吗？**
不用。庄家身份只影响自摸 / 点炮时的倍数。赢牌才需要付钱；没人胡牌的流局通常无需庄家额外付分。
**Q: 工具能区分不同地区的麻将规则吗？**
可以。本工具内置广东、北京、四川等流行地区的番数表和流局规则，创建牌局时可选择。也支持"自定义"方案以适应本地特殊规则。
---
## JWT 签发完整指南：HS256 / RS256 / ES256 选哪个
> JWT 是互联网最常用的无状态身份验证标准。本文讲清楚三种签名算法的原理、适用场景、payload 设计与撤销难题，以及何时选哪个。
URL: https://xtechtools.com/guides/jwt-sign/
发布：2026-04-29 · 更新：2026-04-29
JWT（JSON Web Token）是无状态身份认证的业界标准，从微信小程序到企业级 OAuth2，处处可见。但很多开发者拿着三种签名算法（HS256 / RS256 / ES256）却搞不清什么时候该用哪个——HS256 用错了容易被冒签，RS256 用对了能支撑多方验证。本指南从三段结构讲起，逐一分析算法权衡与安全性，再到 payload 设计、过期策略、撤销方案，让你能自信地选出适合项目的方案。
### JWT 的三段结构
JWT 由三段 Base64URL 编码的部分用 `.` 连接：
```
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c
```
**Header**（首段）：`{"alg":"HS256","typ":"JWT"}` 指定签名算法和文档类型。解码后就是这个 JSON。
**Payload**（中段）：`{"sub":"1234567890","name":"John Doe","iat":1516239022}` 是实际数据（claims）。注意：Base64 只是编码不是加密，任何人都能解码看到内容，所以不要放密码或敏感信息。
**Signature**（末段）：用私钥或对称密钥对「header.payload」字符串签名，防止数据被篡改。只要内容变一个字符，签名就失效。
### HS256：对称加密，单方控制
**HS256 = HMAC with SHA-256**，用同一个密钥（secret）既签名又验证。
签发流程：
```
token = base64(header) + '.'+ base64(payload) + '.' + hmac_sha256(base64(header) + '.' + base64(payload), secret)
```
验证流程：重新计算签名，比对是否相同。
**优点**：
- 实现最简单，一行代码搞定
- 性能最快（HMAC 比 RSA 快 10 倍）
- 密钥小，token 体积小
**缺点**：
- 对称密钥，签发和验证端都要拥有同一个 secret
- 适合单体架构或内部系统，不适合多方验证（如开放平台）
- secret 泄露后，攻击者可伪造任何 token
**典型场景**：单体 Node.js 服务自己签发自己验证的 token，或内部微服务间通信。
### RS256：非对称加密，多方验证
**RS256 = RSA Signature with SHA-256**，用私钥（private key）签名，用公钥（public key）验证。
签发流程：使用私钥签名，发放 token 和公钥。
验证流程：用公钥验证，无需私钥。
**优点**：
- 公钥可安全公开（GitHub、谷歌等大厂都这样做）
- 支持多方验证：中心签发 token，分布式服务都能用公钥验证
- 私钥泄露风险更低（通常存在专门的密钥服务器）
- OAuth2 标准推荐
**缺点**：
- 密钥更复杂（2048 位 RSA 至少 1700 字节）
- 签名与验证性能比 HS256 慢
- 初期配置复杂
**典型场景**：OAuth2 授权服务器签发 token，各个资源服务器都能验证。或公有云 API（AWS、Azure）。
### ES256 与其他算法
**ES256 = ECDSA with SHA-256**（椭圆曲线），介于 HS256 和 RS256 之间。
- 性能接近 HS256（快）
- 密钥比 RSA 小（256 位 ECDSA = 2048 位 RSA 的安全强度）
- 非对称，支持多方验证
**实际应用**：Apple、Google、微信等新一代服务用 ES256 代替 RS256。初创项目倾向 ES256，老项目沿用 RS256。
**选择指南**：
- 单体服务或内网 → HS256（快、简单）
- 分布式/开放平台 → RS256 或 ES256（多方验证）
- 新项目优先 → ES256（性能与安全的最佳平衡）
### 常见 Claims 与设计原则
JWT payload 建议包含这些 standard claims（rfc7519）：
- `iss`（issuer）：签发者，如 `https://auth.myapp.com`
- `sub`（subject）：主体，通常是用户 ID
- `aud`（audience）：受众，指定哪个服务能用这个 token，如 `api.myapp.com`
- `exp`（expiration time）：过期时间，Unix 时间戳（秒）
- `iat`（issued at）：签发时间
- `nbf`（not before）：生效时间，通常 = iat（可用来延迟生效）
- `jti`（JWT ID）：唯一 ID，用于追踪和撤销
**设计原则**：
- **不放敏感数据**：Base64 随意解码，token 里别放密码、身份证、银行卡
- **保持精简**：每个 claim 增加 token 体积，HTTP header 大小有限制
- **用 aud 做访问控制**：不同服务验证时检查 aud 是否匹配，防止 token 串用
- **用 jti 追踪**：调试和安全审计时需要唯一身份
### 过期策略：access token + refresh token
单用一个长期 token 不安全（泄露影响大）。业界标准做法是双 token 体系：
**Access Token**：
- 短期（15 分钟 ~ 1 小时）
- 用于访问 API
- 泄露损失相对小
- 过期后服务器直接拒绝，无需查库
**Refresh Token**：
- 长期（7 天 ~ 30 天）
- 仅用于刷新获取新 access token
- 存在数据库，可追踪和撤销
- 泄露后在数据库删除即可阻止进一步续期
**典型流程**：
1. 登录成功，返回 access token + refresh token
2. 用 access token 调 API
3. Access token 过期，用 refresh token 申请新 access token
4. Refresh token 过期或被撤销，需重新登录
这样既享受无状态的便利，又能在需要时快速撤销（delete from db）。
### JWT 撤销难题的三个方案
JWT 最大问题：签发后无法立即作废（无状态 = 无法查库）。三种常用方案：
**方案 1：短期 token**（推荐）
设 access token 15 分钟过期，攻击者获得 token 也只能用 15 分钟。用户登出时撤销 refresh token。
**方案 2：黑名单数据库**
用户登出或修改密码时，把 token 的 jti 存进黑名单表。验证时先查黑名单，这样破坏了"无状态"但仍比 session 更轻。
**方案 3：改用 Session**
如果撤销需求极高（如金融），就别用 JWT，用 session 结合 Redis，每次都查库验证。损失无状态的便利，但获得完全控制。
**实战建议**：互联网产品选方案 1（短期 access token），政府/金融/医疗选方案 2 或 3。
### 常见问题
**Q: HS256 的 secret 应该多长？**
至少 32 字符（256 bits）。用加密随机生成，不要是弱密码或日期。Node.js：crypto.randomBytes(32).toString('hex')。
**Q: 如何防止 token 被 XSS 偷走？**
Access token 存 httpOnly cookie（脚本无法访问），refresh token 存 secure cookie。这样 XSS 攻击也伤害有限。
**Q: Token 在哪里放传输？**
通常放 Authorization header：`Authorization: Bearer `。不要放 URL 参数（日志和浏览器历史会记录，比 header 不安全）。
**Q: 验证 JWT 时还需要检查什么？**
除了签名有效，还要验证：(1) exp 是否过期，(2) aud 是否匹配当前服务，(3) iss 是否来自可信来源，(4) jti 是否在黑名单（如用了方案 2）。
---
## HTTP 请求代码生成完全指南：fetch / axios / curl 最佳实践
> 从 GET 取数到 POST 创建再到 PUT/PATCH 更新，掌握 HTTP 方法语义、Content-Type 选择、Authorization 方案，写出安全高效的请求代码。
URL: https://xtechtools.com/guides/http-request-gen/
发布：2026-04-29 · 更新：2026-04-29
HTTP 请求看似简单，但选错方法或 header 会导致隐蔽的 bug。GET 用来取数，POST 创建，PUT 整体替换，PATCH 部分更新，DELETE 删除——每个都有特定含义，用错了服务器也许能工作但违反了 REST 约定。本指南从方法语义讲起，逐一覆盖 Content-Type、Authorization、错误处理、超时与重试，并用本站工具生成可用的 fetch / axios / curl 代码。
### HTTP 方法的正确语义
| 方法 | 幂等 | 有 body | 用途 |
| --- | --- | --- | --- |
| GET | ✓ | ✗ | 读取资源，不修改服务器 |
| POST | ✗ | ✓ | 创建新资源，或触发服务端动作 |
| PUT | ✓ | ✓ | 整体替换资源（全量更新） |
| PATCH | ✗ | ✓ | 部分修改资源 |
| DELETE | ✓ | ✗ | 删除资源 |
| HEAD | ✓ | ✗ | 同 GET 但不返回 body，常用于检查资源是否存在 |
**幂等**：重复执行多次与执行一次结果相同。GET/PUT/DELETE 幂等，POST/PATCH 不幂等。
**常见错误**：
- 用 GET 修改数据（导致被浏览器缓存，修改失效）
- 用 POST 代替 PUT（语义不清，难以预测行为）
- 用 DELETE 而不返回成功状态（删除的资源去哪了？）
### Content-Type 与请求体格式
最常见的三种：
**application/json**（推荐）：
```
Content-Type: application/json
{"name":"Alice","age":30}
```
现代 API 的标准。跨语言通用，嵌套灵活。缺点：不支持文件上传。
**application/x-www-form-urlencoded**：
```
Content-Type: application/x-www-form-urlencoded
name=Alice&age=30
```
老式 HTML 表单使用。URL 中含 `&` 会变 `%26`，不适合复杂数据。但很多老网站仍用。
**multipart/form-data**：
```
Content-Type: multipart/form-data; boundary=----Boundary123
------Boundary123
Content-Disposition: form-data; name="name"
Alice
------Boundary123
Content-Disposition: form-data; name="file"; filename="photo.jpg"
Content-Type: image/jpeg
[二进制内容]
```
唯一支持文件上传的格式。浏览器上传表单自动用这个。
**选择规则**：
- REST API（推荐） → JSON
- HTML 表单 → form-urlencoded 或 multipart
- 文件上传 → 必须 multipart
### Authorization 认证方案
服务器如何确认你是谁？四种常见方案：
**1. Bearer Token（最常用）**：
```
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...
```
通常是 JWT。适合 API 认证和移动 app。
**2. Basic Auth**：
```
Authorization: Basic dXNlcm5hbWU6cGFzc3dvcmQ=
```
Base64 编码的 `username:password`。简单但不安全，必须用 HTTPS，很多接口仍用（如 npm registry、GitHub personal access token）。
**3. API Key**：
```
X-API-Key: sk-1234567890abcdef
```
或放 query 参数 `?api_key=...`。不安全，但简单。常见于公开 API（天气、地图、翻译）。
**4. OAuth2**：
```
Authorization: Bearer access_token_here
```
结合 refresh token 的完整授权框架。微信、QQ、Google 登录都用 OAuth2。
**选择规则**：
- 内部 API → Bearer Token（JWT）
- 第三方服务接入 → OAuth2
- 小型公开 API → API Key
- 遗留系统 → Basic Auth（但要用 HTTPS）
### Fetch vs Axios vs curl 对比
**Fetch API**（原生，无依赖）：
```
const res = await fetch('/api/users', {
method: 'POST',
headers: { 'Content-Type': 'application/json' },
body: JSON.stringify({ name: 'Alice' })
});
const data = await res.json();
```
优点：原生 API，无需引入库，Promise 原生支持。缺点：没有内置超时、重试、请求拦截器，手工处理比较繁。
**Axios**（最流行的 HTTP 库）：
```
const res = await axios.post('/api/users', { name: 'Alice' }, {
timeout: 5000,
headers: { 'Content-Type': 'application/json' }
});
const data = res.data;
```
优点：超时、重试、拦截器都有，API 简洁。缺点：需要依赖。
**curl**（命令行）：
```
curl -X POST https://api.example.com/api/users \\
-H "Content-Type: application/json" \\
-d '{"name":"Alice"}'
```
优点：快速测试，无环境要求。缺点：不适合复杂逻辑。
**本站工具**自动生成这三种代码，选择对应场景即可。
### 错误处理与状态码检查
**Fetch 的坑**：fetch 只在网络错误时 reject，4xx/5xx 不会。
```
try {
const res = await fetch('/api/users');
if (!res.ok) throw new Error(`HTTP ${res.status}`);
return await res.json();
} catch (err) {
console.error('Request failed:', err);
}
```
**必须手工检查 res.ok 或 res.status**。
**Axios 的便利**：状态码 4xx/5xx 自动 reject。
```
try {
const res = await axios.get('/api/users');
return res.data;
} catch (err) {
if (err.response) {
console.error(`Server error ${err.response.status}`);
} else if (err.request) {
console.error('No response');
}
}
```
**常见状态码**：
- 200 OK / 201 Created / 204 No Content
- 400 Bad Request / 401 Unauthorized / 403 Forbidden / 404 Not Found
- 500 Internal Server Error / 503 Service Unavailable
不同的错误需要不同处理（401 要重新登录，503 可重试）。
### 超时与重试策略
**设置超时**（防止无限等待）：
Fetch（无内置）：
```
const controller = new AbortController();
const id = setTimeout(() => controller.abort(), 5000);
try {
return await fetch(url, { signal: controller.signal });
} finally {
clearTimeout(id);
}
```
Axios（简单）：
```
await axios.get(url, { timeout: 5000 });
```
**重试策略**：
```
async function retryFetch(url, maxRetries = 3, delay = 1000) {
for (let i = 0; i < maxRetries; i++) {
try {
return await fetch(url);
} catch (err) {
if (i === maxRetries - 1) throw err;
await new Promise(r => setTimeout(r, delay * Math.pow(2, i)));
}
}
}
```
**重试原则**：
- GET / HEAD / DELETE / PUT：幂等，可安全重试
- POST / PATCH：非幂等，重试需谨慎（可能重复创建）
- 只重试 5xx / 408 / 429，不重试 4xx（客户端错误重试无效）
- 指数退避延迟（1s → 2s → 4s），避免击垮服务器
### CORS 跨域与浏览器限制
浏览器同源策略：JavaScript 只能请求同域名/同端口的资源。跨域请求会被浏览器拦截。
**CORS 预检请求**（OPTIONS）：浏览器自动发送，服务器响应允许的方法和 header。
```
Fetch 时浏览器自动发 OPTIONS，如果服务器没有 CORS header，请求被拦截。
```
**解决方案**：
1. 服务器加 CORS header：
```
Access-Control-Allow-Origin: *
Access-Control-Allow-Methods: GET, POST, PUT, DELETE
Access-Control-Allow-Headers: Content-Type, Authorization
```
2. 用 Proxy（开发时）：Next.js / Create React App 的 setupProxy
3. 用 JSONP 或 iframe（已过时）
**注意**：curl 和 Node.js 后端无 CORS 限制，只有浏览器中的 JavaScript 受限。本站工具生成的前端代码，如果跨域需确保目标 API 开启 CORS。
### 常见问题
**Q: 什么时候用 PUT，什么时候用 PATCH？**
PUT 替换整个资源（全量），PATCH 修改部分字段。例：更新用户，PUT 时必须发全部字段，PATCH 只发改变的字段。但多数小型 API 都用 PATCH。
**Q: Fetch 默认是 GET 吗？**
是。不指定 method 时默认 GET；如果提供 body，默认变 POST（但需明确指定 method）。
**Q: 如何在浏览器中传文件？**
用 FormData + multipart/form-data。Axios 自动识别 FormData 并设置正确的 Content-Type。
**Q: 能在 Authorization 里放 API Key 吗？**
可以，但规范做法是用自定义 header（如 X-API-Key）或放 query 参数。Bearer token 严格指 OAuth2 / JWT。
**Q: 302 重定向我的代码需要处理吗？**
Fetch / Axios 默认自动跟随重定向（最多 5 次）。通常不需要手动处理，除非特别不想跟随。
---
## 词云生成完整指南：分词算法 / 美学设计 / 应用场景
> 词云用字号和颜色可视化高频词汇，常见于年度盘点、舆情分析、用户画像。本文讲清楚分词、停用词过滤、词频映射、配色与应用。
URL: https://xtechtools.com/guides/word-cloud/
发布：2026-04-29 · 更新：2026-04-29
词云（Word Cloud）是一种数据可视化方式，用字号大小和颜色深浅表示词汇频率和重要性。从微信公众号年度运营盘点、电商用户评价分析，到舆情监测、学术论文关键词提取，再到社交媒体话题热度，词云快速浮现数据的核心价值。但生成高质量词云并不简单——中英文分词完全不同，停用词必须过滤，字号映射可用线性或对数，配色更是心理学运用。本指南从算法原理讲到美学设计。
### 分词：英文 vs 中文的巨大差异
**英文分词**（简单）：按空格和标点切割。
`"Hello world from Python"` → `["Hello", "world", "from", "Python"]`
浏览器原生 JavaScript 直接 `.split(/\s+/)` 即可。
**中文分词**（复杂）：汉字间没有空格，无法用分隔符切割。必须用算法理解词义。
`"我喜欢学习自然语言处理技术"` → `["我", "喜欢", "学习", "自然", "语言", "处理", "技术"]` 或 `["我", "喜欢", "学习", "自然语言处理", "技术"]`
都有可能，取决于分词库和算法。
**常见中文分词库**：
- **jieba**（Python）：前向最大匹配 + 隐马尔可夫模型，准确率 85-90%
- **Python-Chinese-Segmentation**：分词准确但速度较慢
- **nodejieba**（Node.js）：jieba 的 JS 版本
- **大模型（ChatGPT）**：准确率最高但成本高
本站工具内置中文分词库，用户无需关心实现细节。
### 停用词过滤的重要性
分词后会出现大量"无意义的词"，必须过滤掉：
**中文停用词**（常见 100+ 个）：
的、是、了、和、在、有、人、这、中、大、来、以、对、生、要、我、他、不、为、起、到、一、被、...
**英文停用词**：
the、a、an、and、or、but、in、on、at、to、be、is、are、...
**例子**：
```
原始文本："中国是一个伟大的国家，我们的人民热爱和平。"
分词后：["中国", "是", "一个", "伟大", "的", "国家", "我们", "的", "人民", "热爱", "和平"]
过滤停用词：["中国", "伟大", "国家", "人民", "热爱", "和平"]
```
去掉 "是" "的" "我们" 这类虚词后，词云显示的信息密度立刻提高。
**自定义停用词**：本工具允许在生成前补充或删除停用词，比如项目特定的常见词（公司名、产品名）。
### 词频计算与字号映射
**词频统计**（计数）：
```
单词词频 = 该单词在全文出现的次数
```
假设分词后得到：
```
"AI" 出现 150 次
"机器学习" 出现 80 次
"深度学习" 出现 45 次
"算法" 出现 20 次
```
**字号映射**（关键一步）：频率最高的词显示最大，最低的词显示最小。但用哪个函数映射？
**线性映射**：
```
font_size = min_size + (frequency - min_freq) / (max_freq - min_freq) * (max_size - min_size)
```
字号与词频成正比。缺点：高频词太大，低频词太小，对比过于极端。
**对数映射**（推荐）：
```
font_size = min_size + log(frequency + 1) / log(max_freq + 1) * (max_size - min_size)
```
高频词增长放缓，低频词相对显眼，视觉分布更均衡。
**平方根映射**：
```
font_size = min_size + sqrt(frequency) / sqrt(max_freq) * (max_size - min_size)
```
折中方案，常见。
**经验参数**：min_size = 12px，max_size = 80px（根据词云大小调整）。
### 形状与布局设计
词云形状影响视觉感受：
**矩形（默认）**：
- 最高效利用空间
- 阅读顺序清晰（从左到右、从上到下）
- 适合信息密集场景
**圆形**：
- 和谐、整体感强
- 常见于品牌/企业应用
- 空间利用率 70%
**心形**：
- 情感化、温暖
- 常见于情人节、公益活动
- 难排版，空间利用率 60%
**自定义形状**：上传 SVG 或 PNG 轮廓，词云填充形状内部（高级功能）。
**布局算法**：
- **螺旋**（高效）：从中心向外螺旋排列，快速、紧凑
- **随机**（散乱）：无序排放，有机、不规则
- **竖排**（中文友好）：竖排中文看起来更自然
本工具默认螺旋布局，水平排列，适合快速生成。
### 配色与心理学
颜色不仅是装饰，还传达信息：
**暖色调**（红、橙、黄、粉）：
- 传达：热情、积极、活力
- 适合：品牌推广、营销文案、互动分析
- 例：电商平台的用户评价词云
**冷色调**（蓝、青、紫、绿）：
- 传达：理性、专业、深度
- 适合：学术论文、技术分析、舆情监测
- 例：AI 论文关键词、代码库分析
**单色渐变**（同一色系深浅）：
- 传达：专业、统一
- 适合：企业正式报告
**彩虹**（多彩）：
- 传达：创意、多样
- 适合：儿童内容、创意产业
- 风险：容易显得混乱
**设计建议**：
1. 与品牌色一致（企业应用）
2. 用 3-5 个主色 + 渐变变体，避免超过 7 色（色数过多显脏）
3. 高频词用高对比色，低频词用背景色接近的浅色
4. 测试色盲友好度（5% 男性有色盲）
### 典型应用场景与案例
**1. 微信公众号年度数据分析**：
统计全年文章标题和正文中的高频词。暖色调词云，突出品牌传播的核心概念。
**2. 电商评价分析**：
用户评论分词后生成词云。"快递" "质量" "推荐" 大，"垃圾" "破损" 也大 → 表示有问题值得关注。
**3. 舆情监测**：
爬取新闻、微博、论坛评论，分词后监测高频词变化趋势。蓝色冷调显得专业。
**4. 简历/论文关键词提取**：
PDF 转文本 → 分词 → 词频统计 → 生成词云。一眼看出求职者的核心技能或论文的主题。
**5. 用户画像画像**：
分析 500 条用户问卷回答，生成描述词云。"80 后" "北京" "白领" "爱好旅游" 高频 → 核心用户画像浮现。
**6. 品牌认知调研**：
问用户 "你对 iPhone 的第一印象？" 收集 1000+ 回答，词云显示 "创新" "简洁" "昂贵" 频率。
### 词云 vs 标签云的区别
两者容易混淆但完全不同：
**词云（Word Cloud）**：
- 根据词频改变字号
- 适合展示大量数据中的热点
- 需要数据计算、算法支撑
- 适合分析型应用
**标签云（Tag Cloud）**：
- 等大的标签，按名称字母排序
- 只有分类、导航功能
- 无需计算词频
- 适合网站导航（如博客标签页）
这里讲的是词云。本站工具不支持标签云。
### 常见问题
**Q: 中文词云会包含繁体字吗？**
取决于分词库。jieba 默认简体，但支持加载繁体词库。本工具默认简体中文。
**Q: 能去掉某个我不想看的词吗？**
可以。在生成前的「自定义停用词」输入框里加上这个词，或修改预设停用词表。
**Q: 词云可以导出吗？**
可以。本工具支持导出 PNG（光栅图）和 SVG（矢量），SVG 可在 Figma/Illustrator 继续编辑。
**Q: 为什么同一份数据生成的词云每次不一样？**
布局算法（特别是螺旋）加入了随机成分，多次生成的词位置会不同。词频和字号不变。如需完全复现，固定随机种子。
**Q: 能生成 3D 词云吗？**
本工具不支持 3D。3D 词云需要 Three.js 等 3D 引擎，交互体验未必更好，反而加载慢。
---
## Markdown 转 HTML 完全指南：公众号 / 邮件 / 网站三种用法
> 从 Markdown 到最终渲染，三大场景（微信公众号、HTML 邮件、网站 CMS）的转换技巧与坑位。包含 GFM 扩展、样式嵌入、兼容性处理与安全防护的完整解决方案。
URL: https://xtechtools.com/guides/md-to-html/
发布：2026-04-29 · 更新：2026-04-29
Markdown 因其简洁的语法深受开发者和内容创作者喜爱，但当你需要把 Markdown 发送到公众号、邮件或网站时，单纯的 HTML 转换远远不够。公众号要求内联样式、邮件需要 90 年代级表格兼容、网站则要求 SEO 友好。本指南详解三大场景下的 Markdown→HTML 最佳实践，涵盖 GFM 扩展、样式嵌入、安全防护与工具选型。无论你是内容创作者、开发者还是技术博主，本指南都能帮你解决跨平台排版的所有难题。
### Markdown 转 HTML 的三大场景与各自挑战
**场景 1：微信公众号**。公众号编辑器阉割了大量 CSS，只接受部分标签和 style 属性，无外部样式表、无 @font-face、无 JavaScript。要让排版在公众号里不崩坏，必须把所有样式以 inline style 的方式嵌入到 HTML 标签内。
**场景 2：HTML 邮件**。邮件客户端（Outlook、Gmail、Apple Mail）对 CSS 的支持参差不齐，很多样式属性在某些客户端被无视或破坏。安全的做法是用 table 布局（如 1990 年代的网站），避免 float、flex、grid，所有样式都 inline。
**场景 3：网站 CMS**。网站通常有统一的 CSS 框架（Tailwind、Bootstrap），Markdown 生成的 HTML 需要兼容这些框架的 class，还要考虑 SEO（heading 层级、alt 文本、结构化数据）。
三个场景，三套规则。同一个 Markdown 源文件，直接转换无法同时满足全部需求。
### GFM 扩展与跨平台兼容
标准 Markdown 只支持基础的标题、列表、代码块。GitHub Flavored Markdown（GFM）在此基础上添加了表格、删除线、任务列表、代码行高亮。但问题是：公众号、邮件、甚至一些旧网站的 Markdown 转换器不支持 GFM。选择转换工具时务必检查是否启用了 GFM 模式。常见转换库如 marked.js、markdown-it 都默认支持 GFM，但部分 WordPress 插件可能需要手动启用。
### 公众号场景：inline style 嵌入与样式保留
微信公众号编辑器会自动过滤掉你写的 
`
- JWT Token：三段（header.payload.signature）都是 URL Safe Base64，浏览器 URL 安全
- Email 附件：MIME 协议强制二进制附件用 Base64 编码传输
- API 传二进制：在 JSON 里传图片、证书、签名
- 短小文件进 JSON：Base64 能在 JSON 里安全表达任意二进制
**不该用**：
- 大文件传输：Base64 膨胀 33%，带宽浪费。直接用二进制或分块上传
- 需要隐私：Base64 是编码不是加密，安全信息必须先加密再 Base64
- 高频计算：编解码有 CPU 开销，每秒数百万次编码时可能成瓶颈
- 密码存储：密码必须用 bcrypt/Argon2 哈希，不能用 Base64
### URL Safe Base64 与标准 Base64 的区别
标准 Base64 用 `+` 和 `/` 这两个字符，但在 URL 中它们是保留字符：
- `+` 在 URL 查询参数里被解释为空格
- `/` 是路径分隔符
所以需要转义：`+` → `%2B`、`/` → `%2F`，不友好。
**URL Safe Base64** 的解决方案：
- `+` → `-`（减号）
- `/` → `_`（下划线）
- 末尾 `=` 通常省略（接收方能推断出来）
**JWT 用的就是 URL Safe Base64**。本工具勾选「URL Safe」选项即可输出。同样，如果你是解码 JWT，工具也会自动识别并正确处理。
转换公式：`b64url = b64.replace(/\+/g, '-').replace(/\//g, '_').replace(/=/g, '')`
### 文件与 Data URL：实战场景
**文件转 Base64**：
1. 选择本地文件 → 工具读为字节数组 → Base64 编码 → 得到长字符串
2. 应用场景：数据库存图片、API 传文件、备份到 JSON 中
**Data URL 格式**：
`data:[
```
通常见于动态生成的验证码、图表、二维码。
**邮件签名中的内联图片**：
```html