三行以内可生成基础二维码：先调用qrcode.encode生成*image.rgba，再用png.encode写入文件或响应体，注意处理error并正确编码。
go-qrcode 生成基础二维码图片要几行代码
能，三行以内搞定。核心是 qrcode.Encode 函数，它把字符串转成 *image.RGBA，再用 png.Encode 写到文件或响应体里。
常见错误是忽略返回的 error，结果生成空图或 panic；还有人直接拿返回的 []byte 当 PNG 数据，其实不是——Encode 返回的是原始像素图像，必须手动编码。
-
qrcode.Encode("https://example.com", qrcode.Medium, 256)是最简调用：内容、纠错等级、尺寸（像素） - 纠错等级用
qrcode.Low/Medium/High/Highest，别传数字，否则编译不报错但行为异常 - 尺寸指二维码模块（module）渲染后的总宽高，不是画布大小；如果内容长+纠错高，实际码点会变小，但输出图仍是 256×256
中文内容乱码或扫码失败怎么调
go-qrcode 默认只支持 UTF-8 编码的字节流，但部分扫码器对非 ASCII 字符的 QR 码解析较弱，尤其微信旧版。不是库的问题，是编码策略和扫码器兼容性问题。
解决方向不是改库，而是预处理输入：
立即学习“go语言免费学习笔记（深入）”；
- 确保原始字符串是合法 UTF-8（
utf8.Valid([]byte(s))可校验） - 对中文较多的场景，用
url.PathEscape或url.QueryEscape编码后再生成，比如qrcode.Encode(url.QueryEscape("你好世界"), ...) - 避免在内容里混用全角标点和控制字符，某些终端扫码器会截断或误判
- 如果必须原样显示中文，且目标扫码器明确支持（如支付宝最新版），可加
qrcode.WithVersion(10)提升容量，但体积会明显增大
自定义颜色、边距、格式导出的坑在哪
go-qrcode 本身不支持填色或加 logo，所谓“定制”其实是拿到 *image.RGBA 后自己画。容易踩的坑是坐标算错、RGBA 通道顺序搞反、边距（margin）单位理解偏差。
qrcode.WithQRCodeColor 和 qrcode.WithBackgroundColor 看似能设色，但仅影响最终 PNG 的像素值，不改变二维码逻辑结构；而 qrcode.WithBoost 这类选项在 v1.4+ 已废弃，用了会静默失效。
- 边距参数叫
margin，单位是“模块数”，不是像素；设为4表示四周留 4 个模块空白，最终图像尺寸 = 模块数 × 单模块像素 + 2×margin×单模块像素 - 想加 logo，得用
draw.Draw把小图贴到二维码中心区域，注意裁剪 logo 尺寸，别盖住定位角标（三个大方块） - 导出为 JPEG？不行。库只输出 RGBA 图像，JPEG 不支持透明，强制转会导致黑底或色偏，坚持用 PNG
并发生成大量二维码时 CPU 占用飙高怎么办
不是因为锁或 goroutine 泄漏，而是 qrcode.Encode 内部做了密集的 Reed-Solomon 编码计算，纯 CPU 绑定，且无法复用中间状态。
实测单次调用在 i7-10870H 上约耗 3–8ms，100 QPS 就吃满一个核。没有银弹，只有两个务实选择：
- 加缓存：对相同内容+参数组合做
sync.Map缓存*image.RGBA，注意设置合理过期（比如 1 小时），避免内存涨死 - 限速降频：用
rate.Limiter控制每秒最大生成数，比硬扛更稳；尤其 Web 服务，别让一个二维码接口拖垮整个实例 - 别碰
qrcode.WithAuto：它会动态选 version，计算量翻倍，且结果不可预测，生产环境一律固定WithVersion
真正难的不是写出来，是想清楚这个二维码谁扫、在哪用、多久有效——这些决定了你该不该缓存、要不要 URL 编码、值不值得加 logo。
