sublime text 无法直接部署接口测试，需借助 http requester 插件手动执行 .http 文件；它支持基础请求与响应查看，但不支持环境变量、链式调用或自动化测试，适合高效编辑而非执行。
Sublime Text 本身不能“部署接口测试”，它只是编辑器；所谓“快速部署”，实际是用它写好请求定义，再靠外部工具执行——最轻量、最可控的路径是 HTTP Requester + 手动触发，而不是硬配构建系统或幻想一键运行。
HTTP Requester 是唯一靠谱的即装即用方案
别搜 Rest Console，它在 Package Control 里根本不存在；强行安装会静默失败，.http 文件里写完请求也看不到发送按钮、没有语法高亮，这是最明确的“插件没装上”信号。真正可用的是 HTTP Requester：
- 支持
GET/POST/PUT/DELETE，Header 和 JSON Body 直接写在文件里 - 装完不用配置：新建
test.http，写好请求，右键 →HTTP Requester: Execute或按Ctrl+Alt+R（Windows/Linux）/Cmd+Alt+R（macOS）就能发 - 响应直接弹出新标签页，显示原始响应体 + 状态码，不自动格式化 JSON，但够你一眼看清是否
200或401 - 不支持环境变量切换——如果要测 dev/staging/prod，得手动改 URL 或复制请求到 VSCode 的
REST Client中执行
别碰构建系统跑 curl 或 hurl
有人想用 Sublime 的构建系统调 curl 或 hurl --test 实现“自动化”，结果只会卡在三处：
-
hurl报错时只输出纯文本日志，Sublime 捕获不到结构化信息，没法跳转到出错的.hurl行号 - 每次构建都是新进程，
csrf_token这类需要链式提取的值无法复用，hurl的变量捕获机制完全失效 - 构建命令如
hurl --test $file --report-html /tmp/hurl-report.html在 Windows 上路径不通用，报告还得手动打开
真要跑声明式测试，就老老实实终端里敲 hurl --test login_flow.hurl，加 --dry-run 先检查变量注入是否生效。
敏感信息和多环境怎么处理
HTTP Requester 不支持环境变量，但你可以用简单约定规避硬编码：
- URL 写成
https://{{BASE_URL}}/api/users，然后复制整段请求到终端用curl -X GET https://dev.example.com/api/users -H "Authorization: Bearer $TOKEN"手动补全 - 把 token、密钥等敏感字段存在独立的
secrets.env文件里，用 Sublime 多光标快速替换{{API_TOKEN}}占位符 - 不同环境建不同文件夹：
http/dev/、http/staging/，靠文件路径区分，避免混用
复杂场景（比如登录后拿 token 再调下一个接口）别强撑，HTTP Requester 做不了链式请求——这时直接切到 Postman 或 VSCode 的 REST Client，Sublime 只当草稿本。
真正容易被忽略的是：Sublime 的优势不在执行能力，而在编辑效率。多光标改参数、正则批量修 Header、Snippet 插入标准请求模板——这些才是它不可替代的地方。别花时间折腾“自动化”，把请求写清楚、存好、版本控制住，比什么都实在。
