sublime text 不支持 httprepl，因其是独立的 .net cli 工具，无法嵌入；替代方案为 restclient 插件或自定义构建系统调用 httpie，但均不提供交互式会话功能。
Sublime Text 本身不支持 HttpRepl，也没有名为“HttpRepl 插件”的官方或主流扩展——httprepl 是 .NET CLI 全局工具，只能在终端中运行，无法嵌入 Sublime Text。
Sublime Text 里根本装不了 HttpRepl
很多人搜“Sublime HttpRepl 插件”，是误把命令行工具当成了编辑器插件。实际上：
-
httprepl是独立的 .NET 命令行程序，依赖dotnet运行时，不是 Python 或 Sublime 插件生态的一部分 - Sublime 的插件系统基于 Python（
sublime_plugin），无法加载或调用 .NET 工具二进制文件 - Package Control 中搜不到
HttpRepl或类似名称的合法插件；所有声称“支持 HttpRepl”的第三方包都不可信或已失效
想在 Sublime 里发 HTTP 请求，只能选 RESTClient 或手动调 HTTPie
如果你坚持在 Sublime 编辑请求、触发执行，可行路径只有两条，且都不涉及 httprepl：
- 用
RESTClient插件：写.http文件，按Ctrl+Alt+R（Win/Linux）或Cmd+Alt+R（macOS）发送，响应直接显示在 Sublime 面板里 - 用自定义构建系统 +
httpie：保存为test.http，配置shell_cmd为http --print=hb --pretty=all ，按 <code>Ctrl+B执行 - 二者都只做请求/响应展示，不提供
httprepl的交互式会话（如connect、set header、历史命令上下键等）
微服务接口就地调用，真正要解决的是环境与上下文问题
所谓“就地调用”，核心不是工具名，而是能否快速切换 base URL、注入 token、复用 session、解析响应字段。而 Sublime 的局限恰恰在这里：
-
RESTClient支持@host变量，但必须手动维护.env文件，且不支持动态 token 刷新（比如从登录响应提取access_token后自动设为后续请求 header） - 没有内置 JSONPath 或 jq 支持，查
response.data.items[0].id得复制到终端再跑jq，没法在编辑器内完成断言或字段提取 - 微服务常需链式调用（A → B → C），Sublime 无法编排流程，也不能保存中间变量，每次都是孤立请求
真要对接微服务，别卡在编辑器里折腾“就地”假象——用 httprepl 就去终端连；需要自动化就上 Postman / Insomnia / curl + jq 脚本；要集成进开发流，直接写 Spring Boot 的 RestTemplate 或 WebClient 调用逻辑。Sublime 只适合写、看、轻量触发，它不是运行时。这点容易被忽略，但决定了你花两小时配插件，不如花十分钟写个可复用的 .http 模板加一行 shell 脚本。
