编写正确且高效的应用，最为关键是一系列软件工程上的实践，像测试、code review、灰度、监控、压测等等。不过由于这是 OpenResty 大会上的演讲，我会专注于讲讲 OpenResty 和 LuaJIT 的一些小细节，帮助各位听众避免线上踩坑。

还有一笔账值得一算：调用 Lua CFunction 会迫使 LuaJIT 退回到解释模式，而通过 FFI 调用 C 函数则不会。所以不能光计算 FFI 的开销，还要看因为不用 FFI，导致 Lua 代码无法被编译掉的损耗。在代码中大量调用 Lua CFunction，会使得 LuaJIT 的 JIT tracing 变得支离破碎。即使因为 stitch 的缘故，让剩余的部分能够被...

对 C 语言良好的亲和力，一直是 Lua 的优势之一。LuaJIT 在传统的 Lua C API 之外，额外提供 FFI 的方式来调用 C 函数，更是大大提升了跟 C 交互的便利度。甚至有这么一种说法，虽然 LuaJIT 命名是 Lua + JIT，但是好多人是冲着 FFI 去用 LuaJIT 的。[1]

先看一则示例： {代码...} 拜 Lua 内部实现上的细节所赐，如果传递的数组中带有 nil 值空洞，# 操作符返回的数值并不能反映真实的大小。 直接引用 Lua 5.1 manual 上的说法（Lua 5.2 和 LuaJIT 也是一样的定义）： [链接] The Length Operator The length of a table t is defined to be any integer index n such that ...

今天同事在公司群里转发了一篇文章：Calling Go Functions from Other Languages 其原理是 通过编译时指定 -buildmode=c-shared 选项，把 Go 程序编译成 C 的动态链接库。 由其他语言通过 FFI 的形式，去调用动态链接库的函数。 于是，只要能支持 FFI 的语言，就能调用事先编译到动态链接库里 Go 的函数。 想到 LuaJIT ...

给带 GC 的语言写 C binding 一向是件让人迷糊的事。到底应该在 C 手工释放资源呢，还是依靠 GC 来回收？还好 LuaJIT FFI 提供了很好用的 ffi.gc 方法。该方法允许给 cdata 对象注册在 gc 时调用的回调，它能让你在 Lua 领域里完成 C 手工释放资源的事。

先重温下 Lua 里的真值与假值：除了 nil 和 false 为假，其他值都是真。“其他值”这个概念包括0、空字符串、空表，等等。在 Lua 里，通常使用 and 和 or 作为逻辑操作符。比如 true and false 返回 false，而 false or true 返回 true。