近日，在海外Godot游戏开发者社区，一条题为“I am utterly confused what godot @export/[export] does”的帖子引发热议。发帖人坦言，尽管使用Godot引擎已有段时间，却始终对@export和[export]这两种声明方式感到一头雾水。评论区迅速涌来数十条回复，有人耐心解释，有人感叹“终于有人问出了我一直不敢问的问题”。这一现象折射出Godot新老用户在使用GDScript时普遍存在的知识盲区。
两种写法，同一个目的
首先需要明确：无论是@export还是[export]，它们的核心作用都是将脚本中的变量暴露到编辑器面板上。换句话说，你无需打开代码，就能在Godot的检查器（Inspector）中直接调整该变量的值。这在调整角色速度、生命值、颜色、关卡参数等场景下尤为实用，让“调参”变成一次直观的拖拽或输入，而非反复改代码、运行、再改代码的循环。
[export]是GDScript早期版本的写法，属于旧式注解风格。它位于变量声明之前，例如：
[export] var speed = 300
而@export则是Godot 4.0起引入的新式注解语法，更符合现代GDScript的装饰器风格：
@export var speed = 300
两者在功能上完全等价——都能把speed变量显示在编辑器右侧的属性面板中，允许设计者或你自己实时调整。区别仅在于语法形式和时代背景。Godot 4推荐使用@export，[export]在过渡期仍可使用但已被标记为旧式写法，未来可能逐步弃用。
为什么让人“完全困惑”？
用户的困惑往往来自以下几个方面：
第一，混淆了“导出”与“文件导出”。不少初学者看到export这个词，误以为它与“导出游戏项目”（Export Project）有关，担心在变量前写上@export会影响打包流程。实际上两者毫无关联：这里的“导出”是指将变量从脚本“导出”到编辑器界面，是Godot内部的数据流动，与生成可执行文件无关。
第二，不清楚哪些类型可以导出。基础数据类型如int、float、String、bool自然支持；Vector2、Color、Enum、Array等复杂类型也能导出。但若对自定义类或节点引用处理不当，或忘记添加@export而直接在编辑器中拖拽资源，往往会发现面板上“空无一物”，进而怀疑自己写错了。
第三，新旧文档混杂带来的混乱。网上的教程、论坛回答、老项目代码可能混用[export]和@export，初学者看到两种写法便以为它们有什么微妙差异，甚至怀疑自己漏掉了某个重要的参数配置。事实上，Godot官方在4.x版本的迁移指南中已明确说明：请使用@export。
实战：一个最简单的例子
假设你制作一个平台跳跃游戏，希望角色跳跃高度可调。只需这样写：
extends CharacterBody2D
@export var jump_velocity = -400.0
func _physics_process(delta):
# 跳跃逻辑...
pass
保存脚本后，回到Godot主界面，选中角色节点，你会看到右侧“检查器”面板中出现了“Jump Velocity”属性。修改它的值，无需改任何代码，游戏中的跳跃高度就随之变化。这极大提升了游戏试玩与数值调优的效率。
注意事项与避坑指南
-
不要滥用
@export。只有确实需要在编辑器中调节或提供给策划、美术同事使用的变量，才值得导出。过多导出会让面板变得杂乱，也容易引入误操作。 -
导出数组/字典时谨慎。Godot 4支持
@export var items: Array[int]等带类型导出，但动态修改数组长度、嵌套结构有时会引发编辑器刷新异常，保存为自定义资源可能是更稳妥的方案。 -
节点导出推荐
@export_node_path。如果你需要引用场景中的节点，直接@export var target: Node2D会导致难以在编辑器中指派；改用@export_node_path配合get_node()是更清晰的做法。 -
依赖“导出”实现存档？想清楚。
@export只负责编辑器可见，不负责运行时自动保存。若想记录玩家进度，仍需使用ConfigFile或Resource。
社区共识：写新代码，用新语法
参与该帖讨论的资深开发者一致认为：只要你是基于Godot 4进行开发，请统一使用@export。这不仅是官方推荐的现代写法，也能让代码更整洁、可读性更强。至于旧项目中的[export]，无需急于全部替换，但建议在重构时有意识地迁移。
最终，那位发帖的开发者回复道：“谢谢各位，我现在明白了，@export就是给‘调参党’的福利。”——以此送给每一个曾在编辑器与代码之间迷茫过的Godot学习者。