sublime text 本身不运行 lua，但通过配置 lua enhanced 插件、lua-language-server 及正确 workspace.library 路径，可实现 ngx. 和 resty. api 的语义识别与补全；需确保 lua_code_cache off 生效路径正确，并结合 nginx.conf 配置、resolver 设置及 error.log 定位环境级问题。
Sublime Text 本身不运行 Lua，但配好工具链后，能高效编写、检查、跳转 OpenResty 的 Lua 脚本——关键不是“能不能写”，而是“能不能提前发现 ngx.var 拼错、resty.http 参数传反、或 lua_code_cache off 忘关导致本地调试失效这类问题”。
怎么让 Sublime 正确识别 ngx.* 和 resty.* API
默认的 Lua 插件完全不认识 OpenResty 特有变量和模块，会把 ngx.say 当作未定义函数标红。必须用语义级支持替代语法高亮：
- 装
Lua Enhanced插件（比原生Lua包更准，能识别ngx.req.get_uri_args()这类调用） - 必须搭配
lua-language-server（LSP 后端），并在 Sublime 中启用LSP插件 - 在项目根目录放
luaconfig.json，显式声明依赖路径："workspace.library": ["/usr/local/openresty/lualib"]，否则resty.core、resty.http等模块无法补全 - 别信插件自带的 “OpenResty” 配置模板——很多已过时，直接读
openresty -V输出的--prefix路径去配lua-language-server的runtime.path
lua_code_cache off 开关不生效？先查 Sublime 里是否真改了配置文件
开发阶段常开 lua_code_cache off 实时看 Lua 修改效果，但容易踩两个坑：
- 改的是
/etc/nginx/conf.d/xxx.conf，而 OpenResty 实际加载的是/usr/local/openresty/nginx/conf/nginx.conf（通过include引入），结果 reload 后还是旧行为 - 在 Sublime 里编辑了文件，但没保存（Sublime 默认禁用自动保存），或者保存到了错误路径（比如桌面副本）
- 确认方式：执行
nginx -t后看输出的配置文件路径，再用grep lua_code_cache查该文件里实际值 - 顺手加个
echo "config reloaded at $(date)"到content_by_lua里，curl 一下就能验证是不是真 reload 成功
调试 resty.http 超时或连接拒绝，别只盯着 Lua 代码
resty.http 报 failed to connect to upstream 或 timeout，90% 不是 Lua 写错了，而是环境或配置层漏了：
- 检查
resolver是否配置——如果 upstream 是域名，OpenResty 默认不带 DNS 解析能力，必须显式写resolver 8.8.8.8 valid=30s; - 确认
http模块里有没有lua_package_path指向正确的resty库路径，否则可能加载了旧版或损坏的http.lua - 用
curl -v http://upstream-host:port在 OpenResty 机器上直连测试，排除网络策略或防火墙问题 - Sublime 里 LSP 可能提示
http:request()参数合法，但实际运行时因keepalive_timeout设置过短，复用连接失败——这类问题 LSP 帮不上忙，得靠error.log里的lua entry thread aborted日志定位
OpenResty 的 Lua 脚本调试，本质是 Nginx 生命周期 + Lua 执行上下文 + 网络环境三者交叠的问题。Sublime 能帮你挡住语法和 API 层的坑，但 resolver 没配、lua_shared_dict 大小不足、或 worker_processes 设为 1 导致并发瓶颈这些，得回到 nginx.conf 和 error.log 里找答案。
