sublime text 不支持 hurl 插件，因其插件 api 无法实现 hurl 所需的 json 响应解析、断言失败定位、多请求上下文传递等核心能力；唯一替代方案是配置构建系统调用 hurl 命令，但存在错误定位不准、变量不自动注入等硬限制。
Sublime Text 本身不支持 Hurl 插件——不存在官方或社区维护的“Hurl Sublime 插件”。 你无法在 Sublime 中像 VSCode 那样通过扩展直接运行 hurl 命令、解析 .hurl 文件语法或做断言校验。所有声称“Hurl for Sublime”的方案，本质是手动调用命令行 + 自定义构建系统，且缺失关键能力。
为什么 Sublime Text 无法原生支持 Hurl 测试
Hurl 的核心能力（如 jsonpath 断言、[Captures] 变量提取、请求链执行）依赖其二进制解析器和运行时环境，不是纯文本渲染或语法高亮问题。Sublime 的插件 API 不提供进程间 JSON 响应解析、断言失败定位、多请求上下文传递等能力。即使你把 .hurl 文件用 Sublime 打开，它也只是一堆文本——没有执行引擎，就没有测试。
- Sublime 的 Python API 不能 spawn 并同步捕获
hurl --test的完整输出（尤其是彩色错误定位、断言详情） - 无法在编辑器内高亮显示哪一行
jsonpath "$.args.foo"断言失败，也无法跳转到对应行 - 不支持
{{variable}}模板变量的实时补全、作用域检查或环境注入
勉强可行的替代路径：用 Sublime 构建系统调用 hurl
如果你坚持在 Sublime 里触发测试，唯一办法是配置 Tools → Build System → New Build System…，写一个 shell 调用，但要注意这些硬限制：
- 必须确保
hurl已安装且在$PATH中（which hurl要返回路径） - 构建系统只能捕获 stdout/stderr，无法解析
hurl --test的结构化失败信息（比如具体哪条jsonpath行错） - 不能自动重用当前文件中的
@host或@token变量定义——Hurl 的--variable需显式传参 - 示例构建配置（保存为
Hurl.sublime-build）：
{
"shell_cmd": "hurl --test "$file"",
"file_regex": "^(.*?):(\d+):\d+:.*$",
"working_dir": "$file_path",
"selector": "source.hurl"
}
注意：file_regex 仅能粗略匹配 basic.hurl:5:0 这类位置，但 Hurl 默认错误格式并不严格匹配 Sublime 的跳转规则，点击错误行大概率不会定位准确。
真正能落地的轻量级方案：换工具，别硬扛
如果你要的是“声明式 + 断言 + CI 友好 + 编辑器内反馈”，Sublime 就不是合适载体。现实选择只有三个：
- 用 VSCode +
REST Client：支持.http文件，可发请求、看响应、查状态码，但无断言——适合调试，不是测试 - 用 VSCode +
Hurl官方 CLI（配合终端或任务）：能跑.hurl文件、做完整断言、生成报告，但需手动执行，无内联高亮 - 直接在终端跑
hurl --test test.hurl：最可靠，错误信息完整，支持--report-html输出可视化报告，和 CI 流水线完全一致
最后提醒一句：Hurl 的价值不在“在哪编辑”，而在“怎么定义和验证”。把精力花在写清楚 [Asserts] 和 [Captures] 上，比折腾 Sublime 构建系统有意义得多。文件本身是纯文本，Git 提交、CI 运行、团队复用，都不依赖编辑器。
大量免费API接口：立即使用
涵盖生活服务API、金融科技API、企业工商API、等相关的API接口服务。免费API接口可安全、合规地连接上下游，为数据API应用能力赋能！
