工单系统需基于有限状态机（FSM）实现状态流转，区分运行时与持久化结构体，用行级锁或乐观锁保障并发安全，事件触发须幂等，核心操作应异步化。

Go 语言本身不提供工单系统，你得自己搭骨架——核心是状态机 + 事件驱动 + 持久化，不是套个框架就能跑起来。

工单状态流转必须用有限状态机（FSM）控制

直接用 string 或 int 表示状态（如 "open"、"processing"）会导致非法跳转难以拦截，比如从 "closed" 直接回到 "open" 而没人报错。

• 推荐用 github.com/looplab/fsm 或手写简单 FSM：定义明确的 states 和 transitions，每次调用 fsm.Event() 前校验合法性
• 状态变更必须走 Transition 方法，禁止直接改数据库字段或结构体字段
• 把状态迁移逻辑和业务解耦，例如 CloseTicket() 内部只触发 "close" 事件，不写 SQL

工单数据模型要区分“运行时”和“持久化”结构

别把 struct 直接当 ORM Model 用。一个工单在内存中可能需要缓存用户信息、关联任务列表、最近操作日志；但存到数据库里只需要最小必要字段。

• 定义两个结构体：Ticket（面向业务逻辑，含嵌套对象、方法）和 TicketRow（纯字段映射，用于 sqlx 或 gorm）
• 避免在 Ticket 里塞 sql.NullString 这类 DB 专用类型，它们会污染领域逻辑
• 时间字段统一用 time.Time，入库前通过 BeforeSave 钩子或手动赋值处理时区（建议全系统用 UTC 存储）

并发更新工单时容易丢状态或重复触发事件

多个协程同时调用 ticket.Transition("resolve") 可能导致两次成功提交，最终状态错乱，或者同一个事件被处理两遍（比如发了两条通知）。

Golang Uber Dig

使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等

下载

• 用数据库行级锁：执行状态变更前先 SELECT ... FOR UPDATE 工单记录（PostgreSQL/MySQL 支持）
• 或加乐观锁：在 TicketRow 加 version 字段，UPDATE 时带 WHERE version = ?，失败则重试
• 事件触发（如发邮件、Webhook）必须做成幂等操作，不能依赖“只触发一次”，而要靠唯一事件 ID + 去重表或 Redis SETNX

不要在 HTTP handler 里做耗时工单操作

用户点击“分配给张三”就卡住 2 秒？那不是系统，是阻塞队列。工单操作常涉及通知、审批流、外部 API 调用，必须异步化。

• handler 只做参数校验 + 状态合法性检查 + 入库（事务内），然后投递消息到 redis streams 或 nats
• 单独起 worker goroutine 消费事件，失败后进重试队列（带指数退避）
• 前端轮询或用 SSE 获取操作结果，而不是等后端同步返回所有副作用结果

真正难的不是增删改查，而是状态一致性、事件顺序、跨服务协作——这些不会因为用了 Go 就自动变简单。每加一个新状态或一条流转规则，都要重新审视所有可能的竞态路径。

golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！