image.Decode后直接读像素易出错，因image.Image接口不保证像素线性排列，Stride可能大于宽度，需用Bounds()配合双层循环或At(x,y)安全访问。
为什么 image.Decode 后直接读像素会出错
Go 的 image.Image 接口不保证像素数据是线性排列的，比如 *image.RGBA 的 Pix 字段是按 RGBA 四字节一组排布，而 *image.NRGBA 是预乘 alpha 的；更麻烦的是 *image.Gray 只存单通道但步长（Stride）可能大于宽度。直接用 Bounds().Dx() 当数组长度遍历，大概率越界或漏行。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 始终用
bounds := img.Bounds()获取有效区域，再用双层循环：外层y从bounds.Min.Y到bounds.Max.Y，内层x从bounds.Min.X到bounds.Max.X - 统一转成
*image.RGBA再处理：用rgba := image.NewRGBA(img.Bounds())+draw.Draw(rgba, rgba.Bounds(), img, img.Bounds().Min, draw.Src) - 避免依赖
Pix底层数组——用img.At(x, y)最安全，虽然稍慢，但对小图（如 100×100）几乎无感
color.Gray 转灰度值时常见的亮度偏差
很多人直接取 c.(color.Gray).Y 当作 0–255 灰度，结果字符画发灰、对比度低。问题在于：原图可能是 RGB，而 color.RGBAModel.Convert 默认用 ITU-R BT.709 加权（0.2126*R + 0.7152*G + 0.0722*B），不是简单平均。直接转 Gray 再取 Y，等于走了两遍转换，中间有舍入误差。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 手动算灰度：用
color.RGBAModel.Convert(c)得到color.RGBA，再按权重公式算，保留浮点中间值，最后uint8截断 - 如果图已为
*image.Gray，直接用Y没问题；但注意它的Y是uint8，范围就是 0–255，无需归一化 - 调试时打一行
fmt.Printf("r:%d g:%d b:%d → gray:%.0f\n", r, g, b, gray)，确认权重是否生效
字符映射表选 " .:-=+*#%@" 还是 " .':,;+*?%S#@&"
短映射表（8–10 字符）适合终端快速渲染，但暗部细节容易糊成一片；长表（15+ 字符）能拉开更多灰阶，但小字号下 ' 和 , 几乎看不出区别，反而增加噪声。关键不在字符多寡，而在「人眼感知亮度」是否均匀分布。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 优先用已验证的感知亮度序列，比如
" .:-=+*#%@&"（共 11 个），其中@最密、.最疏，中间用=和+做过渡 - 避免混用全角/半角符号，终端宽度计算会错乱；尤其别用
█类块状字符——它占两个列宽，会导致换行错位 - 测试时把同一张图分别用两种表输出到文件，用
cat out1.txt和cat out2.txt对比，肉眼能看出哪组明暗分层更自然
调整输出尺寸时 scaleX 和 scaleY 为什么不能都设为 0.5
ASCII 字符画本质是「字符网格」，每个字符高度约是宽度的 1.8–2.2 倍（取决于字体）。如果等比缩放图片，再逐像素对应一个字符，竖向会被严重拉伸，人脸变瘦、树干变细。这不是 Go 的问题，是终端字符的固有比例缺陷。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 横向缩放系数通常比纵向大：例如目标宽度 80 字符，原图宽 400，先算
scaleX = 80.0 / 400.0；再设scaleY = scaleX * 0.45（经验值，适配多数等宽字体） - 用
golang.org/x/image/font/basicfont或直接查当前终端字体的aspect ratio，比硬编码 0.45 更稳 - 缩放后务必用
int(math.Round(...))取整，别用int()截断——否则 79.9 变成 79，少一列，右边留白
字符画最难的不是算法，是让不同终端、不同字体、不同缩放设置下看起来都“差不多”。与其调参数，不如固定输出宽度（比如 80），然后动态算高度，再裁掉底部几行——人眼对顶部内容更敏感。
