本文探讨了在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"` // 敏感字段，在反序列化时需要读取
}在这个设计中：
- 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对象: %+v\n", user)
fmt.Printf("用户名: %s\n", user.UserName)
fmt.Printf("密码哈希: %s\n", user.PasswordHash) // 密码哈希被成功读取
fmt.Printf("是否管理员: %t\n", 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: %s\n", 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序列化/反序列化需求的推荐实践。
