image.Decode报“invalid format”是因为未导入对应格式解码器包，需显式import _ "image/jpeg"等；WebP需第三方库；文字水印需正确加载中文字体并理解基线坐标；PNG水印黑边源于Alpha处理不当，应统一图像类型并用draw.DrawMask混合；大图应先DecodeConfig再缩放或ROI处理以节省内存。
image.Decode 报 “invalid format” 怎么办
Go 的 image.Decode 不会自动注册解码器，不导入对应格式包就必然失败——这不是 bug，是设计。你看到的 invalid format 错误，99% 是因为忘了 import _ "image/jpeg" 或 import _ "image/png"。
- JPEG、PNG、GIF 都要显式导入，缺一不可；
import _ "image/gif"只支持基础 LZW，遇到带 Netscape 扩展的动图会静默失败 - WebP 必须用第三方库：
import _ "github.com/chai2010/webp"，标准库完全不支持 - 如果不确定输入格式，先用
image.DecodeConfig读 header（轻量、快），再按config.Format动态 import 对应解码器（需构建时已知）或统一导入常用格式
文字水印渲染失败／显示方块字／位置偏移
文字水印不是调个 DrawString 就完事——它依赖字体解析、基线计算、坐标系转换三重配合。中文尤其容易出问题，核心在于：没加载对字体，或没理解 Y 坐标是基线（baseline），不是左上角。
- 别用
golang.org/x/image/font/basicfont显示中文，它只含 ASCII；必须用opentype.Parse()加载本地 .ttf（如NotoSansCJK或simhei.ttf） text.Drawer.Dot.Y是基线起点，不是字顶。若字号 32，实际顶部大概在Y - face.Metrics().Ascent.Round()，否则文字被切掉上半部分- 中文路径注意用
os.ReadFile("fonts/zh.ttf")，别硬写相对路径；Windows 下反斜杠要转义或用正斜杠
PNG 水印贴上去有黑边／颜色失真
黑边本质是 Alpha 通道没处理好。JPEG 不存透明度，但 jpeg.Encode 会把 RGBA 图里 alpha=0 的区域填成黑色——而 PNG 水印自带 alpha，直接贴到 JPEG 解码结果（通常是 *image.YCbCr）上，混合逻辑就乱了。
- 务必统一图像类型：先用
image.NewRGBA(src.Bounds())创建目标画布，再用draw.Draw(dst, dst.Bounds(), src, image.Point{}, draw.Src)拷贝原图（自动转换色彩空间） - 水印图如果是 PNG，确保它本身是
*image.NRGBA或*image.RGBA；用imaging.Open()比原生image.Decode更省心，它默认返回带 alpha 的类型 - 贴图时别用
draw.Draw简单覆盖，要用draw.DrawMask(dst, r, watermark, image.Point{}, watermark, image.Point{}, draw.Over)，让 alpha 自然混合
大图加水印卡顿／内存爆满
一张 5000×4000 的 JPEG，全量 image.Decode 后可能占 80MB+ 内存；如果只是右下角加个 200×100 的文字水印，完全没必要 decode 整张图。
- 先调
jpeg.DecodeConfig或png.DecodeConfig获取宽高，判断是否需要缩放（比如 > 1920px 宽就等比缩放到 1920） - 缩放后再
Decode，或用imaging.Resize在内存中降采样——它比全量 decode + draw 再 resize 快得多也省内存 - 水印区域小且固定（如右下角 50px 边距），可用
src.SubImage(...)切 ROI 单独处理，避免操作整图
最常被忽略的是 Alpha 预乘和色彩空间隐式转换——这两步不手动控制，不同格式混用时黑边、色偏、panic 都会来得毫无征兆。
