8.4 嵌入式 OpenWRT 与生态地图

8.4 嵌入式 OpenWRT 与生态地图

本节摘要：路由器是 Lua 住过的最小的家：几十兆内存要装下内核、网络栈，再挤一个 Web 配置界面——OpenWRT 的 LuCI 框架选择了 Lua，理由是体积、启动与胶水能力三合一。本节看 LuCI 的 MVC 形状、UCI 配置模型与脚本的绑定，讨论设备端脚本的资源纪律，最后画出寄宿生态地图，把四大家之外的 Neovim、Wireshark 等住户一网收进。

几兆内存的住户

家用路由器的典型配置是几十到几百兆内存、主频几百 MHz 的 MIPS 或 ARM 芯片，flash 存储以 MB 计。在这上面要跑：Linux 内核、网络栈、无线驱动，还要给用户提供一个 Web 配置界面——改 Wi-Fi 密码、看已接设备、设端口转发。技术选型时摆在桌上的选项：

• C 写 CGI：内存 footprint 最小，但每个页面改一次编译一次，配置界面的快速迭代无法忍受；
• 嵌完整 Python/PHP：解释器加运行库动辄几十兆，flash 和内存都装不下；
• Lua：解释器加标准库几百 KB，语法层就能操作配置数据，模板与胶水顺手。

OpenWRT 选择了 Lua，并围绕它搭了 LuCI（Web 界面框架）。看一个 LuCI 页面的骨架（示意形式）：

-- 一个配置页：模型加视图的极简 MVC
local m, s, o

m = Map("network", translate("Interfaces"), translate("Network interface config"))

s = m:section(NamedSection, "lan", "interface", translate("LAN"))
s.addremove = false

o = s:option(Value, "ipaddr", translate("IPv4 address"))
o.datatype = "ipaddr"
o.rmempty = false

o = s:option(Flag, "auto", translate("Auto start"))
o.default = o.enabled

return m
​

声明式的页面描述：绑定的配置文件（network）、节（lan 接口）、两个字段（IP 地址校验、开机自启开关）。类与继承（第 5 章的 Map、section、option 层级）在这里是框架的骨架；表驱动的配置描述（第 3 章）让一个页面二十行搞定。这套界面在 32MB 内存的设备上流畅运行——Lua 的体积账单在这里最锋利。

UCI：配置即文件，文件即表

OpenWRT 把全部系统配置统一进 UCI（统一配置接口）：每个服务一份文本配置文件，格式固定。LuCI 的脚本层把 UCI 文件映射成表语义——读配置就是查表，写配置就是改表后提交：

local uci = require("luci.model.uci").cursor()

-- 读：无线网络的 SSID
local ssid = uci:get("wireless", "@wifi-iface[0]", "ssid")

-- 改：换信道并提交
uci:set("wireless", "@wifi-iface[0]", "channel", "6")
uci:commit("wireless")

-- 事务式批量：先改多处再一次提交
uci:foreach("network", "interface", function(sec)
    if sec.proto == "dhcp" then
        uci:set("network", sec[".name"], "proto", "static")
    end
end)
uci:commit("network")
​

配置文件、脚本、界面三方共享同一模型——这是"表是宿主与脚本的会客厅"在设备端的形态：LuCI 页面声明绑定 UCI 字段，用户在界面上的每次保存最终落到 uci:set 加 commit，脚本后台任务也走同一接口。没有私有的配置 API，没有第二套格式。

设备端脚本的资源纪律比其它现场更苛刻：内存小到每个页面渲染后要立刻释放、CPU 慢到全表遍历要省着用、flash 写寿命有限（commit 才真正落盘，减少无谓写入）。第 3、4 章的性能习惯（local 缓存、concat 拼接、避免无谓中间串）在这种硬件上是"能不能用"而不是"快不快"的区别。OpenWRT 后来的社区也在部分组件上引入了其它技术做对比实验，但 LuCI 数亿台设备的装机量证明了这套 Lua 方案在"够用、小巧、可维护"三角上的长期竞争力。

寄宿生态地图

四大家之外，Lua 的住户散布在工具链与行业软件的各个角落。把地图画全：

四块大陆的住户各有代表性。Neovim 值得单独说：它把 Lua 定为配置与插件的第一方语言（内嵌 LuaJIT），启动时执行配置脚本装配编辑器、插件以模块形式加载、热重载配置随手可得——一个"编辑器作为宿主"的完整样本，社区几年内从 Vimscript 大迁徙到 Lua，看中的正是本章反复出现的三个理由。Wireshark 用 Lua 写协议解析器：新协议的 dissect 函数挂进解析树，分析能力开放给第三方而不动 C 内核。Kong 建在 OpenResty 之上，API 网关的插件（鉴权、限流、转换）全是 Lua 模块——网关现场的第 N 层放大。

选型启示录

把四大家加群岛的经验压成一张决策表，供"要不要在自家产品里嵌 Lua"时对照：

最后一行是诚实的反面：嵌入本身有成本（绑定层维护、双语言调试、版本兼容），没有"变化频繁"或"开放定制"的刚需，脚本层就是纯负债。寄宿之道的另一面是知道自己什么时候不需要房客。

Neovim 样本细读：一个宿主的完整接口面

生态地图上值得展开看一格的是 Neovim——因为它的 API 面对普通开发者完全公开，是研究"宿主如何布置房间"的最好标本。它的接口分四层，每层都能对应到本册某章的机制：

配置层：启动时执行用户的 init 脚本（一个 Lua 块，6.1 节的"块"概念），用户在块里 require 自己的插件模块、设置选项。命名空间层：宿主注入 vim 全局表——选项读写（vim.o 与 vim.opt）、缓冲区与窗口的对象 API（userdata 挂方法表，5.1 节的寄宿本义）、异步任务（vim.loop，libuv 的 Lua 绑定）。事件层：编辑器事件（打开文件、光标移动）派发给注册的 Lua 回调，回调约定即时返回（协程让出或定时器分摊，7.2 节调度思路）。插件层：每个插件一张模块表 + 一份清单声明命令与事件挂钩——第 8.1 节 MOD 模型的编辑器版。

四层叠起来就是一个完整的"宿主接口设计教程"：配置给定制、命名空间给能力、事件给响应、插件给生态。任何想给自家产品做脚本化的人，抄这份结构都不会错——因为它是被几十万插件用户检验过的最小完备集。

设备端的三条硬纪律

把 OpenWRT 一节的工程经验提炼成可迁移的三条：

内存先于速度。设备上"能不能跑起来"由内存决定：启动时加载的模块总量、每会话的表与字符串驻留、临时垃圾的峰值——都要心里有数。工具是 collectgarbage("count")（6.3 节）定期采样，内存曲线平稳才算合格。

写入要节俭。flash 有写寿命，UCI 的"改内存、显式 commit 落盘"模型是通用范式：变更攒批、显式提交、失败可弃。日志同理——写文件的日志在设备上要限速与轮转，否则日志把 flash 写穿。

失败要降级。设备常年无人在场，脚本错误不能让配置界面瘫痪：每个页面渲染过 pcall 壳（6.2 节），失败时降级到"安全模式页面"（只读状态 + 基本操作），而不是白屏。降级路径本身要极简——用最少依赖渲染出来。

LuCI 的分发病形

LuCI 内部是"控制器加模型加视图"的三层，控制器负责把 URL 分派到处理函数——形状就是第 3 章的注册分发：

-- 控制器模块（示意形式）：路由表驱动
module("luci.controller.admin.status", package.seeall)

function index()
    entry({ "admin", "status", "overview" }, call("action_overview"),
           translate("Overview"), 1).dependent = false
    entry({ "admin", "status", "routes" }, cbi("admin_status/routes"),
           translate("Routing Table"), 2)
end

function action_overview()
    local sys = require("luci.sys")
    local info = {
        uptime = sys.uptime(),
        loadavg = sys.loadavg(),
        meminfo = { total = memtotal(), free = memfree() },
    }
    luci.template.render("admin_status/overview", info)
end
​

entry 登记路径段（admin/status/overview）、处理方式（call 直调或 cbi 走表单模型）、显示名、序号——路径树即路由表，序号决定菜单顺序（数组语义），模型层自动把 UCI 配置绑定到页面控件（8.4 节开头的 Map/section/option）。整个框架没有一个"特殊机制"：表存路由、函数做处理、UCI 做持久层、模板做输出——第 2 到 6 章的全部零件在几十 KB 的框架里各就各位。设备端框架的启示：小内存不是少做事，是每个零件都选最省的通用件。

生态地图的读法

地图不是荣誉墙，是选型坐标系。三个读法：

按约束读。你要解决的约束（帧预算、吞吐、原子性、内存）落在哪块大陆，就去那块找成熟方案——游戏找绑定层与热更方案、服务端找网关与脚本缓存模式、设备找省内存纪律、工具找 API 白名单设计。约束相似，方案可迁移。

按接口读。每家宿主暴露给脚本的接口面（表加回调）都是一次接口设计课：Redis 的极简两函数、OpenResty 的阶段全景、Neovim 的四层结构、LuCI 的三层 MVC——四个范本覆盖了"极简到全面"的光谱，给自家产品设计接口时按需取景。

按历史读。谁家在什么年代收留了 Lua、什么版本停更、社区迁去了哪里（5.1 的固化、LuaJIT 的分叉、方言的出现）——生态的时间线告诉你哪些承诺被守住了、哪些演化路径是死胡同。技术选型的情报一半在代码里，一半在这条时间线上。

本节要点回顾

• LuCI 的选型三合一：体积（几百 KB）、启动（无预热）、胶水（表直连配置模型）——设备端的胜负手；
• UCI 统一配置：界面、脚本、文件共享同一模型，读配置即查表、commit 才落盘——flash 寿命与一致性的折中；
• Neovim 四层接口（配置、命名空间、事件、插件）是宿主接口设计的检验过的最小完备集，可整体移植；
• 设备端三硬纪律：内存先于速度（count 采样）、写入节俭（攒批显式提交）、失败降级（安全模式页面）；
• 生态地图四块大陆：游戏、服务端、设备、工具——共同点是"宿主强、变化多、要快、内存紧"；
• 选型决策表：按四家经验对照自身处境；没有变更与定制刚需，不要为嵌而嵌。

四大家看完了。下一章从房客视角切换到房东视角：C API 的虚拟栈、双向集成，以及全册的收官——热更新。