Sublime Text 无法调试 Lua 脚本，尤其是加密脚本，因其仅为纯文本编辑器，无内置调试器和 Lua 运行时；调试需绕过加密层，在运行时捕获解密后的代码并配合外部调试器。
Sublime Text 本身不支持调试 Lua 脚本，更无法调试“打包后加密”的 Lua
直接说结论：Sublime Text 是纯文本编辑器，没有内置调试器，也不提供 Lua 运行时环境。所谓“调试加密脚本”，本质是调试**运行时解密后、实际执行的 Lua 字节码或源码**——而加密层（如 `loadstring` + AES 解密、自定义 loader、或第三方加壳工具）往往在 Lua VM 启动后才介入，Sublime 完全感知不到这个过程。
为什么你看到的 xxx.lua.enc 文件无法被 Sublime 调试
常见误解是“只要文件是 .lua 结尾就能调试”。但加密脚本通常：
- 不是标准 Lua 源码，而是二进制 blob 或 Base64 编码字符串，
sublime-text打开只能显示乱码或不可读字符 - 真实逻辑藏在
require时动态加载的loader里，比如重写了package.loaders[2]去解密并调用load - 即使你反解出明文 Lua，它也可能依赖打包时注入的全局环境（如自定义
_G.print、加密上下文表），直接运行会报attempt to call a nil value
可行路径：绕过加密层，在运行时捕获真实 Lua 代码
目标不是让 Sublime “理解加密格式”，而是让真实 Lua 环境把解密后的代码暴露出来，再配合外部调试器。常用方法：
- 在自定义
loader中加一行：io.open("decrypted.lua", "w"):write(chunk):close()，把load前的 chunk 写出（注意 chunk 可能是字符串或函数） - 若使用
luajit -jv或lua -v启动，加-e "debug.getinfo(1).source"类似钩子，定位当前执行文件来源 - 用
mobdebug或remotelua连接正在运行的 Lua 进程（需目标进程启用调试服务，且未禁用debug库） - 若加密只做字符串混淆（非二进制），可用
string.dump+luac -l反汇编字节码，再人工还原逻辑（但无法设断点）
Sublime Text 能做的只有辅助环节
它唯一可靠的角色是作为“查看器”和“轻量编辑器”：
- 用
Package Control安装LuaEnhanced插件，获得语法高亮和跳转（对解密后的明文 Lua 有效） - 配置
Build System调用本地lua或luajit执行解密后脚本："cmd": ["luajit", "$file"]，但仅限无加密依赖的场景 - 用
Ctrl+Shift+P → Insert Snippet快速插入调试语句，如print(debug.traceback())或for k,v in pairs(_G) do print(k) end
真正卡点永远在加密 loader 的行为是否可控、目标进程是否开放调试端口、以及你是否有权限修改启动参数——这些和 Sublime 无关，也很难绕过。
