BufferedImage构造时选错类型会导致drawString模糊或透明
直接用 BufferedImage.TYPE_INT_ARGB 绘制文字，大概率出现灰蒙蒙、发虚、边缘半透明的验证码文字——这不是字体问题，是颜色通道没对齐。ARGB带alpha，但多数验证码不需要透明背景，绘图上下文默认会混合alpha，文字就“洇”开了。
- 优先选
BufferedImage.TYPE_INT_RGB：纯RGB无alpha，Graphics2D.setColor()设置的纯色能100%落笔 - 如果必须用ARGB（比如后续要叠加水印），务必在绘图前调用
g2d.setComposite(AlphaComposite.Src)，绕过alpha混合 - 别用
TYPE_BYTE_BINARY或TYPE_BYTE_INDEXED：它们不支持抗锯齿，小字号文字直接糊成一块
drawString位置偏移一两个像素？注意fontMetrics的baseline计算
验证码常靠“垂直居中”文字来提升识别难度，但 Graphics2D.drawString() 的y坐标是基线（baseline）位置，不是文字顶部。用 getHeight() 除以2加y，结果往往偏高——字被切掉头顶，或下沉太多留白。
- 正确做法：先获取
FontMetrics fm = g2d.getFontMetrics()，再算y = (height - fm.getAscent()) / 2 + fm.getAscent() -
fm.getAscent()是基线到顶部距离，fm.getDescent()是基线下方距离，两者相加才是视觉高度 - 别信IDE自动补全的“centerY”，它不考虑字体度量，只按矩形框算
抗锯齿开关不生效？得同时设RenderingHints和字体渲染属性
只调 g2d.setRenderingHint(RenderingHints.KEY_TEXT_ANTIALIASING, RenderingHints.VALUE_TEXT_ANTIALIAS_ON)，有时还是锯齿明显——尤其Windows上默认用ClearType，Java的hint可能被绕过。
- 必须配对设置：
g2d.setRenderingHint(RenderingHints.KEY_RENDERING, RenderingHints.VALUE_RENDER_QUALITY) - 更稳妥：创建字体时加上渲染提示，例如
new Font("Arial", Font.BOLD, 14).deriveFont(Collections.singletonMap(TextAttribute.TRACKING, -0.03f))（微调字间距防粘连） - Linux下可能需额外加JVM参数
-Dawt.useSystemAAFontSettings=lcd，否则hint无效
生成后图片变暗或色偏？检查ColorModel和写入格式兼容性
用 ImageIO.write(bufImg, "png", out) 没问题，但换成 "jpg" 时，验证码线条突然变粗、颜色发灰——JPEG不支持alpha，而BufferedImage若用ARGB创建，写入JPEG会强制转为RGB并丢弃alpha信息，触发内部颜色空间转换，导致色值偏移。
立即学习“Java免费学习笔记（深入）”；
- 写JPEG前，确保BufferedImage类型是
TYPE_INT_RGB，避免隐式转换 - 不要依赖
bufImg.getColorModel().getTransferType()判断是否安全，它返回DataBuffer.INT不代表输出格式兼容 - 调试时用
ImageIO.getImageWritersByFormatName("jpg")检查实际writer是否支持你的BufferedImage类型，有些老JDK writer对INT_RGB支持不全
事情说清了就结束。BufferedImage看着简单，但每个构造参数、每行draw调用背后都卡着图形管线的实际行为，漏掉一个hint或类型匹配，验证码就可能被OCR多扫三轮。
