变量与类型：让数据有清楚的含义

类型是一份约定：speed 是连续速度，use_count 是次数，is_open 是是或否。显式类型能让编辑器更早发现一部分错误，也让你检查 AI 代码时知道函数收的是什么、返回什么。它不会自动验证剧情正确性，也不会替代空引用或文件错误处理。

extends Node

@export var move_speed: float = 120.0
var examine_count: int = 0
var has_examined: bool = false
const DEBUG_TITLE: String = "类型练习"

func _ready() -> void:
    examine_count += 1
    has_examined = examine_count > 0
    print(DEBUG_TITLE, ": ", examine_count, " / ", has_examined)

挂到空 Node 后运行，查看输出。再试着把 examine_count 的初始值换成一段文本，观察编辑器如何指出类型不匹配；理解后撤回这个故意引入的错误。

var speed := 120.0 会从右侧推断 float；var speed: float = 120.0 是显式写出。能推断不代表所有场合都清晰，尤其面对返回 Variant 的接口。@export 把可调参数暴露在 Inspector；它不表示变量自动保存进玩家存档。未使用的参数可以用 _delta 这样的名字表达意图，不要用删除必要参数来消除警告。

假设你看到 var value: float = 120.0，这段代码虽然有类型，仍然很难理解。它可能是速度、等待时间或音量。把它改成 move_speed，并在说明里注明每秒像素，读者才能判断一百二十是否合理。类型说明数据能做什么，名字和单位说明它在游戏里代表什么，三者缺一不可。

做一个分类练习：调查次数用整数，是否读过用布尔值，等待秒数用浮点数，屏幕说明用字符串，平面方向用 Vector2。然后给每个变量写一个不能接受的例子，如次数不能是“很多”、等待时间不应该悄悄解释为帧数。不要把所有开关写成零和一，也不要把所有东西塞成字符串；那会把本来能早发现的错误拖到运行中才出现。

赋值是在改变变量，比较是在得到一个真假结果。读到 has_examined = true，可以翻译成“现在把已调查记为真”；读到 examine_count > 0，则是“次数是否大于零”。每遇到一行代码，先用完整中文翻译，能显著减少把判断误当修改的问题。条件表达式得到布尔值，并不意味着原来的次数会发生变化。

再试着预测两种除法：整数五除以整数二，与浮点数五点零除以二点零，结果是否一样。GDScript 的整数除法会保留整数结果，做百分比或插值时尤其要注意。如果你在计算阅读比例、剩余时间或透明度，先明确期待整数还是连续数值。练习不需要复杂公式，只需在输出中同时打印值与解释，并说清为什么选择这个类型。

@export 变量可以在 Inspector 中配置，因此你后来修改脚本默认值，某个已经保存过配置的场景实例未必按你的想象变化。遇到“速度明明改了却没变”，先在运行时观察实际 move_speed，再检查场景或实例的 Inspector 值。不要连续换三个变量名、重新挂脚本，最后碰巧好了却不知道原因为何。

建议给练习角色配置两个明确速度，例如一百和一百五十，只把它们当教学数值。运行同一条直线路径，确认变化来自哪个属性。再把输入锁设为真，检查即使速度仍是一百五十，角色也不会移动：速度、方向和允许输入是三个不同条件。完成本课时，你应能对一个变量说出名称、类型、单位、初值以及谁会修改它，而不只是知道如何在冒号后面补上类型名称。