Go中需用接口解耦碰撞逻辑：定义Shaper接口含BoundingBox()和DoesCollide(other Shaper)，各几何体实现它；Collider接口仅含CollisionShape()方法；AABB与Circle碰撞逻辑应分离实现，避免混用if-else。
Go 里没有“内置碰撞检测”，得自己写逻辑或选对抽象方式——直接硬编码类型判断（比如 i.(type) 断言为 Circle）是典型踩坑点，后续扩展和维护成本会陡增。
用接口解耦形状与行为，别嵌入结构体搞继承式伪装
很多新手在 Rock 里嵌入 Circle，然后试图用类型断言把它当 Circle 用，结果 switch c2 := i.(type) 永远匹配不到——因为 Rock 和 Circle 是两个独立类型，Go 不支持隐式向上转型。
正确做法是定义清晰的接口契约：
-
Shaper接口暴露BoundingBox()和DoesCollide(other Shaper)，所有几何体（*Circle、*Rectangle）都实现它 -
Collider接口只有一方法：CollisionShape() Shaper，让游戏实体（Rock、Spaceship）返回自己的形状实例 - 实体内部不嵌入形状，而是持有字段（如
shape collision.Circle），再通过指针方法返回&r.shape满足接口要求
AABB 和 Circle 碰撞逻辑要分开实现，但调用统一
矩形（AABB）和圆形的数学判据完全不同，混在一个函数里靠 if-else 分支不仅难读，还容易漏掉坐标系方向问题（比如 Ebitengine 的 Y 轴向下，而数学公式默认向上）。
立即学习“go语言免费学习笔记（深入）”；
推荐按形状实现各自逻辑：
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
-
AABB：检查 x、y 两轴投影是否重叠，即rect1.Min.X rect2.Min.X等四连判断 -
Circle：用距离平方避免开方，dx*dx + dy*dy - 所有
DoesCollide方法接收Shaper，内部再根据other.BoundingBox()做 dispatch，比如圆对矩形可先用 AABB 快筛，再做精确点圆距判断
性能敏感场景必须加粗略检测（Broad Phase）
每帧对全部物体两两调用 DoesCollide 是 O(n²)，100 个对象就是近 5000 次计算——实际项目中很快卡顿。
必须引入空间加速结构：
- 静态地图可用“格子索引”：把世界划分为单元格，每个物体登记进其覆盖的格子，只检测同一格或邻近格内的物体
- 动态密集场景建议用
quadtree（二维）或broadphase包（如github.com/hajimehoshi/ebiten/v2/vector配套方案），避免手写树逻辑 - 注意：粗略检测返回的是候选对（
[][]Collider），精细检测（Collide(c1, c2)）只作用于这些对，不是全量
运动物体要预测位移，否则高速下穿模
仅检测当前帧位置，速度一快（比如子弹每帧移动 10 像素），就可能从墙一边直接跳到另一边，完全错过碰撞。
解决方法不是暴力减小时间步长，而是做 Swept / Continuous 检测：
- 对移动中的矩形，传入位移向量
shift mgl32.Vec2，计算移动前后的包围盒并检查路径是否与目标相交 - 圆形可转为“胶囊体”（capsule）：起点圆心 + 终点圆心 + 半径，用线段到圆心距离判据
- 简单替代方案：把位移拆成多步小步长（如 0.5 像素/步），但需控制步数上限，避免死循环
真正麻烦的从来不是单个碰撞公式，而是如何让不同形状、不同运动状态、不同更新频率的对象，在不耦合、不爆炸的前提下，共享同一套检测入口。接口返回值生命周期、包围盒缓存时效性、以及坐标系转换时机，这三个点最容易在联调时突然崩掉。
