在 go 中，为避免客户端与服务端重复定义相同的消息结构体，推荐将共享类型提取到独立的公共包中，或合理组织包依赖关系，以实现类型复用、降低耦合、提升可维护性。
在 go 中，为避免客户端与服务端重复定义相同的消息结构体，推荐将共享类型提取到独立的公共包中，或合理组织包依赖关系，以实现类型复用、降低耦合、提升可维护性。
在构建典型的客户端-服务端系统（如 RPC、HTTP API 或消息中间件）时，双方需约定统一的数据契约。例如，一个通用消息结构体：
type Message struct {
SenderID int `json:"sender_id"`
Content string `json:"content"`
AuthCode string `json:"auth_code"`
}若将该结构体分别复制到 client/ 和 server/ 包中，不仅违反 DRY（Don’t Repeat Yourself）原则，还会导致以下问题：
- 类型不一致：client.Message 与 server.Message 在 Go 类型系统中互不兼容（即使字段完全相同）；
- 维护成本高：字段增删改需同步多处，易遗漏或出错；
- 序列化/反序列化隐患：JSON 标签、编码行为可能因包隔离而产生差异。
✅ 推荐方案：按职责分离，提取公共类型包
最佳实践是创建专用的 types（或 model、proto、shared）包，专门存放跨模块复用的结构体、常量、接口等：
myapp/
├── go.mod
├── types/
│ ├── types.go // 定义 Message 等共享类型
├── server/
│ ├── main.go
│ └── handler.go // import "myapp/types"
└── client/
├── main.go
└── api.go // import "myapp/types"types/types.go 示例：
package types
// Message 是客户端与服务端通信的标准消息结构
type Message struct {
SenderID int `json:"sender_id"`
Content string `json:"content"`
AuthCode string `json:"auth_code"`
}
// Validate 返回基本校验结果（可选增强）
func (m Message) Validate() error {
if m.SenderID <= 0 {
return fmt.Errorf("invalid sender_id: %d", m.SenderID)
}
if m.Content == "" {
return fmt.Errorf("content cannot be empty")
}
return nil
}客户端与服务端即可统一引用：
import "myapp/types"
func sendMsg() {
msg := types.Message{
SenderID: 123,
Content: "Hello, server!",
AuthCode: "token-abc",
}
// ... 序列化并发送
}⚠️ 其他可行但需谨慎的方案
方案二：共用主包（如 server 导出类型，client 直接导入）
适用于服务端明显为主导、客户端仅为附属工具的场景（如 CLI 工具）。但会形成反向依赖（client → server），违背“client should not depend on server”的设计直觉，长期演进易僵化。方案三：合并为单包（如 cmd/myapp 下统一管理）
适合极简原型或工具类项目（如 http 包自身封装了 client/server），但牺牲了模块边界与可重用性，不推荐中大型项目采用。
? 关键注意事项
- 包名语义清晰：避免使用泛泛的 common（易滥用），优先选用 types、schema、dto 等体现契约意图的名称；
- 避免循环导入：公共包不得依赖 client 或 server，否则编译失败；
- 版本兼容性：若项目对外提供 SDK，types 包应遵循语义化版本（SemVer），结构体变更需考虑向后兼容（如仅追加字段、保留 JSON 标签）；
- 生成式扩展友好：若后续引入 Protocol Buffers 或 OpenAPI，建议 types/ 与 .proto 或 openapi.yaml 保持映射一致性，便于代码生成。
综上，独立 types 包是最符合 Go 工程实践、社区共识与长期可维护性的方案——它明确界定了契约层，支撑清晰的依赖流向（client ⇄ types ←→ server），让团队协作更可靠，也让你的 Go 项目真正“可生长”。
