随机字符串，先明确生成规则

随机字符串首先是一组约束

展示用的随机文本、便于人工录入的短码和安全凭据，关注的性质不同。有的希望字符不重复，有的需要排除易混淆字符，还有的要求不可预测，不能仅凭长度统一处理。

在实现之前，先确定允许字符集合、是否允许重复，以及首位是否存在特殊要求。把这些约束整理出来，才能判断生成结果是否满足业务，而不是只检查字符串已经生成。

验证码、临时标识和展示用随机名称，看起来都由字符拼成，但对可预测性、可读性和碰撞的要求不同。选择算法之前先说明用途，才能判断普通随机数是否足够，还是必须使用适合安全场景的随机来源。

字符集合也需要明确。去掉容易混淆的字符能减少人工输入错误，却同时缩小可用空间。若还要求字符不重复，最大长度就受到字符集大小的硬限制，不能靠不断重试来突破。

允许重复与不允许重复，是两种抽样方式

import secrets
alphabet = "ABCDEFGHJKLMNPQRSTUVWXYZ23456789"
length = 12
value = "".join(secrets.choice(alphabet) for _ in range(length))
assert len(value) == length
assert set(value) <= set(alphabet)

这种方式允许同一个字符在结果中出现多次，并且每一位置使用相同字符集。长度为 n、集合大小为 m 时，理论组合数为 m 的 n 次方；实际安全性还取决于随机来源、生成规则和使用方式。

import secrets
alphabet = "ABCDEFGHJKLMNPQRSTUVWXYZ23456789"
length = 12
if length > len(alphabet):
    raise ValueError("无重复字符的长度超过集合大小")
value = "".join(secrets.SystemRandom().sample(alphabet, length))
assert len(set(value)) == length

这些是独立的 Python 示例，展示抽样策略而非项目内部实现。禁止重复会改变分布与组合数，并不自动比允许重复更安全。应当依据使用需求选择，而不是把“看起来更随机”当作可靠指标。

随机字节映射到字符时，要注意取模偏差

允许重复时，可以逐次选择字符；不允许重复时，可以打乱候选集合后选取需要的部分。两种路线对应不同的容量边界，后者不可能无限增加长度。

随机来源失败时，应让整个生成过程明确失败，不能悄悄用时间或固定值补齐。对于含有时间结构的业务编码，也应明确其用途，避免被误用为保密凭据。

如果随机字节均匀分布在 0 到 255，直接对一个不能整除 256 的字符集大小取模，会让前面部分字符得到更多映射机会。短期肉眼几乎看不出来，但它并不是均匀抽样。

一种通用方法是拒绝超过最大整倍数范围的值，再对剩余部分取模。例如字符集大小为 10，只接受 0 到 249，拒绝 250 到 255。实际开发优先使用已经提供均匀选择的标准接口，减少自己维护随机边界的成本。

格式规则不应偷偷降低可预测性要求

要求首位为字母或同时包含几类字符时，可以分别生成满足约束的部分，再使用合适的随机方式打乱顺序。若不打乱，固定位置会泄露结构；若采用拒绝重试，也要确认合法集合不会小到导致大量循环。

时间戳或递增序号可以改善排序或识别，但不能替代随机性。把当前时间拼进字符串，通常只是让一部分内容更加容易预测。不要把结果长度等同于随机熵。

唯一性需要在使用边界确认

一串文本看起来复杂，不代表它具备指定的随机性质。测试可以检查字符是否落在允许范围、长度是否符合约定、禁止重复时是否真的没有重复。

如果生成结果用于对外认证，应另行采用针对该场景审核过的方案。通用文本生成的价值是稳定地执行输入规则，而不是让所有随机需求都共享一个含义模糊的入口。

即使生成空间很大，数据库仍应对必须唯一的字段设置唯一约束。出现冲突时重新生成并重试，通常比提前查一次“是否存在”更可靠，因为查与写之间仍可能有其他请求插入相同值。

测试应验证长度、字符范围、不重复约束和不可能配置的拒绝行为。抽样分布可以用较大样本观察明显偏差，但少量随机测试不能证明密码学安全；安全能力应来自选用的随机接口与完整的使用流程。

不要在日志中记录用于认证的完整随机值。即便生成本身正确，过期时间、单次使用约束和存储方式没有建立，整个功能仍然可能失去预期保护。