企业官网建设流程全解析

很多人第一次接触Lua，都是从“这语法真简单”开始的。变量不用声明类型，循环也没有那么多花哨的写法，看起来确实比C++和Java轻量太多。但真到了写业务逻辑、调bug的时候，才会发现这门“简单”的语言里藏着不少细节——尤其是变量作用域和循环控制这两块，踩坑的频率远比你想象的高。

这篇就专门聊Lua的变量和循环。我的定位很明确：不堆砌语法手册，而是从实际写脚本的角度，把这两块的核心逻辑、使用习惯和容易翻车的地方一次讲透。不管你是刚转来做游戏脚本、嵌入式配置逻辑，还是想用Lua写一些自动化工具，这篇都值得花几分钟静下心看完。

1. 变量：先搞懂全局和local，再谈其他

1.1 为什么Lua默认变量是全局的，以及这个设计带来的隐患

Lua的一个特点（或者说坑点）是：默认情况下，你直接写一个变量名，它就是全局变量。哪怕你是在函数体内部写count = 10，这个count也会被挂到全局环境里。

这在写小段脚本时确实方便，打开解释器，敲几行代码直接跑，不用考虑作用域。但一旦脚本规模变大，或者你写的模块需要在宿主程序里被反复加载，全局变量的隐患就非常明显了。

我举一个实际场景。你在一个游戏项目里写新手引导逻辑，里面用了一个临时变量flag = false，本意是标记引导是否完成。结果另一个模块里，别人也写了一个flag = true，而且加载顺序刚好在你前面，你的逻辑就会被莫名其妙地“跳过去”。这种问题在多人协作的项目里几乎无法排查，因为编译期不报错，运行期也看不出什么异常，只能靠打印日志一点点追。

所以在我自己写Lua的这些年里，有一条几乎刻进骨子里的习惯：凡是能加local的地方，一律加local。这不是教条，而是用血泪换来的教训。

local这个关键字会把变量的作用域限制在当前代码块（chunk）内。这个“代码块”可以是一个文件、一个函数体、一个do...end块，甚至是一个循环体内部。用local声明变量，意味着这个变量只在你限定的区域内存在，不会泄露到全局环境，也不会被其他脚本意外覆盖。

还有一个很实际的性能理由：Lua访问局部变量比访问全局变量快得多。因为Lua虚拟机的指令中，局部变量是通过索引访问的，而全局变量要通过哈希表查找。虽然单次访问的差异在纳秒级，但当你在一个循环里频繁读写某个变量时，累积的差异就很可观了。在性能敏感的热点逻辑里，全局变量的开销会被放大很多倍，而局部变量带来的性能提升，用Profiler测一下就能看到明显差距。

1.2 变量命名、nil的哲学和type函数

Lua的变量命名规则和其他语言差不多：字母、数字、下划线，且不能以数字开头。不过有一个隐藏的坑：下划线开头的变量名通常被用于特殊用途，比如_G（全局环境表）、_VERSION（Lua版本号）。你自己写代码时，尽量避免用一个下划线开头的变量名，否则容易和工作机制里的东西混淆，也容易让人误读。

另一个Lua里非常重要的概念是nil。nil在Lua里代表“没有任何值”，一个变量如果没有被赋值，那它的值就是nil。这和Java的null、Python的None有点类似，但Lua对nil的使用更激进一些：给一个变量赋nil等同于删除这个变量。

这个特性在操作表（table）时特别有用。比如你有一个config表，想删除它的某个字段，直接config.timeout = nil就可以了。不用像其他语言那样调用remove方法，也不用担心内存泄漏，因为表里已经没有这个键了。

这里我要强调一个常见的误解：很多人以为== nil可以判断一个变量是否“存在”。严格来说，由于nil就是“不存在”这个语义，所以if x == nil then实际上就是在问“x是否不存在”。这在逻辑上是自洽的，但在实际编码中，有时候你可能想区分“变量存在但值为假”和“变量根本不存在”这两种情况——虽然Lua的nil把这两种合二为一了，但写代码时心里要有这根弦。

再说type函数。type(x)会返回一个描述类型的字符串，比如"number"、"string"、"boolean"、"table"、"function"、"nil"。

type函数的典型用途是在运行时检查参数类型。比如你写了一个通用工具函数：

local function logValue(value) local valueType = type(value) if valueType == "table" then -- 需要特别处理表类型，不能直接拼接 print("table with keys: " .. table.concat(getKeys(value), ", ")) else print("value is " .. valueType .. ": " .. tostring(value)) end end

注意这里用到了..字符串拼接操作符，这是Lua里最常用的字符串拼接方式。但有个性能细节：大量使用..拼接字符串时，每次拼接都会创建新的字符串，在循环里频繁拼接会带来不必要的内存开销。更高效的做法是收集到table再一次性concat。

2. 数据类型与变量的底层逻辑

2.1 动态类型的便利与代价

Lua是动态类型语言，变量本身不携带类型信息。同样的变量，前一秒还是数字，下一秒可以变成字符串。

你可以这样操作：

local x = 10 x = "hello" x = { name = "Lua" }

这在C++里是不可想象的。C++的int x = 10;之后，这个x就永远是int类型。动态类型的好处是写代码非常灵活，尤其在脚本场景下，你不需要为一个字段值的类型变化去做繁琐的转换。

但代价也很直接：类型错误只能到运行时才会暴露。你写local sum = a + b，如果某个地方把a传成了字符串，程序不会在编译期提醒你，只会在运行时得到奇怪的错误提示，比如“attempt to perform arithmetic on a string value”。这种错误在动态语言里是家常便饭，解决办法通常是靠程序员自己保持严谨：写函数时多考虑边界情况，必要时用type去校验参数。

我个人的习惯是：在对外提供接口的函数里，加一层参数类型校验。虽然会多几行代码，但能省下大量排查时间。尤其是那些可能被不同团队同时调用的公共函数，参数类型混乱几乎是必然发生的，提前校验能帮你把错误挡在源头。

2.2 table是变量的最终归宿

要说Lua里最重要的数据结构，非table莫属。它可以当数组用、当字典用、当对象用，甚至可以模拟类。

看一个最基础的例子：

local player = { name = "A同学", level = 10, items = { "sword", "shield" } }

这里player是一个table，包含三个字段。访问字段有两种写法：点号player.name和方括号player["name"]。两者在访问普通字段时是等价的。

但你如果要用变量作为键名来访问，就必须用方括号：

local key = "level" print(player[key]) -- 输出 10

day to day写多了之后，我越来越喜欢用方括号访问，因为它的语义更接近“动态索引”，而点号更像是写死的属性。如果你的代码里需要遍历一个table的键，那也一定要用方括号，因为遍历时你拿到的是键名，而不是字段本身。

table和变量的关系，本质上就是“变量指向table”。当你写local b = a时（a是个table），b和a指向同一个table，修改b的字段，a也会变。这就是引用语义。这个特性和变量的传值行为形成了鲜明对比：number、string、boolean这些类型的变量，赋值时是拷贝值，而不是引用。

这个区别很容易被新手忽略。举个例子：

local a = 10 local b = a b = 20 print(a) -- 输出 10，a没变 local t1 = { score = 10 } local t2 = t1 t2.score = 20 print(t1.score) -- 输出 20，t1变了

理解了这一点，你才能准确预判代码的行为。尤其是当你把table作为函数参数传进去时，在函数内部对table做的修改，会直接影响外部变量——这既是Lua的方便之处，也容易引发“函数副作用”问题。

2.3 多值赋值和交换变量的经典操作

Lua支持一条语句里给多个变量赋值，这其实是从函数返回多值的结果演变来的语法糖。

local a, b, c = 1, 2, 3 local name, age = getNameAndAge()

在Lua里，有两个值的函数调用可以直接用多值赋值接收，这个在其他语言里通常要借助结构体或类才能实现，Lua用逗号分隔就搞定了。

最有名的技巧是交换两个变量的值，不需要中间变量：

local x, y = 1, 2 x, y = y, x print(x, y) -- 输出 2 1

看到这个写法，其他语言背景的同事通常会愣一下。Lua的赋值是同时进行的，所以x, y = y, x实际上是“先计算右边的所有值，再依次赋给左边”，根本不会出现中间状态。如果写成x = y; y = x，结果就完全不同了，变成两个变量都等于原来的y。

还有一个小细节：赋值时，右边的值如果多于左边的变量，多余部分会被丢弃；如果少于左边，空缺的变量会被赋为nil。这在解析定长配置时很有用，但有时也会导致“变量意外变成nil”的问题，需要你自己留意。

3. 循环语法详解：while、for和repeat-until

3.1 while循环：最基础的条件循环

Lua的while循环和其他语言没有太大区别：

local count = 0 while count < 10 do count = count + 1 print(count) end

while会先判断条件，条件为true才执行循环体。所以如果一开始条件就不满足，循环体一次都不会执行。这个“先判断后执行”的顺序，在很多场景下是合理的。

但也正因如此，如果你需要在循环体里修改某个值才能跳出循环，一定要保证这个值在循环之前是“能进入循环”的状态。初学者常常犯的错误是：定义了count = 10，然后期望while循环输出从1到10——显然，count一开始就大于等于10，循环体直接跳过，什么都输出不了。

我在实际开发中，while用得相对少，更多的是用它来处理“不固定次数”的循环，比如从链表中取满足条件的节点，或者处理动态增长的任务队列。这类循环的终止条件通常不是一个固定数字，而是某个业务状态发生变化。

3.2 数值for循环：步长、边界和隐藏的陷阱

Lua的数值for循环语法是这样的：

for i = 1, 10 do print(i) end

这会输出1到10。还有一个可选的步长参数，默认是1：

for i = 10, 1, -1 do print(i) end

这个会从10倒着输出到1，步长是-1。注意，如果不写第三个参数（步长），默认步长为1，这时候如果你写了for i = 10, 1 do，循环一次都不会执行，因为步长和你想要的遍历方向不匹配。这个问题非常隐蔽，我见过不止一个同事在这里卡了半小时。

数值for的另一个特点是，循环变量i是局部变量，只在循环体内有效。循环结束后，i就访问不到了（会得到nil）。你不需要手动清理它，这是Lua帮你管理好的。

还有一个值得注意的点：数值for在循环开始时会先计算起始值、结束值和步长，并且这三个值会被缓存。所以即使你在循环体内修改了结束值变量，循环的边界也不会变化。比如：

local limit = 10 for i = 1, limit do if i == 5 then limit = 1 -- 这个修改不会影响循环次数 end end

这个循环依然会从1运行到10。了解这个特性，你就不会写出“想通过修改limit来提前结束循环”的代码了。如果确实需要提前退出循环，应该用break，这个后面会讲到。

3.3 泛型for：遍历table的正确姿势

泛型for是Lua最强大的循环形式，它的本质是“迭代器”。常见的用法是：

local items = { "sword", "shield", "potion" } for index, value in ipairs(items) do print(index, value) end

ipairs是一个迭代器，它从1开始，依次返回table中连续的整数键所对应的值，直到遇到nil为止。所以如果你的table不是连续的数组（比如中间缺了一个键），ipairs可能提前结束遍历，结果不完整。

另一个常用迭代器是pairs，它会遍历table中所有的键值对，但遍历顺序是随机的。别指望用pairs遍历出来的顺序和你定义的时候一样，它不做任何排序保证。

这里有一个永久经典的坑：游戏开发中，你定义了这样一个表存储排行榜数据：

local rank = { "first", "second", "third" } for k, v in ipairs(rank) do print(k, v) end

输出是1 first、2 second、3 third，一切正常。但如果这不是一个连续的数组：

local data = { id = 101, name = "A同学", level = 99 } for k, v in ipairs(data) do print(k, v) -- 什么都输出不了 end

因为data没有整数键（1、2、3），ipairs从1开始找，第一个键就是nil，于是直接退出。这时候必须用pairs才能遍历出来。

类似的还有next函数，其实pairs底层就是用next实现的。但绝大多数情况下，我们直接使用pairs就够了。有一点要注意：pairs遍历时，如果你在循环体内往table里新增键，新键有可能被遍历到，也可能不被遍历到，行为不确定，所以不要在遍历过程中修改table的结构，这是写任何语言都应该遵循的纪律。

3.4 repeat-until：最少执行一次的循环

repeat-until在Lua里的写法比较特别：

local i = 1 repeat print(i) i = i + 1 until i > 5

它会先执行一次循环体，再判断条件。所以不管条件是否满足，至少会执行一次。这在写“必须执行一次初始化再判断”的场景时特别方便，比如给玩家发放首登奖励时，至少要先发一次再检查是否重复。

while循环和repeat-until的主要差别就在“先判断”还是“先执行”。如果你需要“先做一次，再判断要不要继续”，用repeat-until可以让逻辑更自然，也更符合人的思维顺序。

注意一点：until后面跟的条件是“退出循环的条件”，不是“继续循环的条件”。这和while刚好相反。写while时你会想“条件为true，继续循环”，写repeat-until时要反过来想“条件为true，循环结束”。

很多新手第一次写repeat-until时会把条件写反，结果要么死循环，要么只执行一次就退出。我的建议是：在写repeat-until时，把condition放在脑内翻译成“满足这个条件就不要再跑了”，这样就能避免失手。

4. 循环控制与性能优化：break、局部变量与迭代器选择

4.1 break的使用边界和跳出困境

Lua的循环控制里，只有break，没有continue。这是很多从Python传过来的朋友最先吐槽的地方——习惯了continue跳过本次循环，到了Lua发现没有，只能靠条件判断来绕。

举个例子：

for i = 1, 10 do if i % 2 == 0 then -- 偶数跳过，相当于continue else print(i) end end

用if...else包住整个循环体，把需要跳过的逻辑放在if里，需要执行的放在else里。写起来确实不如continue优雅，但逻辑是清晰的。

还有一个更常见的需求：跳出双层循环。Lua的break只能跳出当前那层循环，如果你想一次性跳出两层，普遍的方案是用一个标志变量：

local found = false for i = 1, 5 do if found then break end for j = 1, 5 do if j == 3 then found = true break end end end

这已经算是最朴素的解法了。如果你喜欢更函数式的风格，可以把双层循环封装成一个函数，然后用return直接返回：

local function findTarget() for i = 1, 5 do for j = 1, 5 do if j == 3 then return i, j end end end return nil end

这个方案我用的最多，因为return本身就是提前退出的天然方式，而且函数封装也让代码更可读，还顺便把内部逻辑的细节给隐藏起来了。

4.2 循环里的局部变量和性能细节

在循环体内，如果你反复访问一个全局变量，性能上的损耗会比访问局部变量明显。我建议在循环外先把它缓存为局部变量：

local config = _G.config for i = 1, 10000 do if config.needProcess then -- 逻辑 end end

这里_G.config先被存到局部变量config里，循环内访问就快很多。实际上，Lua官方也建议尽量减少全局变量的查找，特别是在性能敏感的路径上。

另一个性能细节是table的读写。Lua的table访问虽然比全局变量快一些，但依然不是廉价的。如果你的循环里需要对同一个table的同一个字段反复读取，同样可以先取到局部变量：

for i = 1, 100000 do local score = playerInfo.score -- 使用 score 做计算 end

不过在优化时注意不要矫枉过正。我见过有人为了省几次table访问，写出了一大堆冗余的局部变量复制，代码变得非常难读。循环体内部的逻辑简单时，编译器自己也能做优化。先把逻辑写清晰，再用Profiler测量，找出真正的热点再做局部优化，这比盲猜性能瓶颈靠谱得多。

4.3 ipairs和pairs的选择困境

ipairs特指“数组部分”的遍历，只遍历从1开始的连续整数键。它的遍历顺序是确定的，从1开始递增，直到遇到nil。如果数组中间有空洞，ipairs会在空洞处停止。

pairs遍历的是table中所有的键值对，没有顺序保证，也不会停。它的实现基于next函数，所以能访问table中的所有元素。

那什么时候用pair？什么时候用ipairs？我常遇到的实际场景是：

• 要遍历一个数组（类似列表、队列），顺序很重要，就用ipairs。
• 要遍历一个字典（类似映射、配置），顺序无所谓，键值配对比较重要，就用pairs。

这里有一个容易搞混的点：当你用ipairs遍历一个纯数组时，它确实能按顺序工作。但如果数组中有一个值为nil（比如你把某个元素删了），ipairs就会立刻停止，就算后面还有更多元素也遍历不到了。

举一个我踩过的真实场景。游戏中有个库存列表，玩家卖掉了某个道具，代码把对应的槽位设为了nil。然后遍历库存时用ipairs，结果后面的道具全都不显示了。排查半天才发现问题出在nil身上。后来我改成用#list的长度来遍历，才彻底解决。

for i = 1, #list do local item = list[i] if item then -- 处理道具 end end

#list运算符返回数组部分的长度，即使中间有nil，它依然能给出一个长度值（具体长度取决于实现，可能不是nil之前的那个值，但常规情况下是安全的）。然后你自己加一个if item then做nil判空，逻辑就稳了。

当然，如果你要遍历的部分确实是纯数组，ipairs仍然是最简洁的选择。关键是你要清楚自己的数据结构是“数组风格”还是“字典风格”，再选择对应的遍历方式。

4.4 闭包陷阱：循环变量和匿名函数

这是Lua新手最容易掉进去的一个深坑：在循环体内创建匿名函数（闭包），然后让这个函数引用循环变量。

看这段代码：

local callbacks = {} for i = 1, 3 do callbacks[i] = function() print(i) end end callbacks[1]() -- 输出多少？ callbacks[2]() -- 输出多少？

直觉上，你可能会认为callbacks[1]()输出1，callbacks[2]()输出2。但实际运行结果可能会让你大跌眼镜——取决于你使用的Lua版本，输出可能是4、4、4。

原因是循环变量i在Lua的for循环中，虽然在每次迭代时看起来是“新的局部变量”，但在某些实现中，闭包捕获的是同一个变量引用，而不是捕获它在某一时刻的值。循环结束后，i变成了退出循环时的值（在这里是4），所有闭包引用的都是这个同一个i，所以打印出来的都是4。

要解决这个问题，常见做法是在循环体内再创建一个局部变量来“复制”当前迭代的值：

local callbacks = {} for i = 1, 3 do local current = i -- 在当前迭代内复制i callbacks[i] = function() print(current) end end

因为current是每次迭代时新建的局部变量，所以每个闭包捕获到的是不同的current，输出就变成1、2、3了。

这个坑在多语言的闭包场景里都存在，但Lua因为变量赋值太灵活，特别容易写出来而不自知。等你发现回调函数输出的值不是预期值时，已经过了很久了。所以我在写闭包相关逻辑时，会条件反射地去问自己：这个函数真正依赖的是哪个变量？它在循环结束后还活着吗？它的值变了吗？想清楚这几点，闭包就再也不会有奇异行为了。

5. 实战演练：处理带条件的玩家数据

我从一个实际的项目场景出发，演示一个组合了变量和循环的典型案例。

假设你有一个游戏配置表，里面记录了多个道具的ID、名称、价格，以及是否强制打折。你要写一段逻辑，找出所有打折的道具，累加它们的价格，并且输出一段友好的提示文本。

local config = { { id = 1, name = "sword", price = 100, discount = false }, { id = 2, name = "shield", price = 80, discount = true }, { id = 3, name = "potion", price = 50, discount = false }, { id = 4, name = "helmet", price = 120, discount = true } } local totalPrice = 0 local discountedItems = {} for _, item in ipairs(config) do if item.discount then discountedItems[#discountedItems + 1] = item.name totalPrice = totalPrice + item.price end end local message = "Discounted items: " message = message .. table.concat(discountedItems, ", ") message = message .. ". Total cost: " .. totalPrice print(message)

这段代码里有几个值得留意的设计选择：

第一，我用for _, item in ipairs(config)而不是for i, item in ipairs(config)，是因为我不需要索引值，直接用_占位忽略它。这是Lua社区非常普遍的习惯写法。_只代表“这个值我不要”，不过它也是一个真实的变量名，所以不能复用得太随意。

第二，我用discountedItems[#discountedItems + 1] = item.name来动态添加元素。#discountedItems是当前数组长度，加1就是新元素的索引。这是Lua里手动追加数组元素的经典写法，比任何语言里的push方法都要直白。

第三，我用table.concat把数组拼接成字符串，而不是用一个循环里反复..拼接。这两种方式性能差异很大，在元素多时concat优势明显。当然，在只有几个元素的小场景下，用循环怎么拼都行。

这个例子的意义在于，它把前面讲的变量作用域、table引用、ipairs遍历、局部变量缓存等知识点，全部串在了一段直观的日常逻辑里。你看完如果觉得“这不就是天经地义的吗”，说明前面那些坑你确实都懂了；如果觉得有些地方写法怪怪的，那正好可以回头再翻一下对应的小节。

6. 常见问题与排查技巧实录

6.1 “attempt to perform arithmetic on a nil value”到底是谁的错

这个报错基本是Lua新手遇到的第一个拦路虎。它的意思是，你在做算术运算时，某个操作数的值是nil，比如local sum = a + b，而a或b没有初始化。

问题可能出在两个地方：一是变量的名字拼错了，比如你定义的是playerLevel，写成了playerlevel；二是变量定义在另一个作用域，当前作用域根本访问不到。判断到底是哪种情况，我一般先加一个打印：

print("a =", a, "b =", b) local sum = a + b

如果打印出a = nil，说明变量名或作用域有问题。如果打印出的值是nil但变量明明赋值了，那十有八九是作用域泄漏了，比如你在if块里定义的局部变量，出了if块就被销毁了。这种时候把变量提到更高的作用域，或者重新设计函数返回，基本就能解决。

6.2 循环次数比预期多了或少了

我遇到最多的是这类问题：

第一种，循环多了一次。比如遍历玩家背包时，用for i = 1, #bag do，结果最后一位是nil，处理时出现了预料之外的逻辑。解决办法还是用ipairs或者在循环体内判空。

第二种，循环少了一次。比如要从10数到1，却写了for i = 10, 1 do。这就是3.2节讲的步长陷阱，默认步长是1，i只会越来越大，永远不会小于1。写倒序遍历时一定要记得带上-1步长参数。

第三种，循环根本没执行。这种情况通常是条件判断写反了，最常见的是把while的条件写成了while count > limit do，但实际应该是小于。这种逻辑错误靠肉眼检查很难捉住，最有效的办法是用打印把循环外的变量值打出来，看一眼条件到底为不为真。

6.3 死循环的快速定位方法

死循环在Lua里非常常见，通常是因为循环体内的退出条件永远无法满足。比如：

local i = 1 while i > 0 do print(i) i = i + 1 end

这个循环永远不会结束，因为i一直是正数并且越来越大。如果你在线上环境遇到这种情况，程序就会卡死，CPU拉满。

排查死循环，我的做法是三步：

第一步，看退出条件。把条件拿出来，代入几个边界值，算一下是否有满足条件的时候。

第二步，看循环体内有哪些变量影响条件。比如上面的i，它在循环体内必须被修改才可能退出。如果循环体内没有修改循环控制变量，那几乎必然是死循环。

第三步，在条件判断前加打印，输出控制变量的当前值。如果你不想看一堆日志刷屏，可以在打印里加个计数器，只打印前20次：

local debugCount = 0 while i > 0 do debugCount = debugCount + 1 if debugCount <= 20 then print("i =", i) end i = i + 1 end

这样你就能快速判断出i到底有没有在变，变的方向对不对。

6.4 热更新场景下的变量污染问题

现在很多游戏项目会用热更新机制，Lua脚本可以在线替换。这个场景里，变量作用域的问题会被放大到极致。

举个例子，你有一个模块文件，顶部定义了一个全局变量用来记录状态：

state = "idle"

如果这个文件被热更新覆盖，state的旧值不会自动清理，新代码加载后可能读到上一个版本的残留值。这会造成非常难追查的状态错乱。

正确的做法当然是尽量不要使用全局变量来存状态，而是把状态封装在一个模块局部变量中。这是使用Lua模块时需要认真设计的一点。你的模块应该返回一张表，表里只暴露需要对外使用的函数，内部状态一律用local变量藏起来，这样热更新时旧值会被新加载的local重新初始化，完全不存在环境污染。

写在最后

Lua的变量和循环，乍一看是入门级的内容，但真正写起来，坑都藏在细节里。全局变量污染、闭包捕获循环变量、ipairs遇nil提前停止、步长方向错误——这些不会让你的程序编译失败，但会在运行时给你找麻烦。

我带过的每一个初学者，几乎都会在某个深夜被这些问题折磨一遍。这也印证了一件事：越是看起来简单的语言，越需要你真正理解它的“脑回路”。Lua的设计哲学是尽量少给程序员设限制，把灵活性和自由度交给你，但也正因为如此，它对你的自律要求就更高。

我个人的经验就是：变量一律用local；循环遍历之前先想清楚你的数据结构是数组还是字典；闭包引用循环变量时，务必多复制一层；凡是涉及循环退出，先用笔在纸上算一遍条件，别急着跑。

把这几条刻进肌肉记忆之后，你再回来看Lua的语法，会觉得它确实简单，但绝不简陋。它给你的自由很大，而真正的专业能力，恰恰体现在如何使用这份自由而不搬起石头砸自己的脚。