Nginx Lua开发者初学时常常面临挑选编辑器的问题，IDE的选择其实早有几种流行方案，不过多数已被淘汰，单纯进行Lua代码的语法校验和自动补全，多数IDE都能胜任，VIM配合特定插件同样可以实现。
使用可视化界面进行Nginx程序调试的IDE，首选是ZeroBraneStudio这个编辑器，它通过Lua Socket实现底层通信，支持在IDE里对Lua代码进行断点设置，比如执行ngx.say("https://lua.ren")这句时，Nginx程序会在此处暂停，IDE的Output窗口会显示相应内容。
这种调试方式依托于ZeroBraneStudio的图形界面，要求Nginx服务与ZeroStudio应用运行在同一台设备上，并且必须安装XWindow系统，然而，采用ZeroBraneStudio的用户数量有限，同样，借助ZeroStudio对Nginx或OpenResty实施断点检测的操作者也不多见，此类环境的搭建过程颇为复杂，此外，在部署于生产环境的Linux服务器上，配置XWindow系统并无太大必要，主要用途仅限于本地调试以及远程代码同步，尽管当前仍可寻找到先前在网上发布的相关调试步骤指南。
耗费了大约五年时长，国内采用ZeroBraneStudio的人就变得稀少，并且多数情形下，寻求调试支持解决故障时，并非通过设置断点来分析内存等资源，此种方式成效并不理想。更高级的做法是借鉴春哥的方法，直接借助火焰图来呈现Lua的运行情况，利用Xray来监测OpenResty服务的运作状态，借助Ylang来促进新功能的开发，通过整合各类指标数据进行分析，由此便能够获得一种全新的观察角度。
长篇大论的开源编程环境并未兴盛开yun体育app官网网页登录入口，不过借助类似VSC这种致力于统合各类开发工具的步伐，也能够实现针对OpenRest以及Nginx这类服务的远程调试功能。安装相应的扩展插件即可达成此目标。个人在OpenResty服务开发方面，运用起来十分方便，因此参考了T婶（tweyseo）撰写的文章，内容是关于在本地Windows系统，借助VSC的SSH插件kaiyun全站网页版登录，远程调试服务器中的OpenResty程序，这篇文章是全网独家首发，现提供给大家，具体如下：
背景
我们公司的测试和生成环境部署的Linux系统都是Red Hat Enterprise Linux Server release 7.3（Maipo），这个版本与云商提供的CentOS 7.3（1161）保持一致，而本人个人电脑则安装了Windows 10操作系统，为了提升在Linux平台上开发和调试Openresty程序（ngx-lua模块）的效率，决定在Windows设备上借助VSCode工具，通过Remote-SSH扩展和C/C++扩展功能，实现远程对Linux环境中的Openresty程序（ngx-lua模块）进行开发与调试工作。
远程开发
起初，在Windows系统上借助PowerShell，需要核实OpenSSH客户端的可选组件是否已启用，或者能够借助git-bash来创建，目的是为了生成用于SSH登录的公钥和私钥对
将公钥文件test.pub里的文本，传输到远程Linux设备上，粘贴到对应用户的.ssh/authorized_keys文档里，若该文档不存在则需新建。随后，借助PowerShell执行SSH登录操作，检验先前步骤是否得当。
随后，在VSCode中查找并安装Remote-SSH插件，同时确保包含Remote-SSH: Editing Configuration Files的附加组件也一并安装，然后需要设置SSH登录的相关配置，可以通过按下CTRL+SHIFT+P并选择Remote-SSH: Open Configuration Files来完成这一步骤。
保存之后，在左侧边栏的远程资源管理部分，会出现相应的SSH远程连接，即名为test(tweyseo)的那个会话。进入test(tweyseo)账号时，登陆步骤十分便捷，接着挑选该账号在远端Linux系统里的特定文件夹，将其关联到VSCode的资源库，随后便能在个人电脑上自由操作这个文件夹内的文档，同时，一旦建立关联，VSCode会在远端资源库中为test(tweyseo)创建一个专属的子会话（属于同一个SSH远程会话），往后只需使用这个子会话，就能在VSCode的资源库中再次关联这个文件夹。最后，需要创建一个终端，使其自动连接到那个工作目录。这样，借助Windows版的VSCode，就能实现在本地操控Linux系统上的程序开发，整个过程就顺利结束了。
借助Remote-SSH扩展的配置功能，将remote.SSH.showLoginTerminal设定为真的状态，有助于更准确地查找登录环节所遇到的障碍。
由于当前任务的核心是构建Linux环境下的Openresty应用（ngx-lua组件），因此必须安装并设置VSCode的C/C++插件，以便在编码阶段获得智能感知功能。这里要留意的是，由于我们进行远程开发，因此这里的C/C++扩展必须借助SSH-Remote扩展，在test(tweyseo)这个SSH远程会话对应的远端Linux系统上的VSCode Server中完成安装，而不是在本地完成安装，即便你在本地和远端都安装了C/C++扩展，该扩展也只会在一处被激活，要么是本地，要么是远端。装置结束后，在作业文件夹关联的作业单元里直接设定“设定”项的C/C++插件相关配置（其中包含路径部分使用的**代表逐层目录下所有文件夹）：
现在，已经准备好在Windows系统的VSCode中远程开发Linux环境下的Openresty程序了，也就是ngx-lua模块，相关的准备工作已经结束。具体来说，工作区的选择和includePath的设置，将在后续部分进行详细说明。
远程调试
这个操作主要是借助VSCode自带的debuggee功能来实施远程调试的。
此处主要任务是研制Linux系统上的Openresty软件（ngx-lua组件），因此，首要条件是确保远程Linux设备必须配备调试C程序所必需的glibc-debuginfo-common-xxx和glibc-debuginfo-xxx，glibc的精确版本号能够通过rpm -qa | grep glibc命令查询，随后前往debuginfo.centos.org获取相应的rpm文件，当然也可以选择直接运用debuginfo-install完成安装。
接下来是构建带有调试功能的Openresty程序，首先在执行./configure命令时必须加入--with-debug参数，其次在开始make操作之前，需要进入nginx的Makefile文件，将编译优化等级调整为-O0。
编译工作结束后，需要在路径/path/to/your/openresty/处创建一个名为*.code-workspace的工作空间，原因是Openresty（nginx）所加载的模块的源代码（含nginx本身代码）大多存放在此路径下的build目录中，不论你是处理ngx-lua模块，还是其他模块，抑或是nginx本身，都能随时将build目录下相关文件夹的路径加入该工作区的路径属性（这些文件夹也会在VSCode的资源管理器中列出），而且添加到工作区的文件夹可以共享（当然也能单独设置特定文件夹的配置），共享的配置包含VSCode自身设置及所有已安装扩展的设置，如此能将纷繁复杂的配置在用户（本地）、远程、工作区及不同文件夹间清晰地区分开来。
同样的，todo：
需要特别指出的是，建议大家将我们提供的Openresty程序的操作目录也放置到这个工作区域里，如此一来，我们便能够借助VSCode的资源管理功能直接修改Openresty程序的业务部分代码，进而让我们可以更加便捷且清晰地针对特定业务环境下的ngx-lua乃至nginx本身展开调试工作。
现在要为调试目标VSCode设置相关参数，直接在对应工作区的启动配置部分进行设定。根据实际需要，可以针对不同的调试情形采用不同的调试目标设定方案。我们能够对正在运作的Openresty程序的领导进程或从属进程实施排错，比如功能验证环节，这种排错方式关联的launch特性的请求种类是附加
设置列表包含以下内容, 其中一项配置的名称为调试nginx服务器, 类型为cpp调试器, 请求方式为附加, 目标程序位于指定路径, 通过命令选择进程id, 使用gdb模式, 配置指令包括启用gdb的格式化输出功能, 忽略执行失败的情况启动调试模式，F5将被激活，接着需要选取Openresty程序的主进程或工作进程的进程标识号，这个可供选择的进程标识号列表可以通过VSCode自带的${command:pickProcess}指令获取，选定后即可着手进行调试操作。
我们同样能够以单线程形式运行在主界面上的Openresty软件，比如在功能实现环节，不过这种情况下必须调整Openresty（nginx）的相关设定
aemon off;
master_process off;这种设置方式关联到启动特性的请求种类时，具体表现为启动指令。
"configurations": [
{
"name": "(gdb) Launch-nginx",
"type": "cppdbg",
"request": "launch",
执行程序位于路径/path/to/your/openresty-debug/nginx/sbin/nginx
参数列表包括, 前缀为, 文件路径为, 你的nginx配置文件所在位置
"stopAtEntry": false,
工作目录路径为路径到你的项目之中
"environment": [],
"externalConsole": false,
"MIMode": "gdb",
"setupCommands": [
{
"设置gdb的格式化输出功能,可以美化显示内容"
"关闭美化输出功能"
"ignoreFailures": true
}
]
}
]选定该调试模式后，F5启动，即可开始调试工作：
最终，在两种情形下，均能借助调试界面输入-exec与debuggee（此处实际为gdb）展开互动，例如输入-exec info registers（与gdb info registers效果相同）用以检视寄存器详情（其他相关指令请参阅man gdb文档）。
扩展
远程编译
todo
attach模式自动选择对应pid
在使用attach的调试模式期间，往往需要不断重复按下F5键并输入进程ID，而且每次操作的进程ID都可能不同，这就导致，每次进行attach调试时，都必须先通过终端执行shell命令来找出相应的进程ID，然后再将该进程ID用于attach进行调试kaiyun.ccm，这样的工作效率实在令人无法忍受。
启动环节里的预发布任务配置，是在输入环节完成之后才运作的，而流程标识符所引用的${command:pickProcess}也归属于输入范畴，因此借助预发布任务配置来达成目的不可行。
指令仅限于系统自带的或是已安装插件所支持的类型，因此同样无法达成。
带研究。
launch模式结束后的清理工作
Openresty（ngx）的配置里打开了reuseport功能，这个功能允许在同一工作目录里运行好几个Openresty实例，但这种做法必须极力防止，因此需要在启动脚本里检查nginx.pid文件是否存在，以此确保工作目录中仅能有一个Openresty程序在运行。然而，在启用launch的调试状态后，调试过程结束后，nginx.pid这个文件仍然存在。
此处针对启动模式下的相关设置，需设定postDebugTask属性，并联合VSCode的任务功能，在启动调试流程终止后，执行移除nginx.pid文件的操作。
