ebiten.rungame 是强制入口，逻辑必须塞进 update、draw、layout；update 必须返回 error 以控制帧循环；draw 应避免误用 screen.fill 破坏混合；layout 需返回固定逻辑尺寸以保障缩放一致性；资源需手动管理生命周期。
ebiten.RunGame 是启动 2D 游戏的唯一入口，不是“可选方案”，而是强制约定——你写的所有逻辑都得塞进 Update、Draw、Layout 这三个方法里，否则画面不动、输入不响应、窗口卡死。
为什么 Update 必须返回 error？
这不是设计冗余，是 Ebiten 的帧控制机制决定的：Update 返回非 nil 错误会直接终止游戏循环，并把错误抛给 log.Fatal。常见踩坑点：
- 忘记在资源加载失败时 return err，结果黑屏无提示，只看到进程还在跑
- 在 Update 里做阻塞 IO（比如同步读文件），导致帧率暴跌甚至假死
- 把本该在 init() 或构造函数里做的初始化（如 audio.NewContext）挪到 Update 里反复调用，CPU 占用飙升
- 实际做法：所有耗时操作提前做完；Update 只做状态更新（如玩家坐标、动画计数器），且必须有明确退出路径（哪怕只是 return nil）
Draw 里不能用 screen.Fill 清屏？
能用，但多数时候不该用——它会覆盖整个画布，包括你后面要画的 UI 层、半透明特效、后处理叠加层。更常见的清屏方式其实是“不主动清”，靠每帧重绘全部内容来隐式覆盖。典型反模式：
- 先 screen.Fill(color.RGBA{0, 0, 0, 255})，再画角色，结果角色边缘发虚（Alpha 混合被破坏）
- 在多图层渲染时，错误地对中间图层调用 Fill，导致上层贴图丢失
- 正确姿势：背景图用 ebiten.DrawImage 绘制；需要纯色底时，确保它是第一张绘制的图层；若真要清屏，优先用 screen.Clear()（比 Fill 更轻量，且不触发混合计算）
为什么 Layout 函数必须返回固定尺寸？
因为 Ebiten 的缩放逻辑全靠它驱动：Layout 返回的宽高，是逻辑坐标系的“基准尺寸”，所有 Draw 中的坐标、大小都按这个基准算，引擎自动缩放到实际窗口。常见误解：
- 把 Layout 当成“设置窗口大小”，其实 ebiten.SetWindowSize 才管这个，Layout 只管“怎么缩放”
- 返回 outWidth, outHeight（即实际像素尺寸），会导致 UI 在高 DPI 屏幕上糊成一片
- 返回动态值（比如根据屏幕比例算出不同分辨率），会破坏帧一致性，动画跳变、碰撞检测错位
- 推荐写法：硬编码一个逻辑分辨率（如 800, 600），让引擎统一缩放；适配移动端时，用 ebiten.IsFullscreen() + 固定宽高比裁剪，而不是改 Layout 返回值
最常被忽略的一点：Ebiten 不管理资源生命周期。图片、音频、字体对象一旦加载进内存，就一直占着——没手动 image.UnsafeImage 或 audio.Player.Close()，即使切场景也不会释放。这不是 bug，是设计选择：你要自己建资源池、做引用计数、在 Update 外围判断是否卸载。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
