Sublime Text 不支持 Lua 断点调试——无内置调试器，不提供变量监视、单步执行或调用栈查看；所谓调试仅能依赖 print/io.stderr 输出、构建系统快速反馈及外部工具辅助。
Sublime Text 本身不支持 Lua 断点调试——它没有内置调试器，也不提供变量监视、单步执行或调用栈查看功能。所谓“调试复杂算法逻辑”，实际只能靠日志输出 + 构建系统快速反馈 + 外部工具辅助定位。
为什么不能像 VS Code 那样设断点
Sublime 的构建系统（Lua.sublime-build）本质只是调用终端执行 lua "$file" 或 luarocks exec lua "$file"，它不接管 Lua 运行时，也不注入调试协议（如 Debug Adapter Protocol）。所有“断点”类需求，最终都得退回到 print、io.stderr:write 或自定义钩子函数上。
-
require 'mobdebug'等远程调试库，在 Sublime 下无法触发 UI 交互，只适合搭配 ZeroBrane Studio 这类专用 IDE - 插件如
SublimeLinter-luacheck只检查语法/风格，不运行代码，对逻辑错误无能为力 - 哪怕装了
Lua Enhanced或AutoLua，也只影响编辑体验（高亮、补全），和运行时调试无关
怎么高效用 print 调试算法中间状态
手动加 print 容易漏删、干扰输出、格式混乱。建议用轻量封装替代裸写：
- 在脚本顶部统一加一个调试开关：
DEBUG = true，所有调试输出包在if DEBUG then ... end里 - 用
io.stderr:write而非print，避免和正常 stdout 混在一起（尤其算法含io.write时） - 打印结构体用
require('json').encode（需提前luarocks install json），比table.foreach更可靠 - 给关键步骤加唯一标签，比如
io.stderr:write("STEP-merge-sort-mid:", json.encode(mid_arr), "\n")，方便 grep 定位
构建系统怎么让调试输出更清晰
默认 Lua.sublime-build 的 "file_regex" 是为编译错误设计的，对 print 输出无效。要提升可读性，需调整两处：
- 把
"shell": true改成false（Windows 下尤其重要），否则io.stderr可能被缓冲，看不到实时输出 - 在
"cmd"中显式重定向 stderr：例如["lua", "$file", "2>&1"]（Linux/macOS）或["lua", "$file", "2>&1"]（Windows cmd，PowerShell 需用2>&1写法） - 如果算法耗时长，Sublime 构建面板会卡住——这不是 bug，是它不支持流式输出；此时应改用终端运行：
lua script.lua | head -20快速看前几条日志
遇到 require 失败或路径错乱怎么办
复杂算法常依赖自定义模块（如 ./lib/graph.lua），但 Sublime 构建系统不会自动设置 LUA_PATH。常见现象是 module 'lib.graph' not found：
- 别在
Lua.sublime-build里硬编码package.path—— 构建系统不执行 Lua 代码，只传命令行参数 - 临时方案：在脚本开头加
package.path = "./?.lua;./?/init.lua;" .. package.path - 长期方案：用
luarocks exec lua "$file"替代lua "$file"，它会自动加载 rocks 路径，也兼容本地./?.lua（前提是你的模块名和文件结构匹配） - Windows 下若用 LuaForWindows，确认
lua.exe和luarocks.bat在同一目录且都在 PATH 中；否则构建系统找不到命令
真正卡住的地方，往往不是语法或配置，而是误以为 Sublime 能做它做不到的事——比如停在某一行等你输入、查看闭包变量、跳进 C 函数内部。这些必须交给 lua-language-server + nvim-dap 或 ZeroBrane Studio。Sublime 的价值，在于极快地改、存、Ctrl+B、看结果，再改。节奏越紧凑，越容易盯住算法里的边界条件和状态漂移。
