场景描述

我们的系统基于基于休息的微服务架构。 对各个子系统的调用通过HTTP请求进行交互，请求参数必须进行编码。

前端在做数据迁移请求的时候，发现总是莫名其妙的丢失一些数据。 最初，迁移是基于数据的自动递增ID段来完成的，一次一部分。 迁移过程中会到另一个系统调用一个服务来确认数据是否属于要迁移的范围。

迁移过程中发现数据丢失后，我们搜索日志，发现了Bad错误。 定位后发现是调用数据有效性确认的服务出现问题。 起初我们的段长度是1000，出现这个问题后，我们查看这个服务的详细信息，发现它处理的请求类型是GET，也就是说它的请求数据和地址长度受到URL长度的限制WEB 服务器。 我们的 URL 长度太长导致了这个问题。 因为这个GET问题，我们迎来了质检。

由此我们也可以意识到，当我们对问题进行抽象时，不可避免地会隐藏一些底层的细节。 例如，当我们通过TSP服务名称来识别服务时，我们就失去了对请求类型的理解。 直接感知。 所以，工作中还是要多想、多看、三思而后行，否则回头看会浪费更多的时间。

现在收集了一些有关 URL 长度的信息：

在HTTP协议中，实际上对于URL的长度是没有限制的。 URL的最大长度往往与用户的浏览器和Web服务器有关。 不同的浏览器通常有不同的最大可接受长度。 当然，它们是不同的。 Web 服务器处理 URL 最大长度的能力也各不相同。

下面是对各种浏览器和服务器的最大处理能力的一些解释。