为什么勾选了Collider的isTrigger，却仍触发OnCollisionEnter而非OnTriggerEnter？

Question

常见原因：**Collider 的 `isTrigger` 属性虽已勾选，但另一个参与碰撞的 Collider 未启用 `isTrigger`，且双方均具备有效 Rigidbody（至少一方非 kinematic）——此时 Unity 仍按物理碰撞处理，触发 `OnCollisionEnter` 而非 `OnTriggerEnter`。** 关键规则是：**Trigger 交互需“双向约定”**：仅当 *至少一方* 是 trigger，且 *另一方不是 trigger*（即普通 Collider）时，才触发 `OnTriggerEnter/Stay/Exit`；若双方都是 trigger，则不产生任何碰撞/触发回调；若双方都不是 trigger，则走物理碰撞流程。此外，若触发方无 Rigidbody（或 Rigidbody.isKinematic = true 且未与非 kinematic Rigidbody 碰撞），也可能因缺少物理参与而静默失败。务必检查：① 哪个 Collider 是 trigger；② 另一方 Rigidbody 是否存在、是否启用、是否为 kinematic；③ 脚本是否挂载在含 Rigidbody 的物体上（`OnTriggerEnter` 要求至少一方有非 kinematic Rigidbody 或另一方主动运动）。

Answer 1

```html

一、现象层：为什么 OnTriggerEnter 从未被调用？

这是 Unity 开发中最高频的“静默失效”问题之一：开发者明确勾选了 isTrigger = true，挂载了含 OnTriggerEnter 的脚本，运行时却完全无响应——既不触发 OnTriggerEnter，也不报错，日志空空如也。表面看配置无误，实则底层物理系统已按“刚体碰撞”路径执行，直接跳过触发器逻辑。

二、机制层：Unity 触发器交互的三大黄金契约

Unity 的触发系统并非单向标记生效，而是基于严格物理参与规则的双向协商机制。其核心契约可结构化为下表：

Collider A 状态	Collider B 状态	Rigidbody 参与要求	回调行为
Trigger ✅	Non-trigger ❌	至少一方具 非 kinematic Rigidbody（或 kinematic Rigidbody 主动运动）	✅ OnTriggerEnter/Stay/Exit
Trigger ✅	Trigger ✅	任意（即使有 Rigidbody）	❌ 无任何回调（零事件，非错误）
Non-trigger ❌	Non-trigger ❌	至少一方具非 kinematic Rigidbody	✅ OnCollisionEnter/Stay/Exit

三、诊断层：五维交叉验证检查清单

1. Trigger 归属确认：使用 Debug.Log($"[{name}] isTrigger: {GetComponent().isTrigger}"); 显式输出双方 Collider 的 isTrigger 值；
2. Rigidbody 存在性验证：检查双方 GameObject 是否挂载 Rigidbody，且 enabled == true；
3. Kinematic 状态解耦：若某方 Rigidbody.isKinematic == true，需确保另一方为 非 kinematic 且处于运动中（静止 kinematic 不驱动 trigger）；
4. 脚本宿主合规性：OnTriggerEnter 必须挂载在至少一方含有效 Rigidbody 的 GameObject 上（不能仅挂于纯 trigger + 无 Rigidbody 物体）；
5. Layer Collision Matrix 审查：Project Settings → Physics → Collision Matrix 中，双方 Layer 必须勾选，否则物理系统直接忽略交互。

四、根因层：典型失效拓扑与修复路径

以下 Mermaid 流程图揭示最常见失效链路及分支修复策略：

flowchart TD
    A[触发器未响应] --> B{A.isTrigger ?}
    B -- 否 --> B1[立即检查 Collider 配置]
    B -- 是 --> C{B.isTrigger ?}
    C -- 是 --> C1[双方均为 Trigger → 无回调
✅ 修复：将 B 改为 Non-trigger]
    C -- 否 --> D{B 是否有 Rigidbody？}
    D -- 否 --> D1[静默失败
✅ 修复：为 B 添加非 kinematic Rigidbody]
    D -- 是 --> E{B.isKinematic ?}
    E -- 是 --> E1[需确认 A 是否运动/非 kinematic
✅ 修复：设 A 为非 kinematic 或启用 MovePosition]
    E -- 否 --> F[正常应触发
⚠️ 检查 Layer Matrix / 脚本挂载位置]

五、工程层：防御性编码实践模板

在关键触发逻辑入口处嵌入运行时自检，避免上线后难以复现：

void OnTriggerEnter(Collider other) {
    var selfRb = GetComponent();
    var otherRb = other.attachedRigidbody;
    
    if (!selfRb && !otherRb) {
        Debug.LogError($"[TriggerGuard] Neither {name} nor {other.name} has Rigidbody → OnTriggerEnter ignored");
        return;
    }
    
    if (selfRb?.isKinematic == true && otherRb?.isKinematic == true) {
        Debug.LogWarning($"[TriggerGuard] Both kinematic → unreliable trigger. Consider using non-kinematic or MovePosition.");
    }
    
    // ✅ 实际业务逻辑
}

六、进阶层：物理模拟精度与帧率敏感性

当使用 Rigidbody.interpolation = Interpolate 或 Extrapolate 时，高速穿越 trigger 区域可能因插值采样遗漏导致 OnTriggerEnter 丢失；此时应启用 Rigidbody.collisionDetectionMode = Continuous（对 Dynamic Rigidbody）或 ContinuousDynamic（对 Kinematic Rigidbody 主动移动时）。该设置虽增开销，却是高动态场景的必要保障。

七、架构层：规避陷阱的模块化设计模式

推荐采用「Trigger Proxy」模式：将所有 trigger 逻辑抽象为独立组件（如 TriggerSensor），强制要求其必须关联一个专用 TriggerRigidbody（非 kinematic，质量=0.001，冻结全部旋转/位移），由该代理 Rigidbody 主动运动并承载脚本。此设计将 trigger 行为与表现层解耦，彻底规避 “谁该带 Rigidbody” 的权责模糊问题。

```