用golang.org/x/image/draw裁剪得黑块，因JPEG解码返回*image.YCbCr而非RGBA，需先转image.RGBA；裁剪前须校验坐标不越界，并显式构造目标Rect。
用 golang.org/x/image/draw 裁剪图片时为什么总得到黑块？
常见原因是源图解码后颜色模型不匹配，draw.ApproxBiLinear 等缩放器只接受 image.RGBA 或 image.NRGBA，而 JPEG 解码默认返回 *image.YCbCr。直接裁剪会导致像素数据错位，显示为黑色或杂色。
- 务必先将源图转换为
image.RGBA：src := image.NewRGBA(srcBounds) draw.Draw(src, src.Bounds(), img, img.Bounds().Min, draw.Src)
- 裁剪区域必须在源图有效范围内，否则
subImage()返回空图像 —— 检查bounds := img.Bounds(); x0, y0, x1, y1是否越界 - 目标尺寸建议用
image.Rect(0, 0, width, height)显式构造，避免依赖原始图宽高导致比例失真
给 PNG/JPEG 添加文字水印时中文乱码怎么解决？
golang.org/x/image/font/basicfont 只支持 ASCII，中文会变成方块或空白。必须加载外部字体文件（如 NotoSansCJK 或思源黑体），并用 font.Face 封装。
- 使用
opentype.Parse加载字体二进制数据（不能直接读路径，需os.ReadFile("simhei.ttf")） - 创建
font.Face时指定 DPI 和字号：face := opentype.NewFace(fontTTF, &opentype.FaceOptions{Size: 24, DPI: 72}) - 绘制前确认目标图是
*image.RGBA，否则text.Draw不生效 - 文字坐标是基线起点，不是左上角 —— 中文建议用
face.Metrics().Ascent调整 Y 偏移
并发处理用户上传图片时 CPU 占用飙升怎么办？
Go 图像操作是纯 CPU 密集型任务，image.Decode + draw.Draw + jpeg.Encode 连续执行会阻塞 goroutine，大量并发请求直接打满 CPU。
Golang Spf13 Viper
下载
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
- 限制并发数：用带缓冲的 channel 控制同时处理的图片数，例如
sem := make(chan struct{}, 4) - 避免重复解码：若需多次裁剪/加水印，解码一次后保存
*image.RGBA到内存，复用而非反复image.Decode - 压缩质量设为 80–90：
jpeg.Encode(w, m, &jpeg.Options{Quality: 85})，过高（100）编码耗时翻倍，过低（50）失真严重 - 对大图（>2000px）先缩略再处理，用
draw.CatmullRom替代ApproxBiLinear质量更好但更慢，按需选择
上传文件名含中文或特殊字符时保存失败怎么处理？
直接拼接 filepath.Join(uploadDir, r.FormValue("filename")) 会导致路径错误或安全漏洞（如 ../etc/passwd）。Gin/echo 等框架的 FormFile 返回的 multipart.FileHeader.Filename 未做清理。
立即学习“go语言免费学习笔记（深入）”；
- 用
path.Base()截掉路径部分：cleanName := path.Base(fh.Filename)
- 用
strings.Map过滤非法字符（Windows 不允许< > : " | ? *，Linux 不允许/ \0） - 生成唯一文件名：组合时间戳 + 随机字符串 + 原扩展名，
fmt.Sprintf("%d_%s%s", time.Now().UnixNano(), randStr(6), ext) - 务必校验
fh.Header.Get("Content-Type")是否为image/jpeg或image/png，防止伪造 MIME 类型绕过检查
*image.RGBA 实例顺序操作；字体、并发、文件名三处不处理，上线后必出问题。 
