Go+PostgreSQL开发REST API 无ORM场景下如何优化查询返回数据结构

问题1：返回嵌套零值是否符合预期 #

是符合预期的，核心原因是Go JSON序列化的omitempty标签对值类型结构体无效：
你定义的Task结构体中，Id_Project是Project值类型、CreatedAt/UpdatedAt是time.Time值类型，这类值类型在初始化时会自动赋对应结构的零值，即使所有内部字段都是零值，omitempty也不会判定它为“空”，所以序列化时会完整输出所有嵌套字段的零值。

问题2：除了匿名结构体，还有哪些可行的方案组织返回数据 #

匿名结构体不是唯一方案，以下几个都是Go生态中常用的生产级方案，你可以根据场景选择：

方案1：修改模型字段为指针类型

把需要按需返回的关联字段、可选字段改为指针类型，未赋值时为nil，omitempty会自动忽略该字段：

type Task struct {
    Id_Task         int64      `json:"id_task,omitempty"`
    Name            string     `json:"name,omitempty"`
    State           bool       `json:"state,omitempty"`
    Id_Project      *Project   `json:"id_project,omitempty"` // 改为指针
    CreatedAt       *time.Time `json:"created_at,omitempty"` // 改为指针
    UpdatedAt       *time.Time `json:"updated_at,omitempty"` // 改为指针
}

这个方案改动最小，不需要调整现有查询逻辑，就能直接过滤掉未赋值的嵌套字段。

方案2：定义独立的接口响应DTO

专门为每个接口定义只包含所需字段的DTO（数据传输对象）结构体，和数据库模型层完全解耦：

// 仅用于ListTask接口返回的DTO
type TaskListResp struct {
    Id_Task int64  `json:"id_task"`
    Name    string `json:"name"`
    State   bool   `json:"state"`
}

查询时直接把数据库返回的字段扫描到DTO实例中再序列化，后续接口字段调整完全不会影响底层的数据库模型定义，适合中大型项目、接口迭代频繁的场景。

方案3：自定义JSON序列化逻辑

给Task结构体实现MarshalJSON方法，手动控制需要序列化的字段，适合不想修改原有结构体定义、需要灵活控制输出的场景：

func (t Task) MarshalJSON() ([]byte, error) {
    // 只序列化你需要的字段
    return json.Marshal(map[string]interface{}{
        "id_task": t.Id_Task,
        "name":    t.Name,
        "state":   t.State,
    })
}

不推荐方案：用map[string]interface{}接收数据

虽然可以直接把扫描结果存入map再序列化，但没有类型校验，需要额外处理类型转换，性能也远低于结构体方案，仅适合非常灵活的动态查询场景。

额外代码优化提示 #

你当前代码中循环复用同一个task指针再拷贝值的写法当前是生效的，但更稳妥的写法是在for rows.Next()循环内部每次新建Task实例，避免后续修改逻辑时出现指针复用的隐藏bug。

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