Luau 局部作用域：代码读到的是哪个路线名称

先问这一行能看见什么 #

设想一条虚构的步行路线，总名称是 Harbor，其中一个可选分支暂时叫 Tower。现在要回答的不是玩家走到哪里，而是某一行代码能读取哪个名称。作用域指的是已声明变量在代码中可被访问的范围；它不是场景物体之间的距离，也不是玩家在路线中停留的时间。把程序边界与游戏空间分开，后面的判断才不会混淆。

先把示例当作普通 Luau 程序阅读。记录每个变量在哪里声明、属于哪个代码块，再按执行顺序跟踪 print。本练习只操作内存中的字符串，不会重命名 Roblox 地点、改变玩家检查点、更新 Workspace 中的路牌或保存路线数据。实际游戏中的这些操作需要额外逻辑与独立验证，不能从一段字符串输出推断已经完成。

外层 local 可以在内层读取 #

第一个示例在 do 代码块之前声明 routeName。块内的 print 能读取这个外层变量，因为内层代码可以访问所在外层作用域中已经声明的名称。块内还声明了新的局部变量 branchName。它们是两个变量，放到同一次 print 中并不会用分支名称覆盖总名称。代码块结束以后，最后一次打印仍然读取 Harbor。

运行前先写出预测：第一行同时出现 Harbor 和 Tower，第二行只有 Harbor。第一条 print 的两个参数之间会有制表符。注意 branchName 这个局部变量在自己的代码块外不可用。如果后续逻辑需要块内算出的结果，应明确设计返回值，或事先在外层声明合适的接收变量。直接去掉 local 并不是清晰的数据传递方案。

打开大图 ↗

local routeName = "Harbor"
do
    local branchName = "Tower"
    print(routeName, branchName)
end
print(routeName)

外层不能自动读取内层局部变量 #

可见性可以从外层延伸到嵌套内层，却不会自动反向扩展。在纸上给 do 块画一个框，branchName 就属于框内。框后的语句不能访问同一个局部声明。如果在别处再声明一个同名的 branchName，得到的是另一个变量，并不是找回原来的变量。名称相同不等于变量身份相同，这也是排查问题时的重要区别。

遇到意外的 nil 时，先检查声明的位置，不要立即全局替换名字。在普通独立示例中，没有绑定到可见声明的标识符可能读取一个不存在的全局值，从而得到 nil。这不会让已离开范围的内部 local 重新可见。Studio 的代码分析也可能提示未知名称。应把它当作代码边界问题处理，而不是据此声称已保存的数据被删除。

同名声明和赋值是两件事 #

第二个示例在子代码块内写了 local routeName。这个新声明遮蔽外层 routeName：在内层，相同拼写指向另一个值为 Tower 的变量。代码块结束后，外层变量重新可见，里面仍然是 Harbor。遮蔽可以是有意设计，也可能是初学者本想更新外层值时误加了 local。判断时要寻找声明，不能只看名字。

紧接着的代码块写 routeName = "Market"，没有新 local 声明。这一行能看见的是外层局部 routeName，因此赋值改变了外层变量。最后输出 Market。完整比较三行：Tower、Harbor、Market。关键差别来自声明，不是引号或 do 本身。若两个值代表不同概念，使用不同且清楚的名称通常更容易阅读和维护。

打开大图 ↗

local routeName = "Harbor"
do
    local routeName = "Tower"
    print(routeName)
end
print(routeName)
do
    routeName = "Market"
end
print(routeName)

声明出现的位置也很重要 #

局部变量在相应作用域中声明之后才可用。不要认为下面的一条 local 能解释所有更早出现的同名标识符。应从代码块顶部向下阅读，在每次使用处找到当时可见的声明。这个方法特别适合有多个短代码块的函数：同样的名称反复出现时，逐行跟踪比凭记忆猜测更可靠。

可以给每条 print 做注释，写明它应该读取哪个变量。第一次执行保持示例原样，之后只做一个受控修改。若同时移动声明、重新命名和修改字符串，新的输出就难以归因。把预测与实际输出分开记录；发生差异时回到声明和边界检查，而不是把碰巧正确的输出当作理解已经完整的证明。

函数还有自己的边界 #

函数参数和函数内部的局部变量属于函数自己的作用域。调用方不会因为调用了一次函数就获得这些局部名称。如果调用方需要计算后的标签，让函数返回标签，再在调用处赋给名称明确的局部变量。嵌套函数可以使用可见的外层 local，因此把函数移动到其他位置可能改变它能访问的变量，需要重新检查。

要区分可见性与结果传递。一个打印名称的函数只是产生了输出，并不一定向调用方返回了值。即使函数返回字符串，也不会自动更新 Roblox 界面。分别检查每个边界：输入从哪里来、哪些变量可见、通过 return 返回什么，以及哪一段调用方代码负责把结果应用到界面或其他对象。这些步骤不能互相替代。

全局变量不是所有脚本的共享数据 #

向没有可见 local 的名称赋值，可能创建或修改当前执行环境中的全局变量。这扩大了当前环境内的访问范围，也使意外的同名冲突更难追踪。但它不能建立 Roblox 独立脚本、各客户端与服务器之间可靠的共享变量。作用域本身不提供网络同步，也不负责跨会话保存玩家进度。

养成明确使用 local 的习惯。若多个脚本需要同一份定义，应研究有明确接口的模块；若客户端与服务器需要交换信息，应研究合适的通信机制和数据验证。这些是本练习之外的任务。把不可访问的局部变量改成全局名称，不能证明多人同步、权限判断或玩家存档问题已经解决，仍要分别测试真正的机制。

留下可以复核的交接记录 #

有用的交接材料包含未改动的示例、预期输出与真实运行结果。标明内层声明创建了新变量，后面的赋值更新了可见的外层变量。再加入负向检查：只在子块中声明的名称在块外不可访问。我们的独立断言检查了这些边界，没有修改任何现有 Roblox 游戏，也没有假装完成 Studio 的联机测试。

采用到实际脚本前，找到具体变量与所有使用它的代码块，说明变化应该只在局部暂时有效、更新外层状态，还是通过函数返回值传出。在独立开发副本中进行相应测试，并记录看到的结果。字符串例子通过，只能证明例子的局部行为；不能因此证明整款游戏的路线系统、界面更新和保存逻辑都正确。