根本原因是Windows下Sublime以ANSI编码传递中文路径给Lua解释器，而lua.exe（5.4+）仅支持UTF-8路径，导致io.open等失败并报“找不到文件”；唯一稳定解法是将项目路径改为全ASCII。
Sublime Text 无法调试含中文路径的 Lua 项目，根本原因不是 Sublime 或 Lua 插件的问题，而是 lua.exe（尤其 5.4+）内部只接受 UTF-8 编码的文件路径，而 Windows 下 Sublime 启动进程时默认用 ANSI（如 GBK）传递 $file 路径——中间一转就乱码，io.open、dofile、require 全部失败。
为什么报 cannot open xxx: No such file or directory 却路径明明存在
这是最典型的症状。Lua 解释器收到的是损坏的路径字符串，比如 C:\项目\test.lua 变成 C:\??\test.lua 或直接截断。它根本没去找真实文件，自然报“找不到”。你用资源管理器双击打开、终端里用 cd 进去再 lua test.lua 都能成功，唯独 Ctrl+B 失败——说明问题出在 Sublime 构建系统传参环节。
- Windows GUI 程序（包括 Sublime）默认用系统 ANSI 代码页启动子进程，不自动转 UTF-8
- 即使你把 Sublime 设置成 UTF-8 编码保存文件，
$file变量传给 lua.exe 时仍是 ANSI 字节流 - luajit 表现类似，但部分旧版 lua 5.1 可能“碰巧”兼容性稍好，不可依赖
别试“改注册表强制 UTF-8”或“写批处理中转”
这类方案看似绕过问题，实际引入新风险：批处理本身也有编码陷阱；注册表修改影响全局，且从 Windows 10 1903 起已弃用 ActiveCodePage 方式；PowerShell 调用又涉及 ExecutionPolicy 和 profile 加载问题。你花半天调通一个 hack，不如直接切路径。
- Sublime 的
shell_cmd不支持管道和&&，写"shell_cmd": "powershell -Command \"cd '$file_path'; lua '$file'\""会因单引号、空格、中文引号全部崩掉 - 用 AutoHotkey 或 Python 中转脚本？增加依赖、启动延迟、错误堆栈指向中转器而非原文件，调试成本反而更高
- 试图在 Lua 脚本开头用
os.setlocale("Chinese")？无效——locale 不影响路径解析编码
唯一稳解：让路径全程保持 ASCII
这不是妥协，是直击根源。Lua 生态（尤其是游戏引擎如 LÖVE、Defold、Cocos）本身也强烈建议项目路径无空格、无中文、无特殊符号——避免跨平台构建和 CI 流水线出错。
- 把整个项目挪到纯英文路径下，例如
C:/dev/mygame/或D:/lua-projects/hello/ - 确保
$file展开后是类似C:/dev/mygame/main.lua这种全 ASCII 字符串 - 如果必须保留中文文档或资源目录，可软链接（Windows 用
mklink /D）或配置构建时用working_dir指向资源根，但主脚本路径仍需 ASCII - 验证方式：在构建系统里临时加一句
"cmd": ["cmd", "/c", "echo $file"]，看输出是否含乱码
file_regex 匹配失败也常源于中文路径
当 Lua 报错形如 我的脚本.lua:5: attempt to call a nil value，默认正则 ^(*?):([0-9]+):? (.*)$ 里的 * 无法匹配中文字符，导致点击错误行不跳转。这不是编码问题，是正则表达式字面量限制。
- 把
file_regex改成"^([^:]*?):([0-9]+):? (.*)$"——[^:]明确表示“非冒号任意字符”，能匹配中文、emoji、空格等 - 注意：这个改动只修复跳转，不解决路径打开失败；必须先搞定路径 ASCII 化，再调这个正则
- 如果用了 LuaEnhanced 插件，确认
selector是source.lua.enhanced，否则构建系统压根不生效
真正卡住人的从来不是配置几行 JSON，而是路径里那个“看起来没问题”的汉字——它让所有后续步骤都在错误前提下运行。动手前先 where lua 和 echo %CD% 看清环境，比反复改 file_regex 有用十倍。
