Sublime Text 不支持 Lua 断点调试，因其无内置调试器，无法单步执行或监视变量；只能通过 print 日志、错误定位及外部工具间接调试，Ctrl+B 仅为批处理式运行，不提供交互式调试会话。
Sublime Text 本身不支持 Lua 断点调试——它没有内置调试器，也不提供单步执行、变量监视或调用栈查看能力。所谓“调试循环和条件判断逻辑”，只能靠日志输出、错误定位、配合外部工具间接实现。
为什么 Ctrl+B 运行后看不到循环/条件的中间状态
因为 Ctrl+B 只是调用系统 lua 或 luajit 执行一次脚本，输出完就结束。循环体内的 print 能看到，但无法暂停、无法观察某次迭代时 i 和 condition 的实时值变化。
- 常见错误现象：改了
if条件却没进分支，或for循环只跑了一次就退出，但控制台只显示最终结果，看不出哪次迭代出问题 - 根本原因：Sublime 构建系统是“批处理式”运行，不是交互式调试会话
- 可行替代：在关键位置加
print，比如print(("i=%d, cond=%s"):format(i, tostring(condition)))，比盲猜快得多 - 注意编码：Windows 下中文路径 +
print容易触发乱码，建议统一用 ASCII 字符打桩，如print("DEBUG_LOOP", i, condition)
如何让错误点击直接跳转到 if/for 出错的那一行
这依赖 file_regex 是否匹配 Lua 实际报错格式。默认构建配置里如果写的是 "^(*?):([0-9]+):?([0-9]*):? (.*)$"，但你的 Lua 解释器实际报错是 test.lua:7: attempt to index a nil value (field 'data')，那正则就能捕获行号；但如果用的是 luajit，错误可能是 test.lua:7:12: attempt to index...，列号多了一段，原正则就会失效。
- 验证方法：故意写个错，比如
nil.foo()，看 Sublime 底部面板报错是否带列号；有列号就用"^(.*?):([0-9]+):([0-9]+):(.*)$"，否则用不带列号的版本 -
selector必须跟插件一致：装了LuaEnhanced就得写"selector": "source.lua.enhanced"，写成source.lua会导致构建系统压根不绑定，Ctrl+B没反应 - Windows 用户特别注意：
file_regex中的*在某些旧版 Sublime 里会被误解析，建议改成.*?或直接用(.*?)
想真正单步调试 if/for，该用什么工具
必须脱离 Sublime Text 本身，换用支持 Lua 调试协议（LLDB 或 lldb-mi）的环境。目前最轻量可行的是 ledb（Lua Embedded Debugger）配合 luajit，或者用 VS Code + lua-debug 插件（需额外配 launch.json 启动 luajit -e "require'debugger'.start()"）。
- Sublime 里装任何“Lua Debugger”插件都无效——它们只是 UI 壳，背后没调试器进程
- 如果坚持用 Sublime，唯一能做的就是把循环拆成可复现的小段，例如把
for i=1,100 do ... end改成for i=1,5 do ... end，再加print(i)观察边界行为 - 条件判断复杂时，把表达式单独提取为变量并打印：
local ok = a > 0 and b ~= nil and table.getn(c) > 2; print("DEBUG_COND", ok, a, b, #c)
真正卡住的地方往往不是语法，而是循环终止条件里的隐式类型转换（比如 tonumber(input) == nil 却忘了 input 是空字符串），或者 if 分支里修改了影响下一轮判断的变量——这些靠 print 能暴露，靠“想象执行流”几乎必错。
