一个页面只显示几列，接口却返回完整实体和关联对象，数据库、应用序列化和网络都会承担额外工作。响应压缩可以减少部分传输量，但不能替代对查询与接口契约的整理。
从页面真正需要的数据开始
记录字段使用情况、集合规模和典型请求参数。对列表与详情使用不同返回模型，避免列表一次加载所有明细。删除字段前需要确认消费者，不能只看当前前端代码就判断没有使用方。
查询层也只取必要内容
如果数据库已经读取大量无用列，再在内存里删除字段，仍然承担了读取和传输开销。应结合 ORM 实际生成 SQL 检查投影、关联与分页。对重复查询和循环加载也要单独核实。
不把多个业务需求硬塞进一个接口
通用接口不断增加可选字段和关联开关，可能使查询成本难以预测。可以按稳定的使用场景建立契约，同时控制扩展范围。是否拆接口，应结合调用次数和客户端体验比较。
验收总成本与兼容性
对相同数据范围比较响应字节、查询行数、耗时和内存，并运行已有消费者的关键流程。压缩作为后续措施时，还要评估 CPU 与内容类型，不能只观察下载大小。
常见问题：DTO 会不会增加维护工作？
会增加明确的契约维护，但也减少内部实体变化直接影响外部接口的风险，应按边界和复杂度选择。
技术参考：微软：EF Core 高效查询。具体接口与配置请结合使用版本核对。
将评估落实到你的系统
如果你的团队正遇到类似问题，可以从一条关键业务路径开始，整理现状、证据与约束，通过系统架构诊断明确优先级、候选方案和验证范围。