两个AABB矩形碰撞当且仅当在x轴和y轴上均重叠；漏判任一轴、不等号方向错误或坐标系混用（如left/right与x/y/w/h混用、y轴方向不一致）是intersects返回false却视觉“贴边”的主因。
两个AABB矩形碰撞当且仅当它们在x轴和y轴上都重叠；漏判任一轴、不等号方向错误、坐标系混用，是90%以上实际项目中intersects返回false却视觉上“明明贴在一起”的根本原因。
为什么intersects函数必须同时检查x和y轴
分离轴定理在2D下的直接推论：只要一个矩形完全在另一个的左侧、右侧、上方或下方，就一定不相交。反过来，“相交”需要两个条件同时成立：
- x方向有重叠：
a.minX b.minX - y方向有重叠：
a.minY b.minY
常见错误是只写x轴判断，或把y轴条件错写成a.minY （这是比较顶点高低，不是投影重叠）。也有人用<code>abs(center_x1 - center_x2) ，这在AABB上虽等价但引入冗余计算，且无法平滑扩展到3D或后续OBB。
边界接触算不算碰撞？取决于还是<code>
绝大多数UI、游戏、物理引擎默认“边对边”视为碰撞，比如按钮点击、角色贴墙、触发器激活。此时必须用和<code>>=：
立即学习“C++免费学习笔记（深入）”；
bool intersects(const AABB& a, const AABB& b) {
return a.minX <= b.maxX && a.maxX >= b.minX &&
a.minY <= b.maxY && a.maxY >= b.minY;
}若业务明确要求“严格内部重叠”（如某些像素级渲染剔除），才改用和<code>>。但注意：浮点下a.maxX == b.minX极易因精度丢失失效，此时应统一加epsilon，而不是依赖==。
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
坐标系不一致导致minY/maxY逻辑翻车
问题不在算法，而在数据表达。你传进来的minY是不是真的代表“y最小值”？这取决于你的坐标系定义：
- OpenGL纹理坐标、Direct2D、SDL：y向下为正 →
minY是top，maxY是bottom - 数学坐标系、某些物理引擎：y向上为正 →
minY是bottom，maxY是top
一旦结构体成员名（如top）和实际存储值（如存了y最大值）不匹配，整个判断就反了。最稳妥做法是统一用minX/maxX/minY/maxY命名，并确保构造时按真实极值赋值，不依赖“top/bottom”语义。
别在每帧临时拼装AABB结构体
如果每次调用intersects前都从x, y, w, h现场算right = x + w、bottom = y + h，不仅多4次加法，还可能因浮点误差让right略小于x + w，造成边界判定抖动。更糟的是，若w或h为负（比如镜像缩放未校验），right会比x还小，minX/maxX关系彻底错乱。
正确做法是：在对象更新位置/尺寸后，**一次性规整AABB字段**，保证始终满足minX 。检测函数只读，不参与计算。
真正容易被忽略的，是AABB本身是否合法——minX > maxX的矩形传进来，任何intersects实现都会返回错误结果，而且毫无提示。
