基于gorm的Go结构体如何动态调整JSON序列化输出字段？

针对你用Gorm做ORM、需要在不同接口返回同一模型不同字段的场景，目前业界主流的实现思路和方案对比如下：

最推荐的工程化方案：分层定义独立响应DTO #

这是Go Web服务开发的通用最佳实践，也就是你提到的第一种方案的规范化落地：

• 明确边界：Gorm定义的数据库模型（即你当前编写的UserAccessToken结构体）只负责数据库交互，绝对不要直接作为接口响应返回客户端。针对每个业务接口的响应需求，单独定义专属的响应结构体（DTO），从数据库读取模型数据后，手动把需要的字段映射到对应DTO再做序列化。
• 针对你的三个场景的DTO定义示例：

  // 创建令牌接口响应：需返回敏感Token字段
  type CreateAccessTokenResp struct {
      CreatedAt time.Time `json:"createdAt"`
      IpAddress string    `json:"ipAddress"`
      Token     string    `json:"token"`
  }
  
  // 普通用户令牌列表接口响应：不返回Token敏感字段
  type ListAccessTokenResp struct {
      CreatedAt time.Time `json:"createdAt"`
      IpAddress string    `json:"ipAddress"`
  }
  
  // 管理后台接口响应：返回全量需要展示的字段
  type AdminAccessTokenResp struct {
      Id        uint           `json:"id"`
      CreatedAt time.Time      `json:"createdAt"`
      DeletedAt gorm.DeletedAt `json:"deletedAt"`
      UserId    uint           `json:"userId"`
      IpAddress string         `json:"ipAddress"`
      Token     string         `json:"token"`
  }
  

这种方案的长期可维护性远高于其他实现，实际落地的好处包括：

• 有编译期类型检查，字段映射错误、漏写的问题可以在开发阶段就被发现，从机制上避免敏感字段意外泄露
• 每个接口的响应结构是完全明确的，后续生成接口文档、OpenAPI规范时可以直接从DTO定义推导，不需要维护额外的场景规则
• 没有隐式的分支判断逻辑，新人接手时可以直接从接口对应的DTO定义看清返回内容，不需要阅读结构体的场景判断逻辑

不推荐的场景实现方式 #

你提到的第二种给模型加Map(scenario)方法动态生成map的方案，并不适合长期维护的生产项目，核心问题是：

• 没有编译期类型校验，字段映射出错时编译器无法识别，很容易出现字段漏加、值匹配错的问题
• 处理列表类场景时需要额外编写批量转换的通用逻辑，一旦模型字段调整，很容易出现部分场景漏改的问题
• 序列化结果没有固定结构，后续做接口联调、文档生成的成本会远高于显式定义DTO的方案

小项目可选的补充简化方案 #

如果是内部小工具项目，不想写重复的DTO字段映射逻辑，可以临时使用以下方案，但不适合复杂业务的长期维护：

• 基于反射的动态序列化库：在标准JSON序列化的基础上，支持根据请求场景动态过滤需要输出的字段，减少重复的结构体定义。但这种方案会引入额外依赖，序列化性能低于标准库，而且没有明确的字段边界，存在敏感字段泄露的风险
• 自定义MarshalJSON方法：给模型实现自定义的JSON序列化逻辑，结合请求上下文判断要输出的字段。但这种方式会把序列化逻辑和业务逻辑耦合，后续新增场景时需要不断在方法里加分支判断，很容易演变成难维护的面条代码

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