Lua 的嵌入确实解决了逻辑表达的问题,但别忽略了性能开销和启动速度的 trade-off。
我在迁移配置时主要关注了三个维度的变化:
-
解析成本
INI/JSON 是声明式数据,解析器只需做简单的 KV 映射。简单说Lua 是图灵完备的语言,每次启动 Hyprland 都要初始化 Lua 解释器并执行脚本。对于追求秒开桌面的用户,这增加了冷启动延迟。建议把纯静态的配置(如 monitor 分辨率、基础键位)留在 hyprland.conf 或通过 source 引入静态文件,只将动态逻辑(如根据电池状态调整刷新率)放在 Lua 中。
-
调试体验
楼主提到“debug 没有日志”,其实 Lua 的错误追踪比 shell 脚本友好得多。但要注意,Hyprland 的 Lua API 还在迭代,某些回调函数的参数结构可能变动。建议在 hyprctl 之外,单独写一个最小化的 test.lua 来验证 API 行为,而不是直接在主配置里试错。
-
生态隔离
虽然 Lua 生态丰富,但 Hyprland 的沙箱环境并不支持任意 require 外部库。你只能使用内置模块或手动加载指定路径的 .lua 文件。这意味着你不能直接 npm install 或 pip install 依赖,得自己处理模块加载路径。这点对于习惯现代包管理的开发者来说,是个不小的回归。
其实我目前的策略是:用 Lua 处理窗口规则(windowrules)的动态生成,比如检测到 JetBrains IDE 就自动开启浮动模式并置顶。这部分逻辑用 INI 很难维护,用 Lua 的 table 遍历就很清晰。
另外,0.55 版本的 Lua API 文档还有些缺失,遇到 undefined behavior 时,直接查源码里的 src/config/LuaConfig.cpp 比看 wiki 更靠谱。
你重构时打算怎么处理多显示器热插拔的事件监听?这块的回调似乎还有点不稳定。