本文探讨了在go语言中如何实现json字段的“只读不写”需求，即某个字段在反序列化时可以被读取，但在序列化时不被输出。针对go标准库`encoding/json`的标签限制，文章提出并详细阐述了通过结构体分离的策略来解决此问题，并提供了完整的代码示例和最佳实践建议，以确保数据安全和代码清晰。
引言：jsON数据处理中的选择性可见性
在现代Web服务和数据交换中，json作为一种轻量级的数据格式被广泛应用。Go语言的encoding/json包提供了强大而灵活的JSON序列化（Marshal）和反序列化（Unmarshal）能力。然而，在实际开发中，我们经常遇到一种特殊需求：某些结构体字段，例如用户的密码哈希、内部审计信息等，需要在从JSON数据中读取（反序列化）时被填充，但在将结构体序列化为JSON响应时，为了安全或业务需求，这些字段必须被忽略，即实现“只读不写”的特性。
Go语言JSON标签的限制
Go语言的encoding/json包允许开发者通过结构体字段标签来控制JSON的序列化和反序列化行为。例如，json:”fieldName”可以指定JSON字段名，json:”-“则表示该字段在序列化和反序列化时都将被忽略。
考虑以下示例结构体：
type User struct { UserName string `json:"userName"` Projects []string `json:"projects"` PasswordHash string `json:"-"` // 希望只在序列化时忽略 IsAdmin bool `json:"isAdmin"` }
在这里，如果我们将PasswordHash字段标记为json:”-“，它确实会在序列化时被忽略。然而，问题在于，当尝试从包含passwordHash的JSON数据反序列化到User结构体时，这个字段也会因为json:”-“标签而被跳过，无法被读取。这与我们“只读不写”的需求相悖。Go语言标准库的JSON标签机制目前无法直接提供这种细粒度的控制，即区分序列化和反序列化时的可见性。
立即学习“go语言免费学习笔记（深入）”；
核心策略：结构体分离
鉴于Go语言JSON标签的局限性，解决“只读不写”需求的最有效且推荐的策略是——结构体分离。这意味着为不同的操作（内部数据模型与外部API模型）设计不同的结构体。
具体来说，我们可以定义两个或更多结构体：
- 内部数据模型结构体（例如 User）：包含所有字段，包括那些敏感的、只用于内部处理或需要从输入中读取的字段。这个结构体用于反序列化输入数据，并在应用程序内部进行数据操作。
- 外部API模型结构体（例如 UserInfo）：只包含那些需要暴露给外部的字段。这个结构体用于序列化输出数据。通常，它可以通过嵌入（embedding）或手动映射的方式从内部数据模型结构体派生。
让我们根据上述原则重构User结构体：
package main import ( "bytes" "encoding/json" "fmt" ) // UserInfo 结构体：用于外部API响应，不包含敏感信息 type UserInfo struct { UserName string `json:"userName"` Projects []string `json:"projects"` IsAdmin bool `json:"isAdmin"` } // User 结构体：用于内部数据处理和反序列化，包含所有字段 type User struct { UserInfo // 嵌入UserInfo，包含公共字段 PasswordHash string `json:"passwordHash"` // 敏感字段，在反序列化时需要读取 }
在这个设计中：
Easily find JSON paths within JSON objects using our intuitive Json Path Finder
30 
- UserInfo结构体定义了所有对外可见的字段。
- User结构体通过嵌入UserInfo来继承所有公共字段，并额外添加了PasswordHash字段，这个字段在User结构体中没有json:”-“标签，因此在反序列化时可以正常读取。
实现细节与代码示例
现在，我们来看如何使用这些结构体进行反序列化和序列化操作，以实现“只读不写”的特性。
1. 反序列化（读取）
当从外部JSON数据读取时，我们应该将其反序列化到包含所有字段的User结构体中。
func main() { // 模拟接收到的包含密码哈希的JSON数据 jsonData := `{ "userName": "john.doe", "projects": ["proj1", "proj2"], "passwordHash": "supersecretpasswordhash", "isAdmin": true }` var user User err := json.Unmarshal([]byte(jsonData), &user) if err != nil { fmt.Println("Error unmarshaling:", err) return } fmt.Println("--- 反序列化结果 ---") fmt.Printf("反序列化后的User对象: %+vn", user) fmt.Printf("用户名: %sn", user.UserName) fmt.Printf("密码哈希: %sn", user.PasswordHash) // 密码哈希被成功读取 fmt.Printf("是否管理员: %tn", user.IsAdmin) // 预期输出： // 反序列化后的User对象: {UserInfo:{UserName:john.doe Projects:[proj1 proj2] IsAdmin:true} PasswordHash:supersecretpasswordhash} // 用户名: john.doe // 密码哈希: supersecretpasswordhash // 是否管理员: true
从输出可以看出，PasswordHash字段被成功地从JSON数据中读取并填充到user对象的PasswordHash字段中。
2. 序列化（写入）
当需要将数据序列化为JSON响应时，我们只对User结构体中对外可见的部分（即UserInfo嵌入字段）进行操作。
fmt.Println("n--- 序列化结果 ---") // 序列化时，只对 user.UserInfo 部分进行操作 userBytes, err := json.Marshal(user.UserInfo) if err != nil { fmt.Println("Error marshaling:", err) return } // 为了美观，进行缩进 var respBuffer bytes.Buffer json.Indent(&respBuffer, userBytes, "", " ") fmt.Printf("序列化后的UserInfo JSON: %sn", respBuffer.String()) // 预期输出： // 序列化后的UserInfo JSON: { // "userName": "john.doe", // "projects": [ // "proj1", // "proj2" // ], // "isAdmin": true // } }
通过json.Marshal(user.UserInfo)，我们成功地只序列化了UserInfo结构体中定义的字段，而PasswordHash字段则被安全地排除在最终的JSON输出之外，完美实现了“只读不写”的需求。
优势与最佳实践
- 清晰的职责分离：这种方法明确区分了内部数据模型和外部API数据模型，使得代码结构更加清晰，易于理解和维护。
- 安全性增强：通过严格控制序列化时的数据暴露，有效防止了敏感信息（如密码哈希）的意外泄露，提高了应用程序的安全性。
- 灵活性高：当API需求变化时，只需修改UserInfo（或类似的对外结构体），而内部User结构体可以保持稳定。
- 可测试性强：不同职责的结构体使得单元测试更加聚焦和简单。
注意事项：
- 命名约定：为了提高可读性，建议为输入/输出结构体采用清晰的命名约定，例如UserRequest（用于反序列化输入）、UserResponse（用于序列化输出）、UserPayload、UserView等。
- 字段映射：如果内部结构体和外部结构体之间的字段差异较大，或者需要进行复杂的转换，可以考虑编写一个辅助函数来进行结构体之间的映射，而不是简单地嵌入。
- 一致性：在整个项目中保持这种结构体分离的模式，可以提高代码的一致性和可维护性。
总结
在Go语言中，当需要实现JSON字段的“只读不写”特性时，由于json:”-“标签的全局性限制，直接使用标签无法满足需求。通过引入结构体分离的策略，即为内部数据模型和外部API模型设计不同的结构体，可以优雅而安全地解决这一问题。这种方法不仅保证了敏感数据的安全性，也提升了代码的清晰度和可维护性，是Go语言处理此类JSON序列化/反序列化需求的推荐实践。