用nextInt(9000)+1000生成4位数字验证码，可确保1000–9999范围，避免前导零问题；若需含全零则应明确业务需求再选String.format。
如何用 Random 生成 4 位数字验证码
纯数字验证码最常用在短信登录或表单防刷场景，实现简单但要注意避免前导零导致实际显示为 3 位。直接用 nextInt(9000) + 1000 能稳定得到 1000–9999 的整数，再转成 String 即可。
常见错误是写成 nextInt(10000)，结果可能生成 0、12 这类不足 4 位的字符串；如果后续要拼接或前端对齐展示，会出问题。
- 推荐写法：
String code = String.valueOf(random.nextInt(9000) + 1000); - 不推荐：
String.format("%04d", random.nextInt(10000))—— 看似能补零，但nextInt(10000)包含 0，补零后是"0000"，不符合“随机且非全零”的业务直觉 - 若必须含 0–9 任意组合（包括
"0000"），应明确业务是否允许，再决定是否用String.format
混合字符验证码怎么避开易混淆字母（如 O 和 0）
用户手输时，'O'（大写字母 o）和 '0'（数字零）、'l'（小写 L）和 '1'（数字一）极难区分。直接用 "ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789" 当字典会埋坑。
更稳妥的做法是预定义一个剔除易混字符的字符池，比如："ABCDEFGHJKLMNPQRSTUVWXYZ23456789"（去掉 O、I、0、1）。
立即学习“Java免费学习笔记（深入）”；
- 生成逻辑：用
random.nextInt(pool.length())取索引，循环拼接 - 不要用
UUID.randomUUID().toString().substring(0, 4)—— 含连字符和小写字母，不可控且长度不固定 - 若项目要求大小写敏感校验，注意前端输入常被自动转成小写，服务端比对前统一转大写更安全
SecureRandom 什么时候必须替代 Random
验证码虽非加密密钥，但若用于登录凭证（比如邮箱验证码有效期 10 分钟），被暴力穷举的风险真实存在。此时 Random 的伪随机性不够，输出可预测，必须换 SecureRandom。
典型表现：同一台机器、同一毫秒级种子下，Random 会重复生成相同序列；而 SecureRandom 从操作系统熵池取源（如 /dev/urandom），不可复现。
- 初始化方式：
SecureRandom secureRandom = new SecureRandom();（无需传 seed） - 性能影响：首次调用略慢（约微秒级），但后续无感，别因“听说慢”就弃用
- 注意：
SecureRandom.getInstance("NativePRNG")在某些容器环境（如旧版 Docker）可能阻塞，用默认构造函数更稳
验证码字符串要不要加干扰线或扭曲？
纯文本接口（如短信、邮件、API 返回）不需要图形处理；只有前端需要渲染图片验证码时，才涉及 BufferedImage、Graphics2D 绘制干扰线、噪点、字符旋转等。
重点在于：干扰不是越复杂越好。过度扭曲会导致 OCR 准确率暴跌，反而逼用户反复刷新——实测中，轻微倾斜（±5°）+ 2–3 条细斜线 + 背景浅噪点，平衡了机器识别难度和人工识别体验。
- Java AWT 渲染时，记得调
g2d.setRenderingHint(RenderingHints.KEY_ANTIALIASING, RenderingHints.VALUE_ANTIALIAS_ON)，否则字体边缘锯齿严重 - 别在图片里嵌入可被正则提取的原始字符串（比如把验证码明文写进 PNG 注释区），这是典型的安全疏忽
- 如果只是返回 JSON（
{"code": "A7K9"}），图形干扰完全不相关，别引入awt依赖
