debug.getinfo(1, "n").name 导致的奇怪行为

这是 Lua 的尾调用优化的结果，详见尾调用优化。

在这种情况下，Lua 将函数调用转换为“goto”语句，并且不需要使用任何额外的栈桢来执行尾调用。

您可以添加 traceback 语句来进行检查：

    function myFunc()
      local name = debug.getinfo(1, "n").name
      print(debug.traceback("Stack trace"))
      return name
    end

当您使用一个函数调用返回时，Lua 进行尾调用优化：

-- 优化的
function good1()
    return test()
end

-- 优化的
function good2()
    return test(foo(), bar(5 + baz()))
end

-- 未优化的
function bad1()
    return test() + 1
end

-- 未优化的
function bad2()
    return test()[2] + foo()
end

您可以参考以下链接了解更多信息： - 《Lua程序设计》- 6.3: 适当的尾调用 - 什么是尾调用优化？- Stack Overflow

你可以通过luac -l -p运行代码。

...

function <stdin:6,8> (4 instructions at 0x555f561592a0)
0 params, 2 slots, 1 upvalue, 0 locals, 1 constant, 0 functions
  1 [7] GETTABUP    0 0 -1  ; _ENV "myFunc"
  2 [7] TAILCALL    0 1 0
  3 [7] RETURN      0 0
  4 [8] RETURN      0 1

function <stdin:10,13> (4 instructions at 0x555f561593b0)
0 params, 2 slots, 1 upvalue, 1 local, 1 constant, 0 functions
  1 [11]    GETTABUP    0 0 -1  ; _ENV "myFunc"
  2 [11]    CALL        0 1 2
  3 [12]    RETURN      0 2
  4 [13]    RETURN      0 1

这些是我们感兴趣的两个函数：foo和boo。

如你所见，当boo调用myFunc时，它只是一次普通的CALL，没有什么有趣的地方。

然而，foo做了一些被称为尾调用的事情。也就是说，foo的返回值是myFunc的返回值。

使这种调用特殊的是，程序无需跳回foo；一旦foo调用myFunc，它可以直接交出钥匙并说“你知道该怎么做”；myFunc直接返回其结果到调用foo的地方。这有两个优点：

• 在调用myFunc之前，foo的堆栈帧可以被清除。
• myFunc返回后，它无需两个跳转返回到主线程；只需要一个

这些优点在您的示例中都不重要，但是一旦有大量的尾调用，它们变得重要。

这种方法的缺点是，一旦清除了foo的堆栈，Lua也会忘记与之关联的所有调试信息；它只记得作为尾调用调用了myFunc，但不知道是从哪里调用的。

一个有趣的副作用是，boo也几乎是尾调用。如果Lua没有多返回值，它将完全相同于foo，而像LuaJIT这样的更智能的编译器可能会将其编译为尾调用。 PUC Lua不会这样做，因为它需要一个文字return some_function()才能识别尾调用。

不同点在于，boo仅返回myFunc返回的第一个值，而在您的示例中，只会有一个，解释器无法做出这种假设（LuaJIT可能在JIT编译期间做出这种假设，但我不理解）。

还要注意的是，严格来说，术语“尾调用”只描述函数A直接返回另一个函数B的返回值。

它经常与“尾调用优化”交替使用，后者是编译器在重复使用堆栈帧并将函数调用转换为跳转时所做的操作。

严格地说，C（例如）有_尾调用_，但没有_尾调用优化_，这意味着以下代码

int recursive(n) { return recursive(n+1); }

是有效的C代码，但最终将导致堆栈溢出，而在Lua中

local function recursive(n) return recursive(n+1) end

仅仅会一直运行。两者都是尾调用，但只有后者被优化。

编辑：与C一样，一些编译器可能会自行实现尾调用优化，因此不要到处告诉每个人“C永远不会使用它”；它只是语言的一个不可或缺的部分，而在Lua中，它实际上被定义在语言规范中，因此Lua没有尾调用优化就不是Lua。

在Lua中，任何形式为return <表达式得到函数>(...)的返回语句都是尾调用。尾调用实际上并不存在于调用栈中，因此不会占用额外的空间或资源。你调用的函数实际上会从调试信息中被删除。

是否有可能修正myFunc()函数，使得同时调用foo()和boo()函数会返回相同的结果？

嗯……是的，但在我告诉你如何做之前，让我试着说服你_不要这样做_。

如前所述，尾调用是Lua语言的一部分。从堆栈中删除尾调用与使用break退出for循环一样，并不是一种“优化”。这是Lua语法的一部分，Lua程序员有权期望尾调用是一个尾调用，就像他们有权期望break退出循环一样。

Lua作为一种语言，明确表示这一点：

local function recursive(...)
  --一些终止条件

  return recursive(modified_args)
end

永远不会，_绝不会_耗尽堆栈空间。它和执行循环一样高效。这是Lua语言的一部分，与for和while的行为一样。

如果用户想通过尾调用调用你的函数，那_就是他们使用语言特性的权利_。拒绝用户使用语言特性的权利是_粗鲁的_。

所以不要那样做。

此外，你的代码表明你试图依赖函数名称。你正在使用名称做出某些重要且有意义的事情。

嗯，Lua_不是Python_；Lua函数根本不需要名称。因此，你不应编写依赖函数名的代码。对于调试或日志记录目的来说，可以。但是，你不能为了调试和记录而破坏用户期望。因此，如果用户进行了尾调用，请接受用户想要的，并且你的调试/日志记录会稍微受到影响。

好了，我们同意你不应这样做了吗？Lua用户有尾调用的权利，你没有拒绝它们的权利？Lua函数没有名称，你不应编写需要它们维护名称的代码？对吧？

以下是不应使用的**可怕的代码！**（在Lua 5.3中）：

function bypass_tail_call(Func)
    local function tail_call_bypass(...)
        local rets = table.pack(Func(...))
        return table.unpack(rets, rets.n)
    end
    return tail_call_bypass
end

然后，只需使用bypass的返回值替换真实函数：

function myFunc()
  local name = debug.getinfo(1, "n").name
  return name
end

myFunc = bypass_tail_call(myFunc)

请注意，bypass函数必须构建一个数组来保存返回值，然后解开它们并用于最终的返回语句。这显然需要进行不必要的内存分配，在常规代码中不会发生。

所以这还有另一个不应这样做的原因。