在 Postman 集合 Runner 中避免服务器压力过大的核心方法是设置请求间隔延迟（Delay）并限制迭代次数，不要将 Postman 当作专业压测工具使用。适用场景为接口功能回归或轻量级负载检查，风险边界在于高并发场景下 Postman 客户端自身可能成为瓶颈且结果不准确。
先说结论：Postman 集合 Runner 默认按顺序发送请求，避免服务器压力的关键是主动配置延迟和控制迭代规模，而非追求高并发。
- 先定位：确认测试目的是功能验证还是负载测试，Postman 适合前者。
- 先做：在 Runner 设置中填写 Delay 毫秒数，降低请求频率。
- 再验证：观察服务器 CPU、内存及接口响应时间，确认无异常波动。
快速处理思路
Postman 集合 Runner 界面提供基础的频率控制选项，无需编写复杂脚本即可限制请求速度。适合个人开发者或测试人员在本地环境进行接口批量验证，不适合模拟大规模用户并发。
1. 打开 Collection Runner 界面。
2. 在 Delay 输入框中填入请求间隔毫秒数，例如 1000 代表 1 秒。
3. 在 Iterations 输入框中限制运行次数，避免无限循环。
4. 点击 Run 开始执行，期间观察本地网络占用情况。
为什么会这样
Postman 集合 Runner 默认以最快速度连续发送请求，缺乏内置的并发 throttling 机制。如果不手动设置延迟，短时间内大量请求会触发服务器的速率限制（Rate Limiting）或导致资源耗尽。
Postman 定位是 API 开发协作工具，而非专业负载测试工具如 JMeter 或 k6。其架构设计侧重于请求调试和自动化流程，而非高并发流量生成。公开资料中没有看到可靠的量化数据表明 Postman 能安全支撑的具体 QPS 上限，因此需谨慎控制频率。
分步处理
第一步：配置运行延迟。在 Postman 主界面点击 Runner 按钮，选择目标集合，在设置面板找到 Delay 输入框，填入大于 0 的数值，建议从 1000ms 起步。
第二步：限制迭代次数。在 Iterations 输入框填入具体数字，避免使用默认的大数值或无限循环，根据测试用例数量决定。
第三步：使用 Newman 命令行控制。若需自动化执行，安装 Newman 后使用-d 参数设置延迟，命令示例newman run collection.json -d 1000。
第四步：监控服务器状态。在执行期间，登录服务器查看系统负载命令如top或htop，确认 CPU 使用率未持续满载。
怎么验证是否生效
检查服务器应用日志，确认没有出现大量的 429 Too Many Requests 或 503 Service Unavailable 错误码。观察 Postman 运行结果面板，确认平均响应时间（Average Response Time）保持在正常业务范围内，未出现因超时导致的失败。
若使用 Newman，可查看命令行输出的失败统计，失败率应为 0% 或在可接受误差内。服务器监控图表中，请求速率曲线应平稳，无尖锐峰值。
常见坑
1. 误将 Postman 当作压测工具。试图通过开启多个 Runner 窗口模拟并发，这会导致本地资源耗尽且结果不可信。
2. 忽略网络延迟。本地设置的 Delay 是发送间隔，不包含网络传输时间，总频率可能仍高于预期。
3. 未处理认证令牌刷新。高频请求可能导致 Token 频繁失效，引发大量 401 错误，增加服务器验证负担。
常见问题
Postman Runner 能代替 JMeter 做压测吗
不能。Postman 缺乏专业的并发线程管理和资源调度机制，适合功能自动化，不适合高负载压力测试。
如何设置 Postman 请求之间的延迟
在 Collection Runner 设置面板的 Delay 输入框中填入毫秒数，或在 Newman 命令中使用-d 参数指定。
服务器出现 429 错误怎么处理
立即停止运行，增大 Runner 中的 Delay 数值，或联系服务端调整速率限制策略。
参考来源
1. Postman Learning Center, "Intro to collection runs", https://learning.postman.com/docs/running-collections/intro-to-collection-runs/
2. Newman GitHub Repository, "Command Line Options", https://github.com/postmanlabs/newman