Sublime Text 仅编辑 .hurl 文件，Hurl 才执行测试；需手动配置语法高亮、Snippet 和构建系统，但无法解析结构化错误或跳转报错行；推荐终端直接运行 hurl --test 并配合 --dry-run 检查变量。
Sublime Text 本身不执行任何 HTTP 请求或断言，它只是个编辑器；Hurl 才是真正跑测试的工具。所谓“配合”，本质是用 Sublime 编辑 .hurl 文件，再通过终端或构建系统调用 hurl 命令执行——中间没有进程集成，也没有实时反馈。
怎么在 Sublime 里高效写 .hurl 文件
Sublime 对 .hurl 没有原生支持，但可手动配置语法高亮和补全：
- 把
hurl语法定义为自定义语言：新建Packages/User/Hurl.sublime-syntax，内容基于 YAML + 注释规则（Hurl 文件本质是带注释的类 YAML 文本） - 安装
YAML插件后，将.hurl关联到 YAML 语法（右下角点击语法名 →Open all with current extension as...→YAML），能获得基础缩进、括号匹配和 key 高亮 - 用
Snippet快速插入常用结构，例如创建http_get.sublime-snippet：<![CDATA[ # ${1:desc} GET ${2:url} HTTP ${3:200} [Asserts] jsonpath "$.${4:body.path}" == "${5:value}" ]]> - 避免在注释里写中文标点（如「」、。），Hurl 解析器虽通常容忍，但某些旧版会因 UTF-8 BOM 或空格截断导致
hurl --test报Parse error
为什么不能直接在 Sublime 里点一下就跑测试
Sublime 的构建系统（Build System）只能触发外部命令并捕获 stdout/stderr，无法：
- 拦截
hurl的结构化失败信息（比如哪一行jsonpath断言失败、实际值 vs 期望值），它只会把整个错误日志当纯文本输出 - 高亮跳转到出错的
.hurl行号（Postman 或 VS Code 插件能做，Sublime 默认构建系统做不到） - 自动重载变量或缓存响应体——Hurl 的链式请求依赖单次执行上下文，构建系统每次都是新进程，无法复用
csrf_token等捕获值 - 如果你硬配了构建系统，命令得写成：
hurl --test $file --report-html /tmp/hurl-report.html，但报告要手动打开，且/tmp/路径在 Windows 上不通用
真正能落地的协作流程
团队用 Sublime 写 .hurl，靠的是“编辑即规范”，不是“编辑即运行”：
- 所有
.hurl文件必须放在项目根目录下的tests/api/，命名统一为login_flow.hurl、search_pagination.hurl，不用test_前缀（Hurl 会自动识别） - 环境变量用
{{BASE_URL}}而不是硬编码https://staging.example.com，然后通过hurl --variable BASE_URL=https://dev.example.com login_flow.hurl注入 - CI 流水线里只跑
hurl --test tests/api/*.hurl，不依赖 Sublime；本地验证也推荐直接终端执行，比构建系统快且信息全 - 如果非要快捷键触发，可用
sublime_plugin.WindowCommand写个极简插件，仅做一件事：sublime.set_timeout_async(lambda: os.system(f"hurl --test {view.file_name()} > /tmp/hurl.log 2>&1"))，再用tail -f /tmp/hurl.log监看——别试图在 Sublime 里解析日志并弹窗提示
最易被忽略的一点：Hurl 的 [Captures] 和 [Asserts] 共享同一作用域，但 Sublime 不校验变量是否被定义。写 {{missing_var}} 时，Hurl 运行时报 Variable not found，而 Sublime 编辑时完全无提示——得靠 hurl --dry-run 提前检查语法和变量引用。
