Ebiten做2D游戏核心是Update、Draw、Layout三件事：Update以固定60TPS运行逻辑确保时间一致性，Draw按显示器刷新率自适应渲染，Layout返回固定逻辑分辨率以保障缩放与坐标统一。
用 Ebiten 做 2D 游戏，核心就三件事：写 Update 处理逻辑、写 Draw 绘制画面、实现 Layout 定义逻辑分辨率——其他所有问题，基本都源于这三处之一没对齐。
为什么 Update 和 Draw 调用频率不同？
Ebiten 默认以固定 60 TPS（每秒 60 次）调用 Update，确保物理、动画、输入响应的时间步长稳定；而 Draw 按显示器刷新率（如 60Hz / 144Hz）自适应调用，可能一帧 Update 对应多次 Draw（vsync 开启时），也可能跳帧（ebiten.IsDrawingSkipped() 返回 true）。
这意味着：
- 在
Update里做耗时计算（比如遍历几百个子弹做碰撞检测），会直接拖慢逻辑帧率，但渲染仍可跟上——现象是“角色动作卡顿，但画面不撕裂” - 在
Draw里反复调用SubImage或做大量图像裁剪，容易触发 GC 或 GPU 同步等待，导致掉帧——现象是“画面卡，但角色移动仍跟手” -
inpututil.IsKeyJustPressed只在Update中有效，且仅返回true一帧；放到Draw里永远是false
图片加载后显示黑块或 panic: "invalid image: unsupported color model"
Ebiten 要求传给 ebiten.NewImageFromImage 的 image.Image 必须是 rgba.Image 类型。PNG 解码后可能是 color.NRGBA 或带预乘 alpha 的格式，Ebiten 不自动转换。
立即学习“go语言免费学习笔记（深入）”；
最稳做法是手动转成 rgba.Image：
dst := image.NewRGBA(src.Bounds()) draw.Draw(dst, dst.Bounds(), src, src.Bounds().Min, draw.Src)
还要检查是否漏了导入解码器：
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 没加
_ "image/png"→image.Decode返回nil, nil, fmt.Errorf("unknown format") - Mac 上遇到
CGO_ENABLED=0报错（尤其读资源文件时），运行前加CGO_ENABLED=1 go run main.go
Layout 返回值写错会导致 UI 糊、动画跳、碰撞错位
Layout 不是设置窗口大小，而是定义逻辑坐标系的基准尺寸。它返回的宽高，是所有 Draw 中坐标、大小的计算依据，引擎再按实际窗口缩放。
常见错误写法：
- 返回
outsideWidth, outsideHeight（即像素尺寸）→ 高 DPI 屏幕上文字/按钮糊成一片 - 动态算分辨率（比如根据屏幕比例返回不同值）→ 每帧缩放比例变，动画位置跳变、碰撞检测坐标错位
- 把
ebiten.SetWindowSize和Layout混为一谈 → 前者管窗口像素大小，后者只管缩放逻辑
推荐写法：硬编码一个逻辑分辨率，比如 return 800, 600；适配移动端时，用 ebiten.IsFullscreen() + 固定宽高比裁剪，而不是改 Layout 返回值。
资源不释放会持续吃内存，Ebiten 不自动管理生命周期
图片、音频、字体对象一旦通过 ebiten.NewImageFromImage、audio.NewContext 等加载进内存，就一直占着——没有类似 Destroy() 的自动回收机制。
关键点：
-
image.UnsafeImage是唯一能显式释放图片底层内存的方式（截至 2026 年 3 月 27 日） - 频繁切换场景时，旧图层、旧贴图必须手动清理，否则内存只增不减
- 音频资源同理，
audio.Player播放完不Close()，句柄和缓冲区持续占用
最容易被忽略的是：很多人以为 “对象被 GC 就等于资源释放”，但 Ebiten 图片底层绑定了 GPU 纹理，GC 不触碰那部分内存。
