Pact的设计哲学：契约优先，模拟先行
pact的核心理念是基于消费者驱动的契约（consumer-driven contracts）。这意味着消费者定义他们对提供者api的期望，然后提供者根据这些契约进行验证。在此过程中，pact通过在消费者端启动一个模拟提供者（mock provider）来拦截消费者发出的请求，并根据预设的契约响应数据。这种机制确保了消费者测试的隔离性和确定性，使其更接近单元测试的范畴。
尝试让Pact消费者测试直接调用实时提供者服务（如开发环境或生产环境）是与Pact的设计哲学相悖的，并且通常会导致测试失败，如问题中所示的PactMismatchesException。Pact期望它所启动的Mock Provider能够接收到消费者发出的请求，如果消费者将请求发送到外部的实时服务，Pact的Mock Provider将不会收到任何请求，从而报告未接收到预期请求的错误。
为什么Pact不直接与实时服务交互？
缺乏对消费者实际使用接口的可见性： 如果消费者测试直接调用实时服务并记录交互（即所谓的“录制/回放”模式），我们将无法得知消费者实际使用了响应中的哪些字段。对于提供者而言，这意味着他们必须假设API响应中的所有字段对消费者都是重要的。 例如，如果一个API返回了10个字段，而消费者实际上只使用了其中3个，但提供者无从得知。当提供者想要修改或删除某个字段时，他们会认为所有字段都是关键的，从而可能导致不必要的API版本升级，或者需要与所有消费者进行沟通，即使这些修改并未影响到任何实际使用的功能。
促进API的独立演进： Pact通过明确定义消费者所依赖的API部分，解决了上述问题。提供者可以清楚地知道消费者实际使用了哪些字段。这样，如果提供者需要修改或删除消费者当前未使用的字段，他们可以安全地进行操作，而无需担心破坏现有消费者或发布新的API版本。这极大地提升了提供者团队的开发效率和API演进的灵活性。
测试的确定性与效率： Pact旨在作为一种轻量级的单元/集成测试工具。直接调用实时服务会引入大量不确定性：网络延迟、服务可用性、数据状态等都可能导致测试结果不稳定。Pact通过使用Mock Provider，确保了测试环境的隔离和可控性，每次运行都能得到一致的结果，从而提高了测试的可靠性和执行效率。它使得测试更加专注于契约本身的验证，而非端到端的系统行为。
总结
Pact的核心价值在于它提供了一种机制，使得消费者和提供者能够就API的“契约”达成一致，并独立地验证这些契约。它不是为了替代传统的集成测试或端到端测试，而是作为一种补充，在服务边界上提供快速、可靠的反馈。因此，理解Pact的设计意图，即通过模拟服务而非直接调用实时服务来生成和验证契约，是有效利用Pact进行微服务测试的关键。
