beego中用qrcode库生成带自定义样式的二维码需手动控制尺寸、容错率（推荐qrcode.medium）、背景色及logo叠加；qrcode不支持自动加logo，须用golang.org/x/image/draw手动合成，且必须提前设置content-type为image/png，避免乱码或下载。
Beego 中如何用 qrcode 库生成带自定义样式的二维码
Beego 本身不内置二维码能力，得靠第三方 Go 库，qrcode（by sqweek）最轻量、无依赖、支持 PNG/SVG 输出。关键不是“能不能生成”，而是怎么控制尺寸、容错率、背景色和 logo 覆盖——这些直接决定扫码成功率。
默认生成的二维码是纯黑底白图，但实际部署时经常要嵌入品牌色或加 logo。注意：qrcode.Write 只写基础码图，叠加 logo 必须用 image/draw 手动合成，不能指望库自动处理。
-
qrcode.Low容错率最低（7%），适合内容短、空间紧的场景；生产环境建议至少用qrcode.Medium（15%） - 尺寸参数传的是“像素宽高”，不是模块数；传 256 表示输出 256×256 的 PNG，但内部模块数由内容长度和容错率动态决定
- 若需透明背景，别用
png.Encode直接写color.White，应创建image.NRGBA并显式设置 alpha=0 的背景像素
Beego Controller 里实时返回二维码 PNG 的正确写法
常见错误是把二维码字节直接塞进 context.ResponseWriter.Write 却忘了设 Content-Type，导致浏览器下载文件或显示乱码。Beego 的 Ctx.Output.Body() 不会自动设 header，必须手动。
另一个坑是并发生成时没做缓存或限流——qrcode.Encode 是 CPU 密集型操作，单次调用约 2–5ms，但 QPS 过百就可能拖慢整个服务。
- 务必在写响应前调用
ctx.Ctx.ResponseWriter.Header().Set("Content-Type", "image/png") - 避免在 handler 里用
os.Create写临时文件再读取返回——磁盘 IO 拖慢响应，直接用bytes.Buffer构造内存图像 - 对高频固定内容（如静态跳转页），可用
sync.Map缓存 base64 编码后的 PNG 数据，过期时间设 10 分钟足够
用 golang.org/x/image/font 解析含文字的二维码图片失败怎么办
这不是 Beego 的问题，而是误把“识别带文字水印的二维码”当成解析任务。标准二维码解析库（如 github.com/skip2/go-qrcode 的配套解码器 github.com/boombuler/barcode）只认黑白二值图。只要图片里有非二维码区域的文字、边框或半透明 logo，barcode.Decode 就大概率返回 invalid format 或空结果。
真正能稳定识别的路径只有一条：先做图像预处理，再喂给解码器。别试图让解码器“变聪明”，得让它看到干净的二值图。
- 用
gocv做灰度化 + 高斯模糊 + 自适应阈值（cv.AdaptiveThreshold），比单纯threshold更抗干扰 - 裁剪时别依赖固定坐标——二维码位置不固定，得先用
cv.FindContours找最大四边形轮廓，再透视变换校正 -
barcode.Decode对 PNG 的 alpha 通道敏感，输入前务必确保是单通道灰度图，否则返回unsupported image type
Beego 日志里出现 http: response.WriteHeader on hijacked connection 怎么办
这个错误通常发生在你用 ctx.Ctx.ResponseWriter.(http.Hijacker) 尝试接管连接（比如实现 WebSocket 或长连接推送二维码状态），但同时又调用了 ctx.Output.Success() 或其他 Beego 自动写 header 的方法。两者冲突，底层连接已被劫持，不能再走 HTTP 响应流程。
如果你只是做普通二维码生成/解析 API，根本不需要 hijack——这个错误说明你复制了某些 WebSocket 示例代码，却没删干净。
- 检查 controller 方法里是否有多余的
hj, _ := ctx.Ctx.ResponseWriter.(http.Hijacker)调用 - 确认没有混用
ctx.Output.Data和手动WriteHeader—— 二者选其一，别交叉使用 - 若真需要长连接（例如轮询解析进度），改用 Beego 的
WebSocket模块，而不是自己 hijack
