企业官网建设流程全解析

1. 为什么用 Postman 梳理 ElasticSearch 接口——不是工具选择，而是工作流刚需

你有没有遇到过这样的场景：刚接手一个 Elasticsearch 集群，文档里只有一句“请调用 /_search 接口”，连索引名都没写全；或者开发联调时，后端甩来一串 curl 命令，你复制粘贴到终端，结果报错{"error":"index_not_found_exception"}，但根本不知道是索引名拼错了、还是 mapping 字段类型不匹配、抑或是权限没开；又或者在 Kibana Dev Tools 里反复敲GET /my_index/_mapping，改个字段类型还得切回浏览器刷新页面，效率低得让人想砸键盘。这些不是小问题，而是每天真实发生在搜索、日志、监控、推荐等业务线上的高频痛点。而 Postman 在这里扮演的，远不止是个“HTTP 请求发送器”——它是一套可版本化、可协作、可复现、可沉淀的 ElasticSearch 接口操作工作流底座。我带过的三个搜索平台项目里，团队平均接口调试时间从 4.2 小时/人/天，压降到 1.3 小时，核心就是把 Postman 当成 ElasticSearch 的“交互式说明书”来用，而不是临时起意点几下就完事。它解决的不是“能不能发请求”，而是“怎么让每一次请求都留下可追溯、可复用、可验证的痕迹”。比如，一个标准的索引创建请求，Postman 能同时存下：完整的 JSON body（含 settings 和 mappings）、预设的环境变量（如{{es_host}}:9200）、前置脚本（自动检查集群健康状态）、测试脚本（断言 shards 分配成功）、甚至导出为 OpenAPI 3.0 规范供前端直接消费。这已经超出了“测试工具”的范畴，成了团队级 ElasticSearch 知识资产的载体。尤其对刚接触 ES 的同学，Postman 的可视化结构、实时响应体高亮、历史请求回溯、环境变量隔离等功能，比硬啃官方 REST API 文档或死磕 curl 更直观、更容错、更贴近真实开发节奏。所以，这篇笔记不是教你怎么点开 Postman 点几下按钮，而是拆解一套经过生产环境千次验证的、围绕 ElasticSearch 全生命周期操作的 Postman 工作法——从单点请求到批量索引管理，从权限调试到性能探查，每一步都带着为什么这么设计、踩过什么坑、以及如何让下一个人接手时不用再从零摸索。

2. 整体设计思路与方案选型逻辑——为什么不用 Kibana Dev Tools 或 curl？

2.1 核心矛盾：ElasticSearch 的 RESTful 特性 vs. 开发协作的实际需求

ElasticSearch 本质是一个纯 RESTful 服务，所有操作都通过 HTTP 方法（GET/PUT/POST/DELETE）+ URI + JSON Body 完成。理论上，curl 就够了；Kibana Dev Tools 也足够强大。但实际工作中，这两者暴露了明显短板：

• curl 的不可持续性：一条命令curl -X PUT "localhost:9200/my_index" -H "Content-Type: application/json" -d '{"settings": {"number_of_shards": 3}}'，看似简单，但一旦涉及多层嵌套 JSON（比如带 analyzer 的 mappings）、需要动态替换 host/port、要批量创建 20 个索引、或需在不同环境（dev/staging/prod）间切换，命令行就迅速变成维护噩梦。你没法给 curl 命令加注释，没法做参数化，没法一键运行整个测试集，更没法把“创建索引 + 写入样例数据 + 验证查询”打包成一个可分享的流程。

• Kibana Dev Tools 的封闭性：它确实专为 ES 设计，语法高亮、自动补全、结果折叠都很友好。但它深度绑定 Kibana 实例，无法脱离浏览器使用；所有请求历史只存在本地 LocalStorage，换台电脑或清缓存就丢失；不支持环境变量管理（你不能定义{{cluster}}然后在 dev/staging/prod 间一键切换）；最关键的是，它无法生成标准化的 API 文档或测试报告，团队协作时，你只能截图发给同事，对方还得手动重输一遍。

Postman 的价值，恰恰在于它用通用 HTTP 工具的灵活性，弥补了专用工具的封闭性。它不假设你是 ES 专家，而是提供一个“沙盒”：你可以把每个 ES 接口当做一个独立的、可配置的、可组合的模块来对待。比如，一个“创建索引”请求，我们不会只存一个 URL，而是会：

• 在URL中使用环境变量{{es_host}}:{{es_port}}/{{index_name}}；
• 在Body中用 raw JSON，但关键字段（如number_of_shards）用{{shard_count}}占位；
• 在Pre-request Script中写一段 JS，自动生成当前时间戳作为索引名后缀；
• 在Tests里写断言，确保响应 status 是 200 且acknowledged为 true；
• 最后把这个请求保存进一个叫 “Index Management” 的 Collection，并打上@es7标签。

这套设计不是炫技，而是直击痛点：让每一次对 ES 的操作，都成为可复用、可验证、可传承的知识单元。我见过最典型的反面案例，是某电商搜索组，三年前的索引模板全靠一位离职同事的本地 curl 记录文件维持，新同事入职后花两周才搞清product_v2_template和product_v2_backup_template的区别，期间线上搜索降级两次。而用 Postman，这个模板会是一个带详细注释的请求，环境变量清晰标注适用版本，测试脚本自动校验字段映射是否合规，新成员导入 Collection 后，5 分钟就能跑通全流程。

2.2 方案选型：Postman 的三大不可替代优势

为什么最终锁定 Postman，而非 Insomnia、Hoppscotch 或自研工具？基于过去五年在六个 ES 项目中的实测对比，它的优势非常具体：

1. 环境变量系统是工业级的：Postman 的 Environment + Global Variables 构成了一套完整的配置中心。你可以定义dev环境：es_host = "192.168.1.10"，es_port = "9200"，auth_token = "Basic YWRtaW46YWRtaW4="；再定义prod环境：es_host = "es-prod.internal"，es_port = "443"，auth_token = "Bearer xxxxx"。切换环境，所有请求自动适配。而 Insomnia 的环境变量是 per-request 的，Hoppscotch 则完全依赖浏览器存储，无法跨设备同步。这点对 ES 运维至关重要——一个集群的 health API、cat API、snapshot API 的 endpoint 可能分散在不同 host，Postman 能用一套变量体系统管。

2. Collection Runner 的批量能力是刚需：ES 的日常运维大量依赖批量操作。比如每日凌晨的索引滚动（rollover），需要按顺序执行：① 检查旧索引大小 ② 创建新索引别名 ③ 执行 rollover ④ 更新 ILM 策略。Postman 的 Collection Runner 支持按顺序、带延迟、带迭代次数执行整个请求链，并生成 HTML 报告。我们曾用它自动化测试 12 个不同分片数、不同副本数的索引创建耗时，数据直接导出 Excel 做容量规划。curl 或 Dev Tools 做这种链式操作，只能写 shell 脚本，可读性和可维护性差一个数量级。

3. 文档与协作的闭环生态：Postman 的 Public Documentation 功能，能把整个 Collection 自动生成交互式 API 文档。点击文档里的 “Run in Postman” 按钮，用户直接导入你的环境和请求，零配置上手。我们给客户交付的 ES 对接文档，就是一份 Postman 文档链接，客户技术团队点开就能试所有接口，反馈周期从“邮件来回问参数”缩短到“10 分钟内定位问题”。而 Kibana 的 Console 没有导出功能，curl 更是纯文本。

提示：Postman 的免费版已完全满足 ES 日常操作需求。无需付费升级，重点是用好它的核心能力——环境变量、Collection、Pre-request Script 和 Tests。那些花哨的 Mock Server 或 Monitoring 功能，在 ES 场景下几乎用不到。

3. 核心细节解析与实操要点——从零搭建你的 ES Postman 工作区

3.1 环境初始化：三步构建安全、可切换的 ES 操作基座

Postman 的力量始于环境（Environment）的合理设计。一个混乱的环境变量表，会让后续所有请求变得脆弱。我建议采用“三层变量”结构，这是经过多个生产集群验证的最小可行方案：

1. Global Variables（全局变量）：存放所有环境共用的、不变的值。

   • es_version:"7.17.0"—— 明确标注集群版本，避免因 API 变更导致请求失败（如 ES 8.x 移除了_search?q=的简单查询语法）。
   • api_base_path:"/"—— 大部分 ES 集群部署在根路径，但有些企业级部署会在/es/下，统一在此配置，避免每个请求 URL 里硬编码。
   • timeout_ms:"30000"—— 设置默认超时，防止慢查询卡死整个 Runner。

2. Environment Variables（环境变量）：按集群划分，每个环境独立。

   • es_host:"127.0.0.1"—— 注意，不要写localhost，某些网络策略下解析可能失败。
   • es_port:"9200"—— ES 默认端口，HTTPS 时为443。
   • auth_method:"basic"—— 支持basic、bearer、none三种模式，便于统一处理认证逻辑。
   • auth_header:""—— 这个变量由 Pre-request Script 动态生成，不在环境里手动填。

3. Data Variables（数据变量，用于 Runner）：仅在批量运行时注入。

   • index_name:"logs-2023-10-01"—— Runner 迭代时传入。
   • doc_id:"12345"—— 用于批量写入测试。

创建步骤（以 Windows 为例）：

• 打开 Postman → 右上角Environments→Create a new environment→ 命名为ES-Dev。
• 在Initial Values栏填写es_host,es_port,auth_method等。
• 切换到Current Values栏，这里才是你实际运行时的值。Initial Values是模板，Current Values是实例。例如，Initial Values里es_host是127.0.0.1，Current Values里可以是192.168.56.10（Vagrant 虚拟机 IP），这样你就能在不同机器上用同一套 Collection，只需改 Current Values。
• 点击Add保存。重复此过程，创建ES-Prod、ES-Staging等环境。

注意：绝对不要在Current Values里存敏感信息（如密码）。Postman 的auth_header应该由脚本动态生成。例如，在 Pre-request Script 中写：

if (pm.environment.get("auth_method") === "basic") { const username = "admin"; const password = "admin"; // 生产环境应从 pm.variables.get("password") 获取，该变量由外部注入 const token = btoa(`${username}:${password}`); pm.request.headers.add({key: "Authorization", value: `Basic ${token}`}); }

这样，密码永远不会明文出现在环境变量里，符合安全审计要求。

3.2 Collection 结构设计：按 ES 生命周期组织，拒绝杂乱无章

一个优秀的 ES Postman Collection，应该像一本结构清晰的《ElasticSearch 操作手册》，而不是一堆散落的请求。我采用“四层金字塔”结构，覆盖 ES 从接入到运维的全链路：

• Level 0: Root Collection——ElasticSearch-Operations

  • 这是顶层容器，不放具体请求，只做分类和描述。

• Level 1: Major Categories—— 四个核心子 Collection：

  • 01-Cluster-Health & Info：集群级操作，如GET /_cat/health?v、GET /_nodes/stats?pretty。
  • 02-Index-Management：索引全生命周期，创建、删除、打开、关闭、rollover、shrink。
  • 03-Document-Operations：文档 CRUD，PUT /index/_doc/id、POST /index/_search、DELETE /index/_doc/id。
  • 04-Advanced-Features：聚合、suggest、script、ingest pipeline、security API。

• Level 2: Sub-Categories—— 每个 Level 1 下再细分。例如02-Index-Management下：

  • Create Index：含标准模板、带 mappings 的模板、带 settings 的模板。
  • Template Management：PUT /_index_template/my_template。
  • ILM Policies：PUT /_ilm/policy/logs_retention。

• Level 3: Individual Requests—— 每个请求命名遵循动词-名词-场景格式，如PUT-index-with-mappings-v7、GET-search-with-aggs-top-10。名称里带版本号，明确兼容性。

这种结构的好处是：新人导入 Collection 后，一眼就能找到“我要查集群健康状态该去哪”，而不是在上百个请求里翻找。而且，Postman 支持为每个 Folder 添加 Description，你可以在这里写上关键说明：

02-Index-ManagementFolder Description: "所有索引操作均基于 ES 7.17.0。注意：ES 8.x 中 'type' 参数已被移除，创建索引时请勿包含 '_doc'。本 Folder 内请求已全部移除 type 字段。"

3.3 关键请求实操：以“创建索引”为例，拆解每一个可复用的细节

“创建索引”看似最基础，却是最容易出错的起点。一个健壮的 Postman 请求，必须包含五个要素：URL、Headers、Body、Pre-request Script、Tests。下面逐项拆解，告诉你为什么每个环节都不能省。

URL:{{es_host}}:{{es_port}}{{api_base_path}}{{index_name}}

• {{index_name}}是一个变量，不是固定字符串。这样，同一个请求可以创建logs-2023-10-01或users-v2，只需在 Runner 里传入不同值。
• {{api_base_path}}确保路径可配置，适应不同部署。

Headers:

• Content-Type:application/json—— ES 严格要求，否则返回 406 错误。
• kbn-xsrf:true—— 如果你连接的是 Kibana 代理的 ES，这个 header 是必须的，否则 403 Forbidden。可以在 Pre-request Script 中动态添加，避免手动开关。

Body (raw JSON):

{ "settings": { "number_of_shards": {{shard_count}}, "number_of_replicas": {{replica_count}}, "refresh_interval": "30s" }, "mappings": { "properties": { "timestamp": { "type": "date", "format": "strict_date_optional_time||epoch_millis" }, "message": { "type": "text", "fields": { "keyword": { "type": "keyword", "ignore_above": 256 } } } } } }

• 所有数字参数（shard_count,replica_count）都用变量，方便在不同环境调整。shard_count在 dev 环境设为 1，prod 环境设为 5。
• format字段明确指定日期格式，避免因客户端时间格式不一致导致 mapping conflict。

Pre-request Script:

// 自动检查集群健康，避免在 red/yellow 状态下创建索引 pm.sendRequest({ url: `http://${pm.environment.get("es_host")}:${pm.environment.get("es_port")}/_cluster/health?wait_for_status=green&timeout=30s`, method: 'GET', header: { 'Authorization': pm.environment.get("auth_header") } }, function (err, response) { if (err) { console.log('Cluster health check failed:', err); pm.test("Cluster is green", function () { pm.expect.fail("Cluster health check failed: " + err); }); } else { const health = response.json(); if (health.status !== "green") { pm.test("Cluster status is green", function () { pm.expect(health.status).to.equal("green"); }); } } }); // 动态生成 auth header if (pm.environment.get("auth_method") === "basic") { const username = pm.variables.get("username") || "elastic"; const password = pm.variables.get("password") || "changeme"; const token = btoa(`${username}:${password}`); pm.request.headers.add({key: "Authorization", value: `Basic ${token}`}); }

• 这段脚本做了两件事：先发一个健康检查请求，确保集群 ready；再生成认证头。它让“创建索引”这个动作，天然具备了前置条件校验，而不是盲目执行。

Tests:

pm.test("Status code is 200", function () { pm.response.to.have.status(200); }); pm.test("Response has acknowledged", function () { var jsonData = pm.response.json(); pm.expect(jsonData.acknowledged).to.be.true; }); pm.test("Index exists after creation", function () { pm.sendRequest({ url: `http://${pm.environment.get("es_host")}:${pm.environment.get("es_port")}/{{index_name}}`, method: 'HEAD' }, function (err, response) { pm.expect(response.code).to.equal(200); }); });

• 三个断言层层递进：HTTP 状态码正确 → ES 返回acknowledged: true→ 索引确实被创建（HEAD 请求验证）。这才是真正的“端到端”验证，而不是只看 200 就算成功。

实操心得：我曾经在一个金融项目里，因为漏写了最后一个HEAD断言，导致 CI 流程里“创建索引”步骤显示成功，但实际索引因磁盘空间不足并未真正创建，后续所有写入都失败。加上这个断言后，问题在 5 秒内就被捕获。这就是 Postman Tests 的价值——它把人工肉眼确认的步骤，变成了自动化校验。

4. 实操过程与核心环节实现——从单点调试到批量运维的完整链路

4.1 单点调试：如何用 Postman 快速定位一个搜索不返回结果的问题

搜索无结果是 ES 最常见的问题，原因可能有几十种。Postman 的优势在于，你能像剥洋葱一样，一层层排除。以下是我总结的“五步定位法”，每一步都在 Postman 里有对应操作：

Step 1: 验证基础连通性

• 新建请求，MethodGET，URL{{es_host}}:{{es_port}}/。
• 发送，看返回{"name":"...","cluster_name":"...","version":{"number":"7.17.0",...}}。如果连这个都失败，问题在网络或认证，不是搜索逻辑。

Step 2: 确认索引存在且非空

• 请求GET {{es_host}}:{{es_port}}/{{index_name}}/_count。
• 如果返回{"count":0,"_shards":{"total":10,"successful":10,"skipped":0,"failed":0}}，说明索引存在但没数据。这时去03-Document-Operations里跑一个POST /index/_doc写入测试文档。

Step 3: 检查 Mapping 是否匹配

• 请求GET {{es_host}}:{{es_port}}/{{index_name}}/_mapping。
• 重点关注你要搜索的字段，比如user_id。如果 mapping 里它是text类型，而你用term查询，必然无结果（text需要用match）。Postman 的响应体高亮功能，能让你快速扫视 JSON 结构，比 curl 的纯文本快得多。

Step 4: 执行最简搜索，观察 Lucene 解析

• 请求POST {{es_host}}:{{es_port}}/{{index_name}}/_validate/query?explain=true，Body:

{ "query": { "match": { "message": "error" } } }

• 这个 API 不执行搜索，只返回 Lucene 如何解析你的 query。响应体里会有explanation字段，告诉你"message"字段被分析成了哪些 term（如["error"]），以及查询是否命中。如果看到no match，说明分析器没生效，要去检查 analyzer 配置。

Step 5: 用 Search Template 隔离业务逻辑

• 把你的复杂 query 提取出来，存为一个 Search Template：

PUT {{es_host}}:{{es_port}}/_scripts/my_search_template { "script": { "lang": "mustache", "source": { "query": { "bool": { "must": [ { "match": { "message": "{{query_string}}" } } ] } } } } }

• 然后用POST {{es_host}}:{{es_port}}/{{index_name}}/_search/template调用它。这样，你就能确定问题是出在 query 本身，还是出在业务代码拼接 query 的逻辑上。

注意：_validate/query?explain=true是神技，但很多文档没提。它能让你在不污染数据、不消耗资源的情况下，看清 ES 内部的 query 解析过程。我把它放在04-Advanced-Features的DebuggingFolder 里，命名为Validate-Query-With-Explain，新人一搜就能找到。

4.2 批量运维：用 Collection Runner 自动化索引生命周期管理

ES 的索引不是一成不变的，尤其是日志类场景，每天都要创建新索引、删除旧索引。手动操作不仅累，还容易出错。Postman 的 Collection Runner 是批量运维的利器。以下是一个真实的“日志索引滚动”自动化流程：

目标：每天凌晨 1 点，对logs-*索引执行 rollover，并更新 ILM 策略。

Collection 结构：

• 02-Index-Management→Rollover-Daily-Logs
  • 01-Check-Index-Size：GET {{es_host}}:{{es_port}}/logs-*/_stats/store?human
  • 02-Rollover-Index：POST {{es_host}}:{{es_port}}/logs-000001/_rollover
  • 03-Update-ILM-Policy：PUT {{es_host}}:{{es_port}}/_ilm/policy/logs_retention

Runner 配置：

• Select Collection:Rollover-Daily-Logs
• Environment:ES-Prod
• Iteration:1（每天只跑一次）
• Delay:0ms（顺序执行）
• Data file: 上传一个rollover_data.json文件，内容为：

[ { "index_pattern": "logs-*", "rollover_alias": "logs-current", "new_index_name": "logs-000002" } ]

Pre-request Script for02-Rollover-Index:

// 从 data file 中读取变量 const data = pm.iterationData; pm.environment.set("rollover_alias", data.rollover_alias); pm.environment.set("new_index_name", data.new_index_name); // 构建 rollover body const body = { "conditions": { "max_age": "1d", "max_docs": 10000000 } }; pm.request.body.update(JSON.stringify(body));

Tests for02-Rollover-Index:

pm.test("Rollover successful", function () { var jsonData = pm.response.json(); pm.expect(jsonData.acknowledged).to.be.true; pm.expect(jsonData.shards_acknowledged).to.be.true; }); pm.test("New index created", function () { pm.sendRequest({ url: `http://${pm.environment.get("es_host")}:${pm.environment.get("es_port")}/${pm.environment.get("new_index_name")}`, method: 'HEAD' }, function (err, response) { pm.expect(response.code).to.equal(200); }); });

运行后，Postman 会生成一份 HTML 报告，清晰列出每个请求的耗时、状态、断言结果。你可以把它集成到 Jenkins，每天凌晨自动运行，失败时邮件告警。相比写 Python 脚本，这套方案的优势在于：所有逻辑可视化、可调试、可分享。运维同事不懂代码，也能看懂报告里哪一步失败了。

4.3 权限调试：当SecurityException出现时，如何用 Postman 快速厘清角色与权限

ES Security 是另一个高频痛点。当你收到{"error":{"root_cause":[{"type":"security_exception","reason":"action [indices:admin/create] is unauthorized for user [kibana]"}]}}，Postman 能帮你快速定位是用户、角色还是权限配置的问题。

调试流程：

1. 确认用户身份：在04-Advanced-Features→SecurityFolder 下，新建GET-User-Info请求：

   • URL:{{es_host}}:{{es_port}}/_security/user/_current
   • Headers:Authorization: Basic ...
   • 这个请求返回当前用户的username、roles、full_name。如果返回 401，说明认证失败，问题在auth_header。

2. 检查角色权限：新建GET-Role-Details请求：

   • URL:{{es_host}}:{{es_port}}/_security/role/{{role_name}}
   • Body:{ "name": "kibana_user" }
   • 这里{{role_name}}从上一步的roles数组里取。响应体里会列出该角色的所有cluster和indices权限。比如，kibana_user角色通常只有monitor权限，没有create_index，所以创建索引失败是预期行为。

3. 模拟权限检查：ES 提供_xpack/security/_authenticateAPI，但更实用的是_security/privilegeAPI：

   • 新建POST-Check-Privilege请求：
   • URL:{{es_host}}:{{es_port}}/_security/privilege/_has_privileges
   • Body:

{ "username": "kibana", "application": [], "cluster": ["manage"], "index": [ { "names": ["logs-*"], "privileges": ["read", "write"] } ] }

• 这个请求会返回一个布尔值，告诉你该用户是否拥有指定权限。把cluster和index里的权限一项项试，就能 pinpoint 到底缺哪个。

实操心得：ES 的权限模型是“白名单”，即没明确授予的权限，默认禁止。很多人以为给了kibana_user角色就能干所有事，其实它只被授予了 Kibana 相关的最小权限。Postman 的这套调试流程，把抽象的 RBAC 模型，转化成了可执行、可验证的具体步骤。我建议把GET-User-Info和POST-Check-Privilege作为每个新集群上线的必跑 checklist。

5. 常见问题与排查技巧实录——那些官方文档不会告诉你的坑

5.1 经典问题速查表：高频报错与精准解法

5.2 独家避坑技巧：来自生产环境的血泪经验

技巧 1：用 Postman 的 “Generate Code” 功能反向验证 curl 命令
当后端给你一条 curl 命令，别急着复制。在 Postman 里新建请求，填好 URL、Headers、Body，然后右键 →Code→ 选择cURL (bash)。对比生成的 curl 和后端给的，往往能发现细微差异：比如后端漏写了-H "Content-Type: application/json"，或者 JSON Body 里少了个逗号。这个功能是双向的——你也可以把 Postman 调通的请求，一键生成 curl 发给运维同事，保证 100% 一致。

技巧 2：为每个 Collection 设置 “Run Options”，避免误操作
在 Collection 右侧...→Edit→Run Options。勾选Disable SSL certificate verification（仅限 dev 环境，prod 绝对禁用）；设置Request timeout为30000ms；最重要的是，勾选Stop on first failure。这样，当01-Check-Index-Size失败时，Runner 不会继续执行后面的02-Rollover-Index，防止在错误前提下执行破坏性操作。

技巧 3：用 Postman 的 “Monitors” 功能做轻量级健康巡检（免费版可用）
虽然 Monitor 功能在免费版有限制（每月 1000 次），但用来做核心接口的定时巡检绰绰有余。创建一个 Monitor，目标是GET {{es_host}}:{{es_port}}/_cat/health?v&h=status，频率设为 5 分钟。Monitor 的结果会生成一个 Dashboard，状态异常时自动发邮件。这比写个 shell 脚本 + cron + mail 命令，稳定性和可视化强太多。

技巧 4：导出为 OpenAPI 3.0，让前端/移动端直接消费
Postman 的Export→OpenAPI 3.0功能，能把整个 Collection 导出为标准 YAML。前端工程师拿到后，可以用 Swagger UI 查看，或用openapi-generator生成 Typescript SDK。这意味着，ES 的搜索接口，不再是后端写个文档丢给前端，而是前端直接基于 Postman 的真实请求，生成调用代码。我们有个项目，前端用这个生成的 SDK，一天就完成了搜索页的对接，零沟通成本。

最后分享一个小技巧：Postman 的Import功能支持直接导入 Kibana Dev Tools 的 Console 历史。打开 Kibana Console，按Ctrl+Shift+I打开开发者工具，切换到Application→Local Storage→console:history，复制 JSON 内容，粘贴到 Postman 的Import→Raw Text里。这样，你就能把 Kibana 里调试好的所有请求，一键迁移到 Postman，完美继承。这是我从一个老 ES 运维那里学来的，至今受益匪浅。