本文探讨了在 go 语言中处理 json 数据时，如何实现特定 结构体 字段只进行反序列化（读取）而不进行序列化（写入）的需求。通过采用结构体分离的策略，将完整数据模型与对外暴露的数据模型区分开来，可以优雅地解决 json:”-“ 标签无法满足的场景，从而有效管理 敏感数据 或优化 api 响应。
在 go 语言的 Web 服务开发中，我们经常需要将结构体（Struct）与 jsON 数据进行相互转换。有时，我们会遇到这样的需求：某个字段（例如用户密码的哈希值 PasswordHash）在从json 反序列化（Unmarshal）时需要被读取以完成内部逻辑，但在序列化（Marshal）为 JSON 响应时，出于安全或隐私考虑，该字段不应被写入。
传统 JSON 标签的局限性
Go 语言 的 encoding/json 包提供了强大的 JSON 标签（json:”fieldName”）来控制字段的序列化和反序列化行为。其中，json:”-“ 标签常用于忽略某个字段，使其在 JSON 转换过程中完全不参与。
考虑以下 User 结构体：
type User struct {UserName string // 必须唯一 Projects []string // 用户有权访问的项目集合 PasswordHash string `json:"-"` // 用户密码的哈希值，标记为不序列化 IsAdmin bool // 用户是否为管理员 }如果我们将 PasswordHash 字段标记为 json:”-“，它确实会在序列化时被忽略。然而，问题在于这个标签也会导致该字段在反序列化时被忽略。这意味着，如果我们从外部 JSON 数据中读取一个包含 PasswordHash 的 User对象，PasswordHash 字段将无法被正确解析到结构体中，这与我们“只读不写”的需求相悖。
立即学习“go 语言免费学习笔记（深入）”；
示例反序列化代码：
import "encoding/json" // …… 假设 content 是包含 PasswordHash 的 JSON 字节 切片 var user User err := json.Unmarshal(content, &user) // 此时，如果 PasswordHash 字段带有 `json:"-"`，它将不会被 unmarshal 到 user.PasswordHash示例序列化代码：
import ("bytes" "encoding/json") // …… 假设 user 已经被填充 userBytes, _ := json.Marshal(user) var respBuffer bytes.Buffer json.Indent(&respBuffer, userBytes, "", " ") // respBuffer 现在包含序列化后的 user 数据，PasswordHash 字段会被忽略显然，json:”-“ 标签无法满足我们对字段进行选择性读写的需求。
解决方案：结构体分离策略
为了实现 JSON 字段的只读不写，一种简洁且推荐的策略是根据不同的数据上下文（内部完整模型 vs. 外部 API 响应模型）定义不同的结构体。这种方法将语义上不同的对象在代码中也进行分离，从而清晰地管理数据的输入和输出视图。
具体实现步骤如下：
- 定义外部可见结构体（UserInfo）：这个结构体只包含那些可以被序列化（写入）到 JSON 响应中的字段。
- 定义内部完整结构体（User）：这个结构体包含所有字段，包括那些只用于内部处理（如 PasswordHash）的字段。通过内嵌（embedding）外部可见结构体，可以重用字段定义。
修改后的结构体定义如下：
type UserInfo struct {UserName string // 必须唯一 Projects []string // 用户有权访问的项目集合 IsAdmin bool // 用户是否为管理员 } type User struct {UserInfo // 内嵌 UserInfo，包含所有对外可见字段 // A hash of the password for this user PasswordHash string // 密码哈希，此字段不带 json 标签，默认参与读写}现在，UserInfo 代表了用户信息的公共部分，而 User 则包含了所有内部管理所需的字段，包括敏感的 PasswordHash。
实现选择性读写
有了这两个结构体，我们可以轻松实现字段的选择性读写：
反序列化（读取）
当从外部 JSON 数据读取用户对象时，我们使用完整的 User 结构体进行反序列化。由于 PasswordHash 字段在 User 结构体中没有 json:”-“ 标签，它将正常参与反序列化过程。
import "encoding/json" // 假设 content 是包含所有字段（包括 PasswordHash）的 JSON 字节切片 var user User content := []byte(`{"UserName":"alice","Projects":["proj1","proj2"],"PasswordHash":"$2a$10$xyz","IsAdmin":true}`) err := json.Unmarshal(content, &user) if err != nil {// 处理错误 panic(err) } // 此时，user.UserName, user.Projects, user.IsAdmin, 和 user.PasswordHash 都已被正确填充 fmt.Printf("Deserialized User: %+vn", user) // Output: Deserialized User: {UserInfo:{UserName:alice Projects:[proj1 proj2] IsAdmin:true} PasswordHash:$2a$10$xyz}序列化（写入）
当需要将用户对象序列化为 JSON 响应时，我们只序列化 User 结构体中的 UserInfo 部分。这样，PasswordHash 字段就会被自然地排除在外。
import ("bytes" "encoding/json" "fmt") // 假设 user 已经被填充，例如从数据库加载或刚刚反序列化 user := User{UserInfo: UserInfo{ UserName: "alice", Projects: []string{"proj1", "proj2"}, IsAdmin: true, }, PasswordHash: "$2a$10$xyz", // 内部字段 } // 序列化时，只使用 user.UserInfo userBytes, err := json.Marshal(user.UserInfo) if err != nil {// 处理错误 panic(err) } var respBuffer bytes.Buffer json.Indent(&respBuffer, userBytes, "", " ") fmt.Println("Serialized UserInfo for response:") fmt.Println(respBuffer.String()) // Output: // Serialized UserInfo for response: // {// "UserName": "alice", // "Projects": [ // "proj1", // "proj2" //], // "IsAdmin": true // }通过这种方式，我们成功实现了 PasswordHash 字段在反序列化时被读取，而在序列化时被忽略的目的。
优点与注意事项
- 清晰的职责分离 ：UserInfo 明确表示对外暴露的数据视图，User 则表示内部完整的数据模型， 代码可读性 和可维护性更高。
- 灵活性：如果需要不同的 API 响应视图（例如，管理员视图包含更多信息，普通用户视图包含较少信息），可以轻松创建更多的 UserView 结构体。
- 避免冗余：通过结构体内嵌，UserInfo 的字段定义无需在 User 中重复。
- 类型安全 ：编译时检查确保了正确的 数据结构 被使用。
注意事项 ：虽然结构体分离是解决此问题的优雅方法，但在某些复杂场景下，例如字段选择性非常动态，或者需要对序列化 / 反序列化过程进行更精细的控制时，可能需要考虑实现 json.Marshaler 和 json.Unmarshaler 接口 来自定义 JSON 转换逻辑。然而，对于本文提出的“只读不写”特定需求，结构体分离通常是更简单、更易于理解和维护的方案。
总结
在 Go 语言中，当遇到 JSON 字段需要只进行反序列化而不进行序列化的场景时，直接使用 json:”-“ 标签是无效的。通过定义不同的结构体来代表数据的不同视图（内部完整模型和外部暴露模型），我们可以有效地管理数据流，确保敏感信息不会被意外序列化，同时保持反序列化功能的完整性。这种结构体分离的策略不仅解决了技术问题，也提升了代码的清晰度和可维护性。
