NanoID

重复概率取决于长度和字符表大小。默认 21 位、64 字符表时，碰撞概率约 2^-126，远低于 UUID v4 的 2^-122。本工具支持自定义长度和字符表：长度越短、字符表越小，碰撞概率越高。如果用于生产环境，建议保留默认 21 位或更长；测试或非关键场景可缩短到 8-12 位。工具页面输出区会显示当前配置下的理论碰撞概率估算值，方便评估风险。

可以，但有限制。字符表支持任意 Unicode 字符，包括中文、表情符号、特殊符号。注意：字符表里的重复字符会被自动去重，且长度不要超过 256 个字符（浏览器限制）。如果字符表包含 URL 不安全字符（如空格、#、?），生成的 ID 在 URL 中使用前需编码。建议生产环境只用字母数字和连字符、下划线。

能用，但碰撞风险很高。5 位长度、64 字符表时，总组合约 10^9 种，生成几千个 ID 后碰撞概率就显著上升。工具输入框下方会实时显示当前长度+字符表下的总组合数，帮助判断是否够用。如果只是临时打标签（比如一天几十个），5 位可以；如果是长期存储或高并发场景，建议至少 12 位以上。

完全在浏览器本地运行。本工具实现方式为纯前端（FE），所有随机数生成、字符表处理、ID 拼接都在用户设备内存中完成，不会向任何服务器发送数据。生成结果不会离开当前页面，刷新后即消失。适合对数据隐私敏感的场景（如生成 API Key、内部标识符）。

可以，但注意性能差异。NanoID 是随机字符串，相比自增整数主键，在 MySQL/PostgreSQL 的 B-Tree 索引中插入时会产生随机页分裂，写入性能比自增 ID 低 10-20%。如果表写入量大（每秒几百行），建议用 UUID v7 或雪花算法。如果表写入量小（每天几千行），NanoID 完全可用，还能避免自增 ID 暴露数据量。工具生成的 ID 默认大小写敏感，数据库字段需设置 utf8_bin 或类似排序规则。

这是正常行为。NanoID 基于 cryptographically strong 随机数生成，每次调用都从字符表中独立随机选取字符。同一个配置重复生成，结果必然不同。如果需要可复现的 ID（比如从同一个种子生成相同序列），本工具不支持，请改用 hash 类方法（如 MD5/时间戳+序号）。工具页面上的「生成」按钮每次点击都会产生新结果，不会缓存。

理论上最长 256 位（浏览器输入框限制），实际不建议超过 100 位。超过 50 位后，ID 长度对碰撞概率的降低已微乎其微（21 位已足够），反而增加存储和传输开销。工具输入框会限制数字输入范围 1-256，但生成按钮会检查：如果长度超过 100，会弹出提示确认。建议生产环境 21 位，极端安全需求 32 位封顶。

核心区别有三点：① 字符表可自定义（UUID 固定 16 进制），NanoID 能用 64 字符表（A-Za-z0-9_-）使同样长度下组合数更多；② ID 长度可调（UUID 固定 36 字符含连字符），NanoID 最短可到 1 位；③ 排序性不同，UUID v1/v7 带时间戳可排序，NanoID 完全随机不可排序。本工具额外支持去重字符表、排除易混淆字符（如 0O1l）等选项，适合对 ID 可读性有要求的场景。