当你的 API 请求中携带生产环境的 Token、用户手机号或内部服务地址时，Postman 的每一次同步都可能成为数据泄露的入口。这篇教程不讲基础的发送请求，而是从安全与隐私的视角，拆解 Postman 在企业环境中应该如何配置、如何管控、如何善后。

环境变量分层：把敏感凭证隔离在本地

Postman 的环境变量分为 Initial Value 和 Current Value 两层。Initial Value 会随 Collection 同步到 Postman 云端和团队工作区，而 Current Value 仅存储在本地，不参与同步。很多开发者习惯直接在 Initial Value 中填入 API Key 或 OAuth Token，这意味着凭证会被上传到 Postman 服务器并对工作区成员可见。正确做法是：将所有敏感字段的 Initial Value 留空或填入占位符（如 {{REPLACE_ME}}），仅在 Current Value 中填写真实值。在 Postman v11.2 之后的版本中，你可以在 Settings → General → Request 中开启 Automatically persist variable values 的关闭状态来强制这一行为。对于团队管理员，建议通过 Workspace 级别的 Variable 权限设置，将 Secret 类型变量的可见性限制为 Workspace Admin 角色。

实战排查：请求头中的 Authorization 泄露到 Postman History

一个真实的高频问题：开发者在调试 OAuth 2.0 接口时，将 Bearer Token 直接硬编码在 Headers 的 Authorization 字段中。调试完成后虽然关闭了 Tab，但该请求已被记录在左侧 History 面板中，包含完整的请求头和请求体。如果此时 Postman 账号处于登录状态且开启了云同步，这条 History 记录会被同步到云端。排查步骤如下：打开 History 面板，逐条检查是否包含敏感信息；对于已同步的记录，右键选择 Delete 后还需确认云端是否已清除——可通过 Web 端 app.getpostman.com 登录同一账号核实。根本性的防护措施是在 Settings → General 中关闭 History 的自动保存，或者在调试涉及生产凭证的接口时切换到 Scratch Pad 模式（离线模式），该模式下所有数据仅存储在本地文件系统中。

使用 Pre-request Script 自动脱敏请求日志

在团队协作中，共享 Collection 时往往需要保留请求示例以便他人理解接口用法，但示例中的真实数据又构成隐私风险。Postman 的 Pre-request Script 和 Tests 脚本提供了一个折中方案：在请求发送前通过脚本动态注入敏感参数，而 Collection 本身只保存脱敏后的模板。例如，在 Pre-request Script 中编写 pm.environment.set('phone', pm.variables.get('real_phone'))，将真实手机号从仅存于本地的 Current Value 注入到请求参数中，而 Collection 中的示例值始终显示为 138****0000 这样的脱敏格式。Tests 脚本中也可以对响应体进行正则替换后再写入 pm.visualizer，避免在 Postman Console 中留下明文 PII。这种方式既保证了团队成员能看懂接口结构，又将敏感数据的暴露面控制在操作者本机。

团队工作区的权限模型与账号生命周期管理

Postman 的 Team Workspace 提供 Admin、Editor、Viewer 三种角色。在安全合规场景下，建议遵循最小权限原则：仅项目负责人持有 Admin 权限，一线开发者使用 Editor，外部审计或合作方使用 Viewer。当团队成员离职或转岗时，管理员需要在 Team Settings → Members 中及时移除其账号。但容易被忽略的是：该成员在离开前可能已将 Collection 导出为 JSON 文件或 Fork 到个人工作区。因此，除了移除账号，还应同步轮换该成员曾接触过的所有 API Key 和 Token。对于使用 Postman Enterprise 方案的团队，可以通过 SCIM 协议对接企业 IdP（如 Okta、Azure AD），实现账号的自动化供给与回收，将人工遗漏的风险降到最低。此外，建议每季度导出一次 Workspace 的 Activity Log 进行审计复核。

本地数据清理：卸载前你需要处理的残留文件

Postman 桌面端在本地存储了大量运行时数据，即使你在应用内删除了 Collection 和 Environment，本地磁盘上仍可能残留缓存。在 macOS 上，Postman 的数据目录位于 ~/Library/Application Support/Postman；在 Windows 上则是 %AppData%/Postman。这些目录中包含 IndexedDB 数据库文件、日志文件以及可能含有请求响应内容的缓存。如果你的调试过程涉及用户个人信息（如姓名、身份证号、手机号等 PII 数据），在卸载 Postman 或更换设备前，务必手动删除上述目录。一个实际案例：某团队在归还测试用笔记本电脑时未清理 Postman 本地数据，后续使用者通过恢复 IndexedDB 文件还原出了包含客户手机号的接口响应记录。建议将 Postman 本地数据清理纳入设备回收的标准操作流程（SOP），并在清理后使用文件粉碎工具覆写磁盘扇区以防止数据恢复。

常见问题

Postman 的 Scratch Pad 模式和登录模式在数据存储上有哪些具体差异？

Scratch Pad 模式下，所有 Collection、Environment、History 和 Cookie 数据仅保存在本地磁盘，不与 Postman 云端发生任何同步。登录模式下，默认开启云同步，你的请求记录、环境变量的 Initial Value、Collection 内容都会上传到 Postman 服务器。如果你的工作涉及内部接口或生产环境凭证，建议在 Scratch Pad 模式下操作，调试完成后手动导出需要保留的 Collection 并存储在企业内部代码仓库中。

团队中有人误将包含生产 Token 的 Collection 发布到了 Public Workspace，应该如何应急处理？

第一步：立即将该 Collection 从 Public Workspace 移除或将 Workspace 可见性改为 Private，操作路径为 Workspace Settings → Visibility。第二步：在对应的服务端（如 AWS IAM、GitHub、支付网关后台）立即轮换或吊销已暴露的 Token 与 API Key。第三步：检查 Postman 的 Public API Network 页面，确认该 Collection 是否已被他人 Fork；如果已被 Fork，你无法直接删除他人的副本，需联系 Postman 支持团队协助处理。第四步：在团队内部进行事件复盘，将 Public Workspace 的发布权限收归 Admin 角色。

如何验证 Postman 是否真的删除了云端已同步的敏感请求记录？

在桌面端删除 History 条目后，登录 Web 端（go.postman.co）查看同一 Workspace 的 History 是否仍存在该记录。如果仍然可见，说明云端删除存在延迟，通常需要等待数分钟后刷新。对于 Enterprise 用户，可以通过 Postman API（GET /me 接口验证身份后调用 Workspace 相关端点）查询云端数据状态。如果你对云端数据的彻底删除有合规级别的要求（如 GDPR 下的数据删除权），需要通过 Postman 官方的 Data Deletion Request 流程提交工单，Postman 会在 30 天内完成处理并提供确认函。

总结

下载 Postman 最新桌面端（https://www.postman.com/downloads/），按照本教程完成安全基线配置后再开始你的 API 调试工作。如需进一步了解企业级安全功能与 SSO 集成方案，可访问 Postman 官方文档的 Security 板块获取详细指引。

相关阅读：Postman使用教程，Postman使用教程使用技巧，Postman快捷键大全：安全合规场景下提升AP