DTO只是一个代码规范的设计，无需过度执着于DTO。在小型项目中，很多情况没有必要使用DTO返回数据，直接用map也完全可以。

减少多余的参数，出于安全性、节约流量的考虑。
例如：密码，出于安全性考虑不返回前端；获取博客列表的时候，不返回博客全文，而是返回标题，id，和前几句。

编译时进行强制检查，规范参数类型。
如果从返回的HashMap中提取某个内容时，无法校验数据类型是否是想要的类型。
例如：前端某个字段要求整数，后端直接传了个浮点回去，前端逻辑处理及显示就会出现问题；在用DTO时，如果直接把不符合要求的类型放进去，后端就会报错。

在DTO类里可以直接写注释，便于别人阅读，知道有哪些参数。后续可以直接生成接口文档
例如：在项目的第一阶段，你得到一个用户对象，只使用“getUsername（）”方法。然后，在第2阶段，突然需要访问password属性。如果你有一个用户对象，你就知道这个值是否可以访问，以及如何通过查看类来获得它；对于HashMap，将不知道还有哪些其他数据属性可用。

易于重构。在删除修改对象属性时，有多个地方用到了这个属性，如果是DTO，通过IDE就可以找到修改点，编译也会进行检查；如果使用map，查找使用的地方难度较大，存在遗漏风险。