为何查询字符串未纳入Web框架的URI路由机制？

• 路由设计的核心定位：分层路径才是资源的核心标识
  路由系统的核心职责是快速匹配资源的分层路径，比如/people/{id}明确指向某一个具体人员资源，路径结构具有唯一性和确定性。而查询字符串本质是对资源的过滤、修饰参数——/people?search=xxx指向的依然是「人员列表」这个核心资源，只是返回结果的范围不同。框架将路由匹配聚焦在路径上，是为了保证匹配逻辑的简洁高效，避免不必要的复杂度。

• 查询字符串的特性导致匹配逻辑复杂度飙升
  查询字符串本身是无序的（?a=1&b=2和?b=2&a=1语义完全相同），还支持多值参数（?tag=php&tag=laravel）。如果把查询字符串纳入路由规则，框架需要处理参数顺序无关性、多值解析、部分参数缺失等各种边缘场景，这会大幅增加路由匹配的性能开销，也会让路由规则变得极其繁琐，违背了路由系统「简洁、快速」的设计初衷。

• 现有模式的灵活性完全覆盖需求
  当前的处理方式（先匹配路径，再在控制器/中间件中处理查询参数）已经足够灵活：你可以在中间件里统一做参数校验、过滤，也可以通过框架的请求对象快速获取参数。如果强行将查询字符串写入路由，反而会陷入规则冗余的困境——比如同一个/people路径下要支持?search=xxx、?sort=xxx、?page=xxx等多种参数组合，就得写大量重复的路由规则，维护成本极高。

• 行业约定与生态兼容性的约束
  主流框架的路由设计普遍遵循RESTful规范，而REST中资源标识主要依赖路径，查询参数用于分页、过滤等辅助操作。这种设计已经成为行业共识，框架开发者不会轻易打破这个约定——否则会增加开发者的学习成本，还会导致现有生态中的插件、工具无法兼容。

另外需要说明的是，RFC6570定义的包含查询字符串的URI模板，更多是用于客户端生成请求，而非服务端的路由匹配。服务端路由需要的是可预测、易匹配的规则，而不是通用的URI生成模板。

内容的提问来源于stack exchange，提问作者inf3rno