场景实例、资源与路径

磁盘上的 player.tscn 是可加载的场景资源；PackedScene 是这种打包场景在程序中的表示；instantiate() 创建真正的节点实例，add_child() 才把它放入场景树。同一份场景可以产生多个实例，但它们使用的某些 Resource 可能仍然共享。

extends Node2D

# 先在练习项目中创建并保存 player.tscn。
@export var player_scene: PackedScene

func _ready() -> void:
    if player_scene == null:
        push_error("请在 Inspector 指定 Player Scene")
        return
    var player: Node = player_scene.instantiate()
    add_child(player)

1. 给空 Node2D 挂脚本，把 player.tscn 拖到 Inspector 的 Player Scene。
2. 运行并在 Remote 场景树中找新建的节点。
3. 清空资源引用后再运行，观察错误提示是否清楚；这属于依赖缺失测试。

两盏练习灯共享同一个材质资源时，修改材质可能影响两盏。两张物品卡共享静态名称与图标通常是好事；把某个玩家的临时“已拿走”标记写进共享资源，往往不是。先区分静态定义与运行状态，再决定是否需要资源副本或独立状态对象。

在 FileSystem 面板中找到一张练习图片，先确认文件名，再找到引用它的 Sprite2D。你要建立的不是“图片在某个文件夹”的印象，而是一条具体链路：源文件存在，纹理资源被节点引用，节点进入运行场景，最后被当前视野显示。同一个文件可以被几个节点引用；文件夹里有图片却没有任何节点引用，也不会自动出现在游戏中。

1. 记录图片在工程中的 res:// 路径和引用它的节点名称。
2. 在 Inspector 临时清空纹理，运行，观察这是缺少显示资源而不是节点消失。
3. 恢复纹理，确认画面回来。
4. 只在练习工程中使用 Godot 的文件管理操作调整文件位置，并在操作后检查引用；不要一开始就在外部终端批量改名。

设想一张教学资料卡，标题和说明固定，玩家是否打开过它会变化。标题、说明、图标属于定义；屏幕上当前显示的那张卡属于节点实例；这次游戏是否读过属于运行状态。把三者写成三列，之后每增加一个字段都先问它属于哪列。例如“已读次数”不是图片属性，也不应该因为两张卡共用图标就自动共享。

可以先不写背包系统，只放两个 Button 和一个 Label。两个按钮引用同一份静态定义，分别记录自己的点击次数。再故意让它们使用同一个计数变量，观察为什么点击左边会影响右边。这个对照帮助你理解共享不是错误本身：共享标题减少重复维护，共享独立进度却可能违背需求。是否复制资源应由数据含义决定，不是看到联动就把所有资源全部复制。

报错里出现找不到节点时，先看它从哪个节点出发查找；出现打不开资源时，先看 res:// 下的文件；保存失败时，再看 user:// 的应用数据位置。不要拿 Windows 磁盘路径去修复一个节点相对路径。为问题记录完整错误信息，同时写出“这是节点路径还是文件路径”，往往就能把调查范围缩小一半。

导出前还有一项很有价值的自查：全文搜索自己电脑的盘符，逐条区分文档说明与运行时代码。说明文档记录工作目录没有问题，但游戏运行时依赖 D 盘上的个人图片，就可能只在开发机上成功。练习的完成证据应包含：清空资源能得到清楚提示；恢复引用后正常；关闭重开工程后引用仍成立。真正的分发可靠性还需要后续导出测试，不能由编辑器中的一次显示代替。