Sublime Text 不支持 Lua 断点调试——它无原生调试器，不嵌入 Lua 解释器，也不实现 DAP 协议；Debugger 插件仅支持 Python/JS/Go 等语言的 attach 调试，对 Lua 文件静默忽略；真正可用方案是换用 IntelliJ IDEA + EmmyLua 或 ZeroBrane Studio。
Sublime Text 本身不支持 Lua 断点调试
直接说结论：Sublime Text 没有原生 Lua 调试器，也**不支持在代码中设断点并停住执行**。所谓“断点无法命中”，本质是误用了调试概念——你不是配置错了，而是选错了工具链。Sublime 的插件（包括 SublimeREPL）只提供交互式解释器（REPL）或构建运行能力，所有 Lua 代码都是通过调用外部 lua.exe 或 luajit 进程执行的，而 Sublime 自身既不嵌入 Lua 解释器，也不实现 DAP（Debug Adapter Protocol）协议。
为什么 Debugger 插件对 Lua 文件完全无效
Sublime 的官方 Debugger 插件（蓝色靶心图标）仅支持 attach 到符合 DAP 协议的独立语言服务器，比如 Python、JavaScript、Go 的调试进程。Lua 生态中目前只有极少数工具（如 EmmyLua、ZeroBrane Studio）实现了 DAP 服务端，而 Sublime 没有对应客户端适配。你在 Lua 文件里点左侧行号设断点，Debugger 插件根本不会识别该文件类型，也不会向任何后端发送断点请求——它只是静默忽略。
- 检查方式：打开命令面板（
Ctrl+Shift+P），输入Debugger: Toggle Breakpoint，如果命令不可见或执行无反应，说明当前语法/文件类型未被 Debugger 支持 -
SublimeREPL启动的是子进程，但不暴露调试端口，也无法传递断点信息 - 即使你手动改写构建系统去调用
lua -e "require'debug'.debug()"，也只会进入交互式调试器（类似 gdb 的命令行模式），和编辑器断点无关
真正能用的替代方案：换工具，不是调配置
如果你需要断点、变量监视、单步执行等完整调试体验，必须离开 Sublime Text。目前 2026 年稳定可用的方案只有两个：
-
IntelliJ IDEA + EmmyLua 插件：唯一成熟支持 Lua 断点调试的 IDE。需确保 SDK 指向含
lua.exe的目录，且项目为Lua Module类型（非普通 Project），否则断点灰色不可用 -
ZeroBrane Studio：轻量、开源、专为 Lua 设计。无需复杂配置，打开即用断点；支持远程调试 Unity / Cocos / GGE 等嵌入 Lua 的宿主环境，只要宿主集成了
mobdebug
别浪费时间折腾 Sublime 的 Lua 调试插件——没有一个主流插件（SublimeLinter-lua、SublimeText-Lua、SublimeREPL）提供断点能力，它们只做语法高亮、lint、REPL 执行三件事。
Sublime 里还能怎么高效查 Lua 问题
接受“不能断点”这个事实后，你可以靠以下方式快速定位逻辑错误：
- 在关键位置加
print()，配合SublimeREPL的Ctrl+, s快捷键选中执行，比保存+终端运行快得多 - 把
SublimeREPL的 Lua 构建系统指向带调试符号的 Lua 解释器（如luajit -jdump），用于性能分析而非断点 - 用
assert()替代断点：例如assert(type(x) == 'table', 'x 不是 table')，出错时立刻中断并打印上下文 - 开启 Sublime 控制台（
Ctrl+`），观察插件加载失败、路径错误、ImportError等底层异常——很多“脚本不运行”其实是require失败被静默吞掉
断点调试是语言服务器和 IDE 协同的结果，不是编辑器单方面能解决的功能。Sublime 的优势在极速响应与轻量定制，强行让它干 IDE 的活，只会陷入无解循环。
