Go 的 struct 不能直接当 CQRS 的 Command/Query 类型用，因其无继承、无接口强制约束、无运行时语义标签，仅靠命名无法自动路由；需用空接口标记、规范 handler 分发、读写分离及最终一致性应对策略。
为什么 Go 的 struct 不能直接当 CQRS 的 Command/Query 类型用
Go 没有继承、没有接口实现强制约束，struct 本身不带语义标签，光靠命名（比如 CreateUserCommand 或 UserListQuery）无法在运行时区分读写意图，更没法自动路由到对应 handler。你得靠显式约定 + 手动分发，否则很容易把查询逻辑混进命令处理里。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 定义两个空接口标记：用
type Command interface{}和type Query interface{}，所有命令/查询结构体匿名嵌入它们（如type CreateUserCommand struct{ Command }），不是为了类型检查，而是给 IDE 和团队一个可 grep 的信号 - 避免用同一个 struct 同时承载输入校验和领域逻辑 —— 比如
UserForm既用于 HTTP POST 解析，又被塞进 command handler 做业务判断，后续加缓存或审计时会卡住 - 不要在 query struct 里放
ctx context.Context字段：它属于调用链，不是查询数据的一部分；放进去会导致序列化失败、日志污染、测试难 mock
Handler 分发器写成 switch-case 还是 map[string]func()？
Go 里没有反射友好的泛型调度器（不像 Java Spring 的 @CommandHandler），所以 dispatch 必须手动维护。用 map[string]func(interface{}) error 看似灵活，但 key 字符串容易拼错、没编译检查、无法跨包复用；而大段 switch-case 又难维护。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 按 command/query 类型名做 key：用
reflect.TypeOf(cmd).Name()生成字符串键，而非手写"CreateUserCommand"，避免 typo - handler 注册统一走 init 函数或启动时的
RegisterCommandHandler(<code>CreateUserCommand</code>{}, createUserHandler)，别散落在各文件里 - query handler 必须支持 context 超时控制 —— 比如
func(ctx context.Context, q *UserListQuery) ([]User, error)，否则数据库慢查询会拖垮整个 HTTP 请求
读库用 database/sql 连接池，为什么还总超时？
CQRS 下读库压力大，但很多人只调大 SetMaxOpenConns，忘了 SetMaxIdleConns 和 SetConnMaxLifetime 同样关键。连接池空闲太多会触发 DB 侧连接回收，再用时得重连；生命周期太长又可能拿到 DB 已断开的 stale 连接。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 读库连接池优先设
db.SetMaxIdleConns(20)，略小于SetMaxOpenConns(30)，保证常驻连接数稳定 -
SetConnMaxLifetime(5 * time.Minute)是安全值，比 MySQL 默认wait_timeout=28800（8 小时）短得多，能避开大部分“connection was closed”错误 - 别在 query handler 里用
db.QueryRowContext直接查主库 —— 即便只是 “SELECT id FROM users WHERE id = ?”，也要确保 data source 是专配的只读 replica，否则读写分离就失效了
EventStore 写完立刻查不到最新状态？
这是 CQRS 最典型的最终一致性陷阱。你发了 UserCreatedEvent 到 Kafka，Projection 服务消费后更新读库，但 HTTP 接口返回 201 后立刻 GET /users/123，大概率 404。这不是 bug，是设计使然；但用户感知差。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 对强一致性要求高的场景（如注册后立即跳转个人页），加一层「写后查」兜底：command handler 提交 event 后，同步查一次自己刚写的 aggregate snapshot（用本地内存 cache 或 Redis），不依赖 projection
- projection 消费延迟要可观测 —— 在 Kafka consumer group metrics 里监控
lag，超过 1s 就告警，别等用户投诉才发现 - 别让 query handler 去 join event store 表查最新状态：event store 是 append-only，不适合随机读；projection 表才是为查询优化的
真正难的不是拆开读写，而是界定哪些读必须强一致、哪些可以等几毫秒、哪些根本不需要实时 —— 这个边界得贴着业务需求划，代码里藏不住模糊地带。
