Spring GET请求使用PageDTO作为分页参数是否存在弊端？

一、用PageDTO封装分页参数的潜在问题 #

• GET请求语义不匹配：GET请求的参数本就该是URL上扁平的键值对，用DTO封装虽然Spring能自动映射，但不符合GET请求“参数透明、直观”的常规用法。前端或跨语言调用方得额外去查DTO的结构才能传参，平白增加沟通成本。
• 校验与复用的矛盾：给DTO加校验注解后，要是某个接口只需要部分分页参数（比如只限制size），要么冗余校验，要么得拆DTO，反而不如直接在@RequestParam上标注校验规则灵活。而且分页参数的默认值写在DTO字段里，接口文档（比如Swagger）没法直接展示，调用方可能不知道有默认值，得额外说明。
• 排障难度更高：参数绑定出错时，用DTO得排查字段映射、类实例化的整个流程；单独用@RequestParam的话，直接看URL参数和方法参数的对应关系，一眼就能定位问题。

二、公司要求改用单独@RequestParam的核心原因 #

• 贴合RESTful设计：REST风格的GET查询接口，每个参数都对应明确的查询维度，分页参数（size、current）本身就是独立的查询条件，没必要强行封装成对象，保持扁平结构更符合规范。
• 提升团队协作效率：其他开发者看接口方法签名就能直接知道要传哪些参数，不用去翻DTO的内部结构，降低了理解成本。团队统一用这种风格，能减少认知差异，避免因为不同封装方式产生的沟通问题。
• 避免过度封装的冗余：看似通用的分页参数，不同业务场景可能有细微差别——比如有的接口用pageNum代替current，有的对size的最大值限制不同。用DTO封装很容易为了兼容多场景加冗余字段或逻辑，反而不如单独参数灵活可控。

三、网上大量DTO封装案例的本质 #

网上很多这类实现，核心是为了快速减少重复代码——多个接口都要分页参数，封装成DTO能少写几次参数。但这种复用是短期省事，长期来看，团队规模越大、接口越复杂，前面说的那些弊端就越突出，反而会增加维护成本。

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