如果你跟我一样用 Godot 做 2D 小游戏，大概率会在某个晚上被这几个场景折腾到没脾气：子弹明明描边画得很大，却从敌人身体中间穿过去；想删一个临时生成的爆炸特效，结果直接报错；明明是像素风，一缩放边缘锯齿就糊成一团。这篇是系列二第 5 篇，前几篇我们解决了场景搭建、角色移动和 TileMap 地图，这一期我想集中处理“游戏真正能打起来”之前绕不开的几个底层问题：物理碰撞为什么不生效、节点到底该怎么删、2D 画面为什么发糊，以及弹幕类游戏里子弹一多就卡该怎么优化。所有代码以 Godot 4 为准，我自己用的 4.2 稳定版，3.x 的读者需要手动对照项目设置的位置。

1. 物理碰撞“神秘穿透”的排查：刚体类型、碰撞层与形状尺寸

战斗系统里最容易被误会的，就是“明明加了碰撞节点，为什么没有反应”。大多数时候不是逻辑错了，而是 Godot 物理引擎压根没把这两个物体当成应该碰撞的对象。

1.1 先确认你用的节点，是物理系统真正认识的“身体”

Godot 2D 里有几类物理相关节点，很多人一上来全用 Area2D，这其实是问题的起点。CharacterBody2D 一般用于玩家或敌方角色，它要靠脚本里的 move_and_slide() 自己移动，物理引擎负责处理它和其他碰撞体之间的阻挡；RigidBody2D 是完全交给物理引擎驱动的刚体，适合可被推开的箱子、被击飞的道具；StaticBody2D 适合墙体、地面这类静止不动的物体；Area2D 本身不参与物理阻挡，它只是“监控区域”，用来检测物体进入、离开或重叠。

如果你给一个应该被玩家撞回去的敌人用了 Area2D，然后希望它像墙一样挡住玩家，那就不可能。反过来，如果子弹需要检测敌人，却不代表子弹本身要被物理引擎“推着走”，那么子弹用 Area2D 是最合适的。常见的错误是你的子弹根本没有设置正确的 Body 类型，而是用了 Node2D + CollisionShape2D，这种组合在 Godot 4 里不会参与任何碰撞检测，因为碰撞形状必须挂在物理节点下面才有效。

Debug 时我习惯先检查：这个节点如果是 Area2D，它不会阻挡玩家，只会发信号；如果是 CharacterBody2D，有没有在 _physics_process() 里调用移动函数；如果是 CollisionShape2D，是不是被错误地加到了 Node2D 下面。把这几件事过一遍，能过滤掉一半的“穿透问题”。

1.2 碰撞层和掩码没对上：别人打不到你，多半是位运算没配好

Godot 的碰撞检测基于 layer 和 mask 两层位掩码。简单说，layer 表示“我站在这层的赛道上”，mask 表示“我看得到哪些赛道上的物体”。子弹要打中敌人，子弹的 mask 必须包含“敌人所在的 layer”，敌人的 mask 也必须包含“子弹所在的 layer”。很多人只设置了子弹的 mask，忘了敌人那边也要反向设置，结果就是监听不到进入的信号。

我在项目资源里一般先约定这张表：

墙体不需要主动检测什么，所以 mask 设为 0。玩家要在地图上走，mask 就要包含世界和敌人。敌人自身要挡住地图，同时要能被玩家子弹打中，所以 mask 里包含世界、玩家以及玩家子弹那两位。这里的数值不是随便拍的，layer 名的规则是 1、2、4、8、16，也就是二进制位从 1 开始左移，方便用位运算组合判断。

在代码里动态设置也很简单：

gdscript复制const LAYER_WORLD := 1
const LAYER_PLAYER := 2
const LAYER_ENEMY := 4
const LAYER_BULLET := 8

func setup_bullet() -> void:
    collision_layer = LAYER_BULLET
    collision_mask = LAYER_ENEMY

强烈建议在 Project Settings > Layer Names > 2D Physics 里把常用层名提前定义好，这样美术或队友接手时，看一眼检测配置就知道节点在跟谁互动，也避免靠数字猜来猜去。

1.3 形状没跟着资源走：CollisionShape2D 的尺寸和缩放比你想的更容易出问题

还有一种“看起来碰到了，其实擦边穿过”的情况，是 CollisionShape2D 的尺寸和 Sprite 不一致。新创建一个 CollisionShape2D 时，默认形状可能是一个很小的胶囊或长方形，你如果把敌人图片调大了一倍，却忘了调碰撞形状，那么子弹只有在子弹中心擦过敌人中心附近时才可能触发检测。另一个坑是父节点被缩放，子节点的碰撞形状会被一起缩放。如果美术资源的缩放比例是 2，碰撞多边形却没跟着调，那么视觉上打中了，物理上还没进入检测范围。

排查时打开编辑器上方的 Debug > Visible Collision Shapes，运行游戏看线框形状是否贴合角色。这个功能可以帮助你快速发现问题。如果角色有复杂的轮廓，直接用 CollisionPolygon2D 手动画节点或者导入资源时生成碰撞轮廓，会比大矩形更精确，代价是物理计算量稍微多一点点，但对普通 2D 游戏来说完全可接受。

2. 生命周期问题：先搞懂 free、queue_free 和字典里的节点，再开始批量删

物理体设置正确之后，第二个高频崩溃点就是节点删除。很多人在脚本里写了 free()，结果下一次物理帧访问这个节点时直接报“Object was deleted or freed”，或者明明删了对象，一运行还是卡顿。

2.1 为什么不再建议直接 free，而是等一帧再 queue_free

free() 是立即释放这个节点，调用后节点马上走出场景树，对象也从内存里丢掉。问题在于，如果这次删除发生在物理回调、动画回调或者信号回调的执行过程中，引擎可能还持有对这个节点的引用，下一行代码再访问它的属性，就会读到一块已经被释放的内存。轻则打印一段你看不懂的 warning，重则把整个游戏带崩。

queue_free() 做的事情是“托管式删除”，把节点放进待删除队列，当前帧结束后统一处理。它不会立刻删除，所以如果你在同一帧里还想用这个节点做收尾，它仍然是有效的。每次我想从信号回调里删除一个刚被击中的敌人，默认都是用 queue_free()，只有一种特殊情况要小心：节点还没有被 add_child() 到场景树里，只是 new() 出来创建了，此时 queue_free() 不会立刻回收，你仍然要手动 free() 或先入树再排队删除。刚创建、还没入树的临时对象，我也会尽可能避免直接 free，而是用对象池之类的机制管理生命周期。

安全起见，我经常用一个辅助写法：

gdscript复制func safe_remove(node: Node) -> void:
    if not is_instance_valid(node):
        return
    if node.is_inside_tree():
        node.queue_free()
    else:
        node.free()

这里的 is_instance_valid() 很重要。Godot 的对象一旦被释放，这个引用不会自动变成 null，它可能是“悬空引用”，直接判空拦不住，用引擎提供的有效性检查才能确定它是否还活着。

2.2 遍历字典批量删除节点：先收集 key，别边遍历边 erase

需要管理大量子弹或者怪物时，很多人会用一个 Dictionary 或数组存放节点引用，类似 bullet_dict[bullet_id] = bullet_node。删除的时候最容易踩的坑，是在遍历的同时直接 erase，这会让遍历顺序乱掉，甚至有漏删风险。Godot 对遍历时修改字典的限制在两个版本里不太一样，但一致的安全做法是：先在一个临时数组里收集要删除的 key，遍历完再去删除。

正确示范大概是这样：

gdscript复制var bullet_map := {}

func check_bullets() -> void:
    var to_remove: Array[int] = []
    for key in bullet_map:
        var bullet: Area2D = bullet_map[key]
        if not is_instance_valid(bullet) or bullet.is_queued_for_deletion():
            to_remove.append(key)
            continue
        if bullet.global_position.length() > 2000:
            to_remove.append(key)
    for key in to_remove:
        if bullet_map.has(key):
            bullet_map[key].queue_free()
            bullet_map.erase(key)

我个人的习惯是，如果有需要跨帧保留的实体，就让它自带一个唯一 ID，字典的 key 用 ID 而不是节点对象本身。这样节点即使被释放，ID 也不会误伤到别的实体。如果只是清空全部子弹，直接遍历调用 queue_free() 后统一 clear() 也可以，但前提是你在清空引用前不要继续使用字典里的过期引用。

2.3 从父节点删除子节点后，记得把外部引用一并清掉

另一个常见场景是：子弹命中敌人后，敌人从父节点身上被移除，但 bullet_map、敌人列表、UI 技能指向器等外部脚本还保存着敌人引用。代码看上去没崩，但偶尔卡顿，因为节点虽然释放了，旧引用还停在各种容器里，每次遍历都要判断一次有效性，白白增加开销。

模块化设计的正面做法是让每一个需要删除的实体自己发出信号，例如 died，由管理它的系统监听信号并统一清理所有引用。场景结构不复杂时，也可以直接在父容器里用 child_exiting 信号监听，但要注意它可能延迟触发，不能把它当成同步的 free。我的建议很简单：管理任何节点池或实体集合时，都让“谁创建，谁负责清理”，不要让无关脚本到处持有同一个节点引用。这不只是内存问题，还是维护性问题。

3. 2D 画面又糊又锯齿：从项目设置到相机，逐层找原因

物理不反弹的问题解决后，视觉上的锯齿问题往往紧随而至。Godot 2D 默认渲染已经处理了很多，但做像素风或精细线条风的人，几乎都会在某个配置上翻车。锯齿问题的根源不是单点的，而是坐标、纹理过滤、缩放方式三者共同作用的结果。

3.1 项目缩放模式直接决定“放大是否模糊”

大多数 2D 游戏不会固定在一个原始分辨率窗口里运行，而是要自适应玩家屏幕，这时就要依靠窗口缩放设置。Godot 4 的项目设置里，display/window/stretch/mode 是核心。如果你用低分辨率做像素素材，推荐填 canvas_items，然后在 aspect 里选 keep，这样画布内容会等比缩放，保持游戏原始比例。如果你选 viewport，整个窗口像一个 Viewport 纹理一样被拉伸，对像素风来说更容易出现模糊边缘。

这里有一个反直觉的地方：canvas_items 下如果默认纹理过滤是线性（Linear），画面放大后边缘会被插值，看起来就会发虚。所以像素游戏我通常会把 rendering/textures/canvas_textures/default_texture_filter 项目设置改成 Nearest，这样像素点会保持锐利。而如果你做的是手绘风、高分辨率素材，反而不要盲目关掉 Linear，否则斜线边缘会产生明显锯齿感。无论是哪种，都不要把默认纹理过滤当成一个全局开关来套用，单个 Sprite 可以通过 texture_filter 节点属性单独覆盖默认值，这是更精细的做法。

3.2 像素对齐和相机平滑：运行起来一移动就发虚的主角

静态画面锐利不代表运行时也锐利。Godot 的物理和渲染可能发生在浮点坐标上，角色有时候会停留在一个“半像素”的位置。为了显示平滑，引擎会对纹理做插值，结果就是像素风的角色边缘出现淡淡的重影或闪烁。

所以做像素游戏时，我通常会在项目设置里打开这两个选项：rendering/2d/snap/snap_2d_transforms_to_pixel 和 rendering/2d/snap/snap_2d_vertices_to_pixel。前者负责把节点的 Transform 对齐到整数像素位置，后者负责把顶点坐标对齐。两个都打开，能明显减少角色和地图移动时产生的抖动。代价是相机平滑移动会轻微被破坏，摄影机每帧都停在像素格上会显得不够柔和，但像素游戏恰恰需要这种硬朗感。

Camera2D 还有一个坑是 position_smoothing_enabled，它让相机移动带缓冲。如果你开启了像素对齐，这个平滑反而会引入不连续感，因为每一帧相机位置都是浮点数，而像素对齐会把它“吸”到整数位。要么关闭平滑，要么你自己控制相机目标位置，手动在 _process() 中做插值，再对齐到像素，效果会好很多。运行中如果角色快速转身或产生旋转，碰撞形状和视觉边界也会出现少量虚线感，这种通常无法完全消除，只能靠更高分辨率的原始素材掩盖。

3.3 检查导入设置：不是所有糊都是运行时造成的

还有一部分“锯齿”其实在资源导入阶段就决定了。选中图片资源，查看 Import 面板，如果纹理的 Filter 选项是默认的 Linear，而且图片被放大很多倍，那么边缘插值一定会带来模糊。许多引擎默认会对纹理生成 mipmap 来优化缩小显示，但 2D 像素素材通常不需要 mipmap，关闭后能避免一些远处缩小后的细节丢失问题。Godot 4 里如果图片是像素风，我一般把导入设置中的 Filter 改成 Nearest，Mipmaps 关闭，Repeat 根据 TileSet 的需求决定。

总结一下排查顺序：先看窗口拉伸模式，再看纹理过滤，最后开像素对齐。很多朋友只改了一个选项，发现没用就放弃，实际上这三个设置是一套组合拳。尤其当你把画面从窗口切换到全屏时，如果没有正确设置拉伸，锯齿和模糊会同时出现，那种观感最让人头疼。

4. 弹幕游戏的性能核心：别让每个子弹都成为场景树里的“重量级对象”

Godot 做弹幕游戏完全可行，但如果你用最简单粗暴的方式，每帧创建一个发射场景，很快就会发现场景树里塞了几百个节点，然后帧率开始直线下跌。解决思路有两层：减少节点的生成销毁频率，以及考虑用物理查询代替一部分物理节点。

4.1 生成节奏：从“每帧生成”到“时间表驱动”

写弹幕最容易犯的错误是把发射逻辑直接放在敌人的 _process() 里，然后不加节流。每帧生成意味着每秒钟几十个新节点，如果子弹存活时间还很长，内存和节点数都会增长很快。正确的做法是给发射动作设置节奏，比如用一个计时器控制间隔，或者用一个弹幕表驱动。

简单版是：

gdscript复制@export var fire_interval := 0.2
var timer := 0.0

func _physics_process(delta: float) -> void:
    timer -= delta
    if timer <= 0.0:
        fire_a_bullet()
        timer = fire_interval

想要做复杂弹幕，不要把这些数据写死在脚本里。可以把弹幕模式定义成数据结构，每一组弹幕对应一个冷却时间、子弹数量、旋转偏移、速度等，这样调节起来不用反复改代码。比如：

gdscript复制var pattern := {
    "count": 12,
    "speed": 180.0,
    "interval": 0.4,
    "offset": 0.0,
}

运行时根据这些参数去 release 子弹，逻辑就能和数值分离。这也是弹幕游戏里非常常见的做法，很多看起来华丽的 Boss 攻击，本质上只是“一组角度计算 + 定时发射”。

4.2 用对象池管理子弹：启动时预创建，运行时只做状态切换

对象池的核心逻辑很简单：不要反复创建和销毁节点，而是预先创建一组子弹，不用的隐藏起来放进池子里，要发射时就去找一个隐藏的子弹，重新设置位置、速度和外观，用完之后再隐藏回去。这一步能省掉节点创建和销毁的大部分开销。

我用 Area2D 做子弹时，会给它一个 active 状态。初始时全部隐藏，monitoring 也关闭，发射时再打开。代码大致是这个结构：

gdscript复制extends Area2D

var velocity := Vector2.ZERO
var active := false

func fire(pos: Vector2, dir: Vector2, spd: float) -> void:
    global_position = pos
    velocity = dir * spd
    active = true
    show()
    set_deferred("monitoring", true)

func recycle() -> void:
    active = false
    hide()
    set_deferred("monitoring", false)

池管理器很简单：

gdscript复制@export var bullet_scene: PackedScene
var pool: Array[Area2D] = []

func acquire() -> Area2D:
    for bullet in pool:
        if not bullet.active:
            return bullet
    var new_bullet := bullet_scene.instantiate()
    add_child(new_bullet)
    pool.append(new_bullet)
    return new_bullet

func release(bullet: Area2D) -> void:
    bullet.recycle()

这里有两点值得注意。第一，set_deferred("monitoring", true) 不能在物理回调中直接改，否则可能报“Can't change this state while flushing queries”。第二，隐藏的子弹最好同时关闭碰撞检测，因为一个不显示的 Area2D 如果还在检测碰撞，就会白白消耗 CPU。对象池看起来比直接 instance() 多写了几行代码，但这是弹幕游戏能不能稳定跑到几百颗子弹不卡的关键。

4.3 高频子弹的可选升级：用射线查询代替逐子弹碰撞体

如果子弹数量非常大，比如上千颗，即使对象池能撑住节点数量，每颗子弹都要参与物理检测也未必撑得住。这时可以考虑让子弹本身不附带碰撞体，而是在每帧用 PhysicsDirectSpaceState2D 做一次射线查询，向目标方向投射一小段射线。虽然射线查询也是物理检测，但省去了 SceneTree 管理和大量 Area2D 节点的开销，在特定场景下比几百个 Area2D 更轻。

例如一个非常简单的“高射速激光子弹”：

gdscript复制extends Node2D

var velocity := Vector2.ZERO

func _physics_process(delta: float) -> void:
    var motion := velocity * delta
    var space := get_world_2d().direct_space_state
    var query := PhysicsRayQueryParameters2D.create(
        global_position,
        global_position + motion,
        0b100  # 敌人的碰撞层，这里写的是 layer 3 的位值 4
    )
    var result := space.intersect_ray(query)
    if result:
        global_position = result.position
        if result.collider.has_method("take_damage"):
            result.collider.take_damage(1)
        queue_free()
    else:
        global_position += motion

这种方式的缺点是如果子弹速度极快，运动距离太大，射线仍然可能跳过极小的敌人。你可以把一帧旅程拆成多段查询，或利用上一帧与当前帧位置之间的连续射线。实际上很多街机风格弹幕游戏并不会给每颗小子弹都做精细的体碰撞，而是用射线或点检测代替，因为玩家看不到纳米级碰撞精度，只需要“打中没打中”这个结果足够快就行了。

5. 让战果“看得见”：字体绘制反馈与屏幕显示层级的几个细节

战斗系统跑通以后，游戏立刻会变得像样起来，因为玩家需要实时看到伤害数字、Boss 血条、得分和预警文字。Godot 里直接做伤害飘字，往往比想象中更容易踩坑——尤其当你需要同一时间显示几十个飘字时。

5.1 用 Label 画伤害数字时，不要频繁创建和销毁节点

最直接的伤害飘字是 Label，但如果你每个伤害数字都动态 instantiate() 一个 Label，再让它飘一下然后删除，等战斗激烈时，场景树会被大量 UI 节点压垮。更好的方式和子弹的思路一致：预先创建一组 Label，放到一个节点池里，每次需要飘字时取一个未在使用的 Label，设置位置、文本、颜色，用 Tween 让它向上移动并淡出。

一个极简的飘字池做法是把所有文本放在同一个 Control 下面，用一个数组索引记录当前可用项，简单循环分配就可以。这里还要注意 Label 默认字体。Godot 4 的内置字体在低分辨率下可能显得不够清楚，如果你导入了自定义字体，最好在主题 Theme 里统一设置，而不是每个 Label 单独覆盖，否则后续换字体时要把几十个 Label 挨个改一遍。

如果做的是像素风游戏，字体的 font_size 和实际像素分辨率比例也很关键。一个 16 号字体在 320x180 的游戏分辨率里可能超大，但切成整数倍缩放到 720p 后却又显得不够锐利。我通常会在项目设置里定义一套 UI 缩放适配，并且把字体资源导入为可复用资源，不要每帧去加载字体文件。

5.2 用 CanvasLayer 把 UI 层级分开：别让战斗元素盖住飘字

另一类显示问题是层级混乱。2D 游戏里，角色、子弹、血迹特效、伤害飘字如果全都在同一层，可能出现伤害数字被敌人身体盖住的状况。控制显示顺序有几个方法。纯 2D 节点时，可以调整 z_index，值越大越靠上；而涉及 UI 时，更推荐用 CanvasLayer，把 HUD 和飘字放到独立的 CanvasLayer 里，并将其 layer 设置为较高的层。CanvasLayer 会把该层下的所有内容统一绘制在指定顺序，不会随着主场景里的 z_index 变化而混乱。

我用得比较顺的结构是这样的：主世界节点放在默认层，受伤飘字放到 CanvasLayer 的 layer 10，HUD 放到 layer 20。这样即使有大量子弹和敌人遮挡，飘字也有稳定的最高优先级。飘字池里的 Label 不需要设置 z_index，直接放在那个 CanvasLayer 的容器里即可。

5.3 绘制顺序和性能：不要把所有绘制都堆在一个 CanvasLayer

CanvasLayer 很方便，但也不是越多越好。如果每个特效都开一个 CanvasLayer，反而可能影响绘制批处理和排序性能，因为引擎要按层拼接绘制指令。常见的做法是：普通 World 一个层，VFX 层一个，UI 层一个，就足够应付绝大多数 2D 游戏了。

关于绘制批处理，还有一个小技巧：外观相同的子弹，如果 Sprite 纹理和材质一致，它们会被引擎尝试合批，性能会比每颗子弹各自使用不同材质高很多。做弹幕游戏时，如果不同子弹来自不同美术资源，尽量让同一阶段的弹幕使用同一张图集和同一个 CanvasItemMaterial，并且避免在飞行中修改颜色和透明度太频繁，不然会导致渲染批次上升。这个点在做很多同屏子弹的时候，比单纯堆对象池更关键。

这些字体和层级的问题，本质上都属于“玩家看不看得见”的体验问题。战斗逻辑再完美，如果玩家看不清伤害和弹幕预警，前面做的物理和性能优化都会大打折扣。我在实际做 2D demo 时，最常回头检查的清单就是：碰撞层是否一致、删除节点是否用 queue_free、画面设置对不对、对象池是否正常工作，以及 UI 层是否压住了战斗层。把这些固定成自检流程之后，后面再往里加敌人 AI、Boss 状态机，就不用频繁被这些底层问题打断思路了。