Go：新手从能写代码到能独立做项目，中间最容易缺哪几层能力

发表于 分类于 本文字数： 6.3k 阅读时长 ≈ 23 分钟
从会写 Go 函数，到能独立把一个小项目做完，中间真正缺的通常不是语法，而是需求拆解、抽象建模、目录职责、错误处理、测试、性能、上线排障和协作这些分层能力。本文围绕一个最小告警通知服务，把这条成长链路拆开讲清。

学 Go 写到能独立写函数、能把接口跑起来这一步时，最容易出现一种断层：

  • 单个函数能写
  • gin、net/http、数据库操作能拼起来
  • 小功能在本地也能跑通
  • 一旦变成“做一个完整项目”，代码就开始发散
  • 改一个需求，目录、接口、错误处理、测试一起乱

问题通常不在于语法没学完，而在于中间缺了几层工程能力：

  1. 需求怎么拆
  2. 模型怎么立
  3. 目录和包职责怎么分
  4. 错误怎么传递
  5. 测试怎么兜底
  6. 性能怎么验证
  7. 上线后怎么排障
  8. 和别人一起做时怎么保持边界稳定

这一篇不讲“如何从零学 Go 语法”，而是直接回答一个更贴近工程的问题：

从“会写函数”到“能独立做项目”，中间最容易缺的到底是哪几层能力。

贯穿全文的小项目是一个最小的告警通知服务。
它要做几件事：

  1. 接收监控系统上报的告警事件
  2. 判断是否重复告警
  3. 根据级别选择通知渠道
  4. 发送通知并记录结果
  5. 失败后做有限重试
  6. 暴露查询接口，方便排障和回放

这个项目不大，但足够把从编码到交付之间的关键能力层串起来。

一、这篇文章要解决什么问题

读完这一篇，应该能独立回答这些问题：

  1. 为什么“能写代码”还不等于“能独立做项目”
  2. 一个小项目从需求到上线，最少要经过哪些能力层
  3. Go 里目录设计、错误处理、测试和性能验证为什么会互相影响
  4. 哪些地方容易把代码写成“本地能跑、线上难改”
  5. 怎样用一个小型项目把工程能力补得更完整

如果这些问题能答清，后面再做小服务、脚手架、批处理器、内部工具，路径会稳很多。

二、先看贯穿全文的小项目

先把场景说具体。

假设现在要做一个告警通知服务，监控平台会把事件推过来：

1
2
3
4
5
6
7
{
  "id": "evt-1001",
  "service": "order-api",
  "level": "critical",
  "message": "db timeout",
  "occurred_at": "2018-09-12T20:00:00Z"
}

项目的最小需求如下：

  1. 同一个 id 在 5 分钟内重复到达时，只保留一次发送
  2. info 走邮件，warn 和 critical 走机器人
  3. 发送失败要重试 3 次
  4. 查询接口能看到最近一次发送状态
  5. 日志里能查到事件 ID、渠道、耗时、错误原因

如果只看功能点，这个项目不复杂。
真正拉开差距的，是你能不能把它做成下面这种状态：

  • 需求变更时能知道改哪一层
  • 出错时能快速定位是输入、路由还是发送器问题
  • 新增渠道时不需要把 if else 改满全项目
  • 能写测试保护住重复告警、重试和状态流转
  • 上线后看到延迟升高，知道从哪里开始查

三、先把一句话结论说清楚

从“会写函数”到“能独立做项目”，缺的往往不是某个高级语法点，而是下面这条链没有打通：

把需求拆成边界，把边界收敛成模型，把模型落到目录和包，再用错误处理、测试、观测、性能验证和上线流程把它变成可交付系统。

这条链里最容易断的，通常是这十一层能力：

  1. 需求拆解
  2. 抽象建模
  3. 目录职责
  4. 错误处理
  5. 状态流转
  6. 测试设计
  7. 配置与启动
  8. 日志和指标
  9. 性能验证
  10. 上线排障
  11. 协作约定

后面逐层拆开讲。

四、第一层能力：把需求从一句话拆成可交付清单

新手阶段最容易遇到的问题，不是代码写不出来，而是看到“做个通知服务”这种需求时，脑子里只有接口和数据库表。

更稳的第一步不是写代码，而是先拆清单。

拿这个小项目来说，需求至少要拆成六块：

  1. 输入：请求格式、字段校验、幂等键是什么
  2. 规则：重复判定窗口多长，渠道怎么选
  3. 动作：发送、记录、重试
  4. 状态：待发送、发送中、成功、失败、放弃
  5. 查询：外部能查什么，内部要留什么排障信息
  6. 运维：启动配置、超时、日志、指标

拆到这个粒度，代码层面的边界才会开始清楚。

如果连这一步都没做，后面经常出现这些问题：

  • 发送逻辑写进 HTTP handler
  • 重试逻辑写进数据库层
  • 查询接口返回不了真正需要排障的字段
  • 过了几天再看代码，已经分不清“业务规则”和“技术细节”

五、需求拆解里的常见错法

最常见的错法，是把需求直接翻译成“我需要几个接口、几张表、几个结构体”。

比如一上来就这样写：

1
2
3
4
5
6
7
8
9
10
11
func CreateAlert(c *gin.Context) {
    var req map[string]any
    if err := c.ShouldBindJSON(&req); err != nil {
        c.JSON(400, gin.H{"error": err.Error()})
        return
    }

    // 查一下数据库里有没有相同 id
    // 没有就直接发通知
    // 发失败就再发一次
}

这段代码的问题，不在于语法，而在于四层职责已经混在一起了：

  • HTTP 输入解析
  • 业务校验
  • 去重规则
  • 发送动作

这种写法在第一天看起来很快，三天后就会变成一团很难调整的流程代码。

更好的需求拆法，通常长这样：

  1. 先定义“接收告警”这一条主流程
  2. 再列出主流程里的规则节点
  3. 再列出每个规则节点需要依赖什么数据
  4. 最后才决定这些数据和动作落在哪些包

六、第二层能力：抽象建模，把数据和流程分开

需求拆完后，下一层能力是建模。

建模不是画一张 UML 图，而是回答几个很实际的问题：

  1. 系统里最核心的对象是谁
  2. 每个对象的职责边界是什么
  3. 哪些字段是输入态，哪些字段是持久态，哪些字段只是展示态

拿这个小项目来说，至少会有这几个核心对象：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
type AlertEvent struct {
	ID         string
	Service    string
	Level      Level
	Message    string
	OccurredAt time.Time
}

type DeliveryRecord struct {
	EventID      string
	Channel      Channel
	Status       DeliveryStatus
	Attempt      int
	ProviderCode string
	FailedReason string
	UpdatedAt    time.Time
}

type DeliveryDecision struct {
	Channel   Channel
	Deduped   bool
	Retryable bool
}

这里最关键的不是字段本身，而是三个对象的角色不同：

  • AlertEvent 表示输入事件
  • DeliveryRecord 表示发送结果
  • DeliveryDecision 表示业务决策

一旦这三类东西混在一个结构体里，后面状态流转、测试和查询都会变脆。

七、模型没立住时，代码通常会怎么坏

模型没立住，最典型的表现是“一个结构体承担一切”。

例如：

1
2
3
4
5
6
7
8
9
10
11
12
type Alert struct {
	ID          string
	Service     string
	Level       string
	Message     string
	RetryCount  int
	Status      string
	Channel     string
	Error       string
	ProviderRes string
	RequestIP   string
}

这类结构体常见的问题是：

  • 输入字段、领域字段、基础设施字段混在一起
  • 字符串到处飞，没有类型约束
  • Status 和 RetryCount 的关系没有规则表达
  • 查问题时很难判断某个字段该在哪一层被修改

建模真正要解决的是：让变化落在有边界的位置。

例如新增短信渠道时，理想情况只影响：

  1. 渠道枚举
  2. 路由决策
  3. 对应发送器

如果连数据库查询、HTTP 解析、状态查询接口都一起被拖着改，通常就是模型边界没站稳。

八、第三层能力：目录职责和包边界

Go 项目写到能维护的阶段，目录结构不是装饰，而是职责分配。

对这个小项目来说，下面这种结构就已经足够像一个项目，而不只是脚本集合：

1
2
3
4
5
6
7
8
9
alert-notify/
├── cmd/server
├── internal/domain
├── internal/service
├── internal/store
├── internal/channel
├── internal/httpapi
├── internal/config
└── internal/observability

每层职责可以先压成这样：

  • domain：核心对象和规则
  • service：主流程编排
  • store：持久化和去重存储
  • channel：邮件、机器人这些发送实现
  • httpapi：请求接入和响应封装
  • config：配置加载和校验
  • observability：日志、指标、trace 包装

目录分清后，有两个直接收益：

  1. 读代码时知道该从哪里进
  2. 改代码时知道影响范围大概在哪

九、一个更像脚本堆而不是项目的目录反例

反例也很典型：

1
2
3
4
5
6
7
8
project/
├── main.go
├── handler.go
├── util.go
├── db.go
├── send.go
├── retry.go
└── model.go

这个结构的问题在于名字都是技术动作，不是业务职责。

过一段时间后，最容易出现下面这些现象：

  • util.go 变成杂物间
  • model.go 同时放请求体、数据库模型、响应体
  • handler.go 里开始直接拼 SQL 和调用第三方 SDK
  • retry.go 不知道归业务规则还是基础设施

目录职责不清，最直接的后果不是“不优雅”，而是：

  • 测试难写
  • 改动范围难判断
  • 新成员接手成本高
  • 代码评审很难讨论边界

十、第四层能力：错误处理不是补丁，而是接口设计

写项目时，错误处理这层最容易被低估。

函数能返回 error，不代表错误已经设计好了。
真正要回答的是：

  1. 哪些错误是输入问题
  2. 哪些错误是业务规则拒绝
  3. 哪些错误是依赖故障
  4. 哪些错误可以重试
  5. 哪些错误要暴露给调用方，哪些只留给日志

这个小项目里，可以先把错误分成几类：

1
2
3
4
5
6
var (
	ErrInvalidEvent    = errors.New("invalid event")
	ErrDuplicateWindow = errors.New("duplicate in dedup window")
	ErrChannelNotFound = errors.New("channel not found")
	ErrProviderTimeout = errors.New("provider timeout")
)

再往前走一步，可以包上下文：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
func (s *Service) Deliver(ctx context.Context, event AlertEvent) error {
	if err := validateEvent(event); err != nil {
		return fmt.Errorf("validate event: %w", ErrInvalidEvent)
	}

	channel, err := s.router.Route(event.Level)
	if err != nil {
		return fmt.Errorf("route level %s: %w", event.Level, ErrChannelNotFound)
	}

	if err := s.sender.Send(ctx, channel, event); err != nil {
		return fmt.Errorf("send event %s via %s: %w", event.ID, channel, err)
	}
	return nil
}

这样做的价值在于：

  • 上层能 errors.Is 判断类别
  • 日志里有调用链上下文
  • 排障时知道失败发生在验证、路由还是发送阶段

十一、错误示例：把业务失败写成 panic

项目初期很容易出现这样的代码：

1
2
3
4
5
6
7
8
9
10
func mustRoute(level string) string {
	switch level {
	case "info":
		return "mail"
	case "warn", "critical":
		return "robot"
	default:
		panic("unknown level")
	}
}

这里的问题不是 panic 不能用，而是业务输入不应该把服务进程打掉。

更稳的写法是：

1
2
3
4
5
6
7
8
9
10
func route(level Level) (Channel, error) {
	switch level {
	case LevelInfo:
		return ChannelMail, nil
	case LevelWarn, LevelCritical:
		return ChannelRobot, nil
	default:
		return "", fmt.Errorf("unknown level %q: %w", level, ErrInvalidEvent)
	}
}

panic 更适合处理真正不该继续运行的程序错误，例如：

  • 明显破坏内部不变量
  • 启动期关键依赖缺失且没有降级路径
  • 测试里故意让程序快速暴露错误

业务失败、第三方超时、输入缺字段这些情况，通常都应该走正常错误返回。

十二、第五层能力：状态流转和幂等

当一个项目开始涉及“执行一次动作并记录结果”时，状态流转就出现了。

这个小项目至少会有下面这条状态链：

1
2
3
pending -> sending -> success
pending -> sending -> failed -> retrying -> success
pending -> sending -> failed -> exhausted

如果代码里没有明确状态流转，常见后果是：

  • 重试次数和最终状态对不上
  • 查询接口显示成功，实际最后一次发送失败
  • 重复告警进来后，又额外触发一次发送

可以先给状态一个最小枚举：

1
2
3
4
5
6
7
8
9
type DeliveryStatus string

const (
	StatusPending   DeliveryStatus = "pending"
	StatusSending   DeliveryStatus = "sending"
	StatusSuccess   DeliveryStatus = "success"
	StatusFailed    DeliveryStatus = "failed"
	StatusExhausted DeliveryStatus = "exhausted"
)

再给状态更新加约束：

1
2
3
4
5
6
7
8
9
10
11
12
func canTransit(from, to DeliveryStatus) bool {
	switch from {
	case StatusPending:
		return to == StatusSending
	case StatusSending:
		return to == StatusSuccess || to == StatusFailed
	case StatusFailed:
		return to == StatusSending || to == StatusExhausted
	default:
		return false
	}
}

写项目时，能把“允许什么状态变化”说清，就已经比“只改一个字符串字段”稳定得多。

幂等也是这一层的一部分。
同一个 event.ID 在窗口期内重复到达时，系统要回答的是：

  1. 直接忽略
  2. 只更新最后看到时间
  3. 记录重复次数

这个规则如果不提前定义，后面查询、排障和指标都会对不上。

十三、第六层能力：测试不是收尾动作，而是设计反馈

一到项目层面，测试的重要性会明显上升。
原因很直接：你写的不再是“一个函数对不对”，而是“多个边界拼起来后，规则是不是还成立”。

这个小项目里，最值得先测的不是第三方发送成功，而是规则：

  1. 重复窗口是否生效
  2. 渠道路由是否正确
  3. 重试次数是否封顶
  4. 状态流转是否合法
  5. 查询接口返回的记录是否和发送结果一致

如果这些地方不测，项目改两轮后就很容易出现“局部看起来没问题，整体流程已经歪了”的情况。

十四、怎么给这个小项目写最小测试集

先看一个表驱动测试例子，验证渠道路由：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
func TestRoute(t *testing.T) {
	cases := []struct {
		name  string
		level Level
		want  Channel
		ok    bool
	}{
		{name: "info to mail", level: LevelInfo, want: ChannelMail, ok: true},
		{name: "warn to robot", level: LevelWarn, want: ChannelRobot, ok: true},
		{name: "invalid level", level: Level("x"), ok: false},
	}

	for _, tc := range cases {
		t.Run(tc.name, func(t *testing.T) {
			got, err := route(tc.level)
			if tc.ok && err != nil {
				t.Fatalf("unexpected err: %v", err)
			}
			if !tc.ok && err == nil {
				t.Fatalf("expected err")
			}
			if tc.ok && got != tc.want {
				t.Fatalf("want %s, got %s", tc.want, got)
			}
		})
	}
}

再看一个流程测试，验证重复事件不会重复发送：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
func TestService_DeliverDedup(t *testing.T) {
	store := newMemoryStore()
	sender := &fakeSender{}
	svc := NewService(store, sender)

	event := AlertEvent{
		ID:         "evt-1001",
		Service:    "order-api",
		Level:      LevelWarn,
		Message:    "db timeout",
		OccurredAt: time.Now(),
	}

	if err := svc.Deliver(context.Background(), event); err != nil {
		t.Fatalf("first deliver err: %v", err)
	}
	if err := svc.Deliver(context.Background(), event); err != nil {
		t.Fatalf("second deliver err: %v", err)
	}
	if sender.calls != 1 {
		t.Fatalf("want 1 send call, got %d", sender.calls)
	}
}

这类测试的价值很大，因为它保护的已经不是单行代码，而是项目里真正重要的业务承诺。

十五、第七层能力：配置和启动流程

能独立做项目，意味着不只是把逻辑写出来，还要能把服务稳当地启动起来。

这个阶段最容易漏掉的有三件事：

  1. 配置从哪里来
  2. 配置是否合法
  3. 启动失败时日志够不够清楚

一个最小配置可以是：

1
2
3
4
5
6
7
8
type Config struct {
	HTTPAddr        string        `yaml:"http_addr"`
	DedupWindow     time.Duration `yaml:"dedup_window"`
	SendTimeout     time.Duration `yaml:"send_timeout"`
	MaxRetry        int           `yaml:"max_retry"`
	RobotWebhook    string        `yaml:"robot_webhook"`
	MailSMTPAddress string        `yaml:"mail_smtp_address"`
}

配置加载完后，不要立刻当成可用，先校验：

1
2
3
4
5
6
7
8
9
10
11
12
func (c Config) Validate() error {
	if c.HTTPAddr == "" {
		return errors.New("http_addr is empty")
	}
	if c.DedupWindow <= 0 {
		return errors.New("dedup_window must be positive")
	}
	if c.MaxRetry < 0 {
		return errors.New("max_retry must be non-negative")
	}
	return nil
}

这样做的收益不只是“更规范”，而是能把启动问题尽量提前暴露在本地和测试环境，而不是运行一段时间后才发现配置不对。

十六、第八层能力：日志、指标和排障入口

项目能否独立维护，一个关键分水岭就在观测能力。

如果服务出故障后只能靠读代码猜，就说明项目还停在“能跑”的阶段。
更像工程交付的做法，是在写逻辑时顺手把排障入口留好。

对这个小项目来说，日志至少要带这些字段：

  • event_id
  • service
  • level
  • channel
  • status
  • attempt
  • latency_ms
  • error

最小日志示例：

1
2
3
4
5
6
7
8
logger.Info("deliver finished",
	"event_id", event.ID,
	"service", event.Service,
	"channel", channel,
	"attempt", attempt,
	"status", status,
	"latency_ms", cost.Milliseconds(),
)

指标也不需要一开始就铺很大，先把核心链路埋住：

  1. 接收总量
  2. 去重命中数
  3. 各渠道发送成功数和失败数
  4. 平均耗时和 P95
  5. 重试次数分布

有了这些信息，线上问题至少能先回答：

  • 事件有没有进来
  • 是规则把它丢掉了，还是发送器挂了
  • 是整体变慢，还是某个渠道单独变慢

十七、第九层能力：性能意识从基线开始

从写代码到做项目，中间还缺一层性能意识。

这里说的性能，不是看到循环就想优化，而是能回答三个问题：

  1. 当前基线是多少
  2. 瓶颈在哪一层
  3. 改动后是否真的更好

这个小项目里，最可能变慢的点通常不是路由判断，而是：

  • 重复判定查询
  • 第三方发送阻塞
  • 大量日志格式化
  • 查询接口对记录列表做全量扫描

更稳的顺序通常是：

  1. 先确认慢的是 CPU、IO 还是外部依赖
  2. 先对关键函数做基准测试
  3. 再用日志和指标确认线上热点
  4. 最后才决定是否要改数据结构或并发模型

十八、一个最小性能验证示例

比如重试列表查询一开始写成线性扫描：

1
2
3
4
5
6
7
8
func (s *memoryStore) FindByEventID(id string) *DeliveryRecord {
	for i := range s.records {
		if s.records[i].EventID == id {
			return &s.records[i]
		}
	}
	return nil
}

数据量小的时候没问题，记录量上来后就会拖慢去重判断。

这时可以先写基准测试：

1
2
3
4
5
6
7
8
func BenchmarkFindByEventID(b *testing.B) {
	store := buildStoreWithNRecords(10000)
	b.ReportAllocs()

	for i := 0; i < b.N; i++ {
		_ = store.FindByEventID("evt-9999")
	}
}

如果确认这里已经成热点，再换成索引：

1
2
3
4
5
6
7
8
9
10
11
12
type memoryStore struct {
	records []DeliveryRecord
	index   map[string]int
}

func (s *memoryStore) FindByEventID(id string) *DeliveryRecord {
	pos, ok := s.index[id]
	if !ok {
		return nil
	}
	return &s.records[pos]
}

这个例子真正要说明的是：

  • 性能优化要先拿基线
  • 改结构前先确认热点
  • 改完后要重新测

项目层面的性能能力，核心是建立验证闭环，而不是看到代码就想“压榨一下”。

十九、第十层能力：上线、回滚和故障处置

能独立做项目，通常还意味着这个项目不只在本地跑一次，而是要进测试环境、预发环境、生产环境。

这时最容易暴露短板的，不是业务代码，而是上线相关能力：

  1. 启动失败怎么快速定位
  2. 发版后失败率升高怎么回滚
  3. 新版本和旧版本数据是否兼容
  4. 重试中的任务在发版时怎么处理

对这个小项目来说，上线前至少该有一个检查清单：

  1. 配置是否齐全
  2. 关键依赖是否可连通
  3. 发送渠道凭据是否有效
  4. 去重窗口和重试次数是否符合环境预期
  5. 查询接口是否能读到新写入记录

发版后如果出现“告警进来了，但通知没发出去”，排障顺序可以先压成这样：

  1. 查接收日志，确认事件已进入系统
  2. 查去重指标，确认是否被窗口过滤
  3. 查路由日志，确认渠道选择是否正常
  4. 查发送器日志和超时指标，确认是否卡在外部依赖
  5. 查持久化记录，确认状态有没有更新

这个顺序清楚，线上故障才不至于一上来就全靠猜。

二十、第十一层能力：协作、接口约定和代码评审

独立做项目不等于独自关门写完。

真正进入工程阶段后，哪怕项目规模不大，也会碰到这些协作点：

  1. 和前端或调用方约定请求响应格式
  2. 和运维约定配置和部署方式
  3. 和同组成员约定目录边界和错误风格
  4. 在代码评审里解释设计取舍

这个阶段最容易缺的，不是“沟通态度”，而是接口约定能力。

例如查询接口，如果只返回：

1
2
3
{
  "status": "failed"
}

那排障价值很低。
如果返回的是：

1
2
3
4
5
6
7
8
{
  "event_id": "evt-1001",
  "status": "failed",
  "attempt": 3,
  "channel": "robot",
  "failed_reason": "provider timeout",
  "updated_at": "2018-09-12T20:12:00Z"
}

调用方、排障人员和后续开发都能少走很多弯路。

代码评审也一样。
比起只说“这个实现能跑”，更有价值的是把下面这些点说清：

  1. 为什么用显式状态而不是一个布尔值
  2. 为什么把发送渠道抽成接口
  3. 为什么 handler 不直接操作数据库
  4. 这个测试保护的是哪条业务规则

能把这些点讲清，项目协作才会逐步稳定。

二十一、边界：什么时候还不需要把项目做得太重

前面讲了不少工程能力，但也不要走到另一个极端，把每个小工具都做成“大型框架”。

有些场景下，简单结构就够：

  1. 一次性脚本
  2. 生命周期很短的内部工具
  3. 规则和流转都极少的小服务
  4. 还在验证需求真假的原型

这时可以先保留简化版：

  • 目录少一点
  • 抽象薄一点
  • 先用内存存储
  • 测试先保关键路径

真正要警惕的，不是项目小，而是需求已经明显变复杂，代码还停留在脚本写法。

一个简单判断方式是看这三个信号：

  1. 改一个需求时会动到三层以上代码
  2. 出问题后定位路径超过半小时
  3. 新增一种能力时只能复制旧代码再改字符串

只要这三个信号开始稳定出现，就说明该补工程层了。

二十二、把这些能力串成一条完整交付链

把前面各层串起来，这个小项目更像一条完整链路：

  1. 需求拆解
    确认输入、规则、动作、状态、查询、运维

  2. 抽象建模
    分出事件、决策、记录三类核心对象

  3. 目录职责
    把领域、流程、存储、渠道、接口拆开放

  4. 错误处理
    区分输入错误、规则拒绝、依赖故障和可重试失败

  5. 状态流转
    定义待发送、发送中、成功、失败、耗尽等状态

  6. 测试验证
    用单测和流程测试保护核心规则

  7. 性能验证
    为热点查询和发送链路建立基线

  8. 上线排障
    通过日志、指标、查询接口形成故障定位入口

  9. 协作约定
    把接口、目录、错误风格和评审标准固定下来

当这条链打通后，你做的就不只是“一堆能运行的 Go 代码”，而是一个可以被维护、被验证、被交接、被上线的小项目。

二十三、写这个项目时，最容易踩的几个坑

把这些能力层合起来看，这个阶段最常见的坑基本集中在下面几类：

  1. handler 直接写业务流程
    后面测试和复用都很难做

  2. 所有字段都用字符串
    状态、渠道、级别缺少类型保护

  3. 错误只返回一句文本
    上层既不能分类，也拿不到上下文

  4. 没有流程测试
    局部函数都对，整体流程仍然可能出错

  5. 日志不带业务键
    线上出问题后无法按事件 ID 串联链路

  6. 上线前不校验配置
    结果启动成功，流量进来后才发现渠道不可用

这些坑并不神秘，核心原因通常都是中间那几层能力还没有补齐。

二十四、练习：把文章里的小项目继续做下去

如果你想把这篇文章里的内容变成自己的能力，可以继续做这几组练习：

  1. 给告警通知服务新增 sms 渠道
    要求只改路由和发送器，不动主流程控制

  2. 给去重逻辑加时间窗口测试
    验证窗口内重复事件不再发送，窗口外再次发送

  3. 给查询接口补分页和按状态过滤
    观察模型和存储层是否需要一起调整

  4. 给发送器加超时和 context 取消
    验证超时错误能否被正确记录并重试

  5. 给 FindByEventID 写 benchmark
    比较切片扫描和 map 索引的差异

  6. 模拟一次上线故障
    例如机器人 webhook 配置为空，整理一遍从启动失败到日志定位的排障过程

做完这几组练习后，你得到的就不只是某几个语法点，而是一整条小项目交付链的手感。

二十五、结语

从会写 Go 代码到能独立做项目，中间最容易缺的，不是某个“进阶语法”，而是多出来的那几层工程能力。

会写函数，解决的是局部表达。
能独立做项目，解决的是另一类问题：

  • 需求怎么拆
  • 模型怎么立
  • 包边界怎么放
  • 错误怎么传
  • 测试怎么护住规则
  • 性能怎么验证
  • 上线后怎么查
  • 协作时怎么不把系统写散

把这些层一层层补起来，项目经验才会真正开始沉淀。
等你再回头看那些“写一个接口、调一个库、把功能跑起来”的阶段，会发现真正拉开差距的，从来不是写出更多代码，而是把代码组织成一个能长期交付的小系统。