png越压越大因默认未启用zlib压缩，需显式设png.encoder{compressionlevel: png.bestcompression}；jpeg需调优quality（75–85）；gif压缩收益低；应通过image.decodeconfig识别真实格式而非扩展名；resize应选合适插值算法并保留alpha类型；webp需导入_ "golang.org/x/image/webp"注册解码器。
用 golang.org/x/image 读取和重编码图像时，为什么 PNG 越压越大？
默认用 png.Encode 保存时不会压缩，而是写入未压缩的 IDAT 块。必须显式设置 png.Encoder 的 CompressionLevel 字段，否则体积可能翻倍。
- 使用
png.Encoder{CompressionLevel: png.BestCompression}才能启用 zlib 最高压缩 - JPEG 不需要额外配置，但需注意
jpeg.Encode的*jpeg.Options中Quality值（建议 75–85，低于 60 易见明显失真） - GIF 支持有限，
golang.org/x/image/gif不提供调色板优化或 LZW 压缩级别控制，实际压缩收益很低
批量处理多格式图像时，如何统一识别格式并路由到对应编码器？
别依赖文件扩展名——用户可能把 photo.jpg 改成 photo.png。应读取文件头（magic bytes）判断真实类型。
- 用
image.Decode前先调用image.DecodeConfig，它返回Format字符串（如"jpeg"、"png"） - 注意：某些 WebP 或 HEIC 文件
image标准库不支持，会报unknown format；此时需引入github.com/h2non/bimg或调用cwebp外部命令 - 对同一张图多次解码+编码会累积质量损失，务必确保只 decode 一次，然后复用
image.Image实例做 resize 和 encode
用 resize.Resize 缩放图像后，为什么颜色发灰或边缘锯齿严重？
github.com/nfnt/resize 默认用双线性插值（resize.Bilinear），适合快速预览，但对文字、线条图等高频内容不友好。清晰度和性能需权衡。
- 要求高保真：用
resize.Lanczos3（计算开销大，但锐度好） - 纯缩略图展示：
resize.NearestNeighbor最快，但仅适用于像素风或超小尺寸（如 16×16 favicon） - 务必在 resize 后再做 encode —— 先 encode 再 decode 缩放等于白干，且引入二次压缩损伤
- Alpha 通道处理容易被忽略：PNG 透明背景缩放后若没保留
color.NRGBA类型，可能被转成color.RGBA导致半透区域异常
生成 WebP 时为什么总报 no decoder for format webp？
Go 标准 image 包默认不注册 WebP 解码器。必须手动导入并触发 init() 函数注册。
立即学习“go语言免费学习笔记（深入）”；
- 添加导入：
_ "golang.org/x/image/webp"（下划线很重要，表示只执行包初始化） - 编码 WebP 需额外依赖：
github.com/chai2010/webp提供webp.Encode，支持有损/无损、ICC、EXIF 等；标准库只支持解码 - WebP 有损压缩在 Quality=75 时通常比 JPEG 同质轻 25%–30%，但编码速度慢 2–4 倍，线上服务慎用同步编码
