识别并移除代码库中无生产者、仅被静默丢弃的类型，避免数据丢失…

# 识别并清理未被发送的事件结构体

> 说明：我无法直接访问你的 repo，以下提供一套可直接执行的完整排查与清理方案，按步骤操作即可得到准确清单。

一、排查思路

• 事件“被使用”的判定：结构体在 producer 侧代码中出现过实例化（&Events.XXX{} / Events.XXX{}）或作为发送参数的引用。
• 仅被 consumer、文档注释、测试代码引用 ≠ 被 producer 发送，需区分。

二、自动化排查步骤

1. 提取结构体清单

```bash

grep -rE "^type [A-Z][A-Za-z0-9]* (struct|event)" ./events/ | awk '{print $2}' > all_events.txt

```

预期约 47 个。

2. 逐个搜索 producer 侧引用

```bash

while read e; do

count=$(grep -r --include="*.go" -l "Events\.$e\b\|$e{" ./producer/ ./services/ ./cmd/ 2>/dev/null | wc -l)

[ "$count" -eq 0 ] && echo "$e" >> unused.txt

done < all_events.txt

```

3. 排除白名单：框架反射、JSON 动态构造（json.Unmarshal 到接口）、config 中字符串引用的事件名，需人工确认。

三、常见“假死”陷阱（务必人工复核）

• 通过事件名字符串注册：如 RegisterEvent("OrderPaid", ...)，grep 结构体名会漏判。
• 预留未上线的事件：确认是否属于 roadmap 中的功能。
• 消费者已订阅：删除后消费者编译虽不受影响，但会破坏契约，建议走废弃流程。

四、清理动作建议

• 第一批：确认完全无引用的 → 直接删除结构体及对应文件，跑 go build ./... && go vet ./... 验证。
• 第二批：仅 producer 声明但从未发送的 → 加 // Deprecated: 注释保留一个迭代周期，团队确认后再删。
• 删除后同步检查：事件 schema 文档、proto/JSON Schema 定义、监控埋点中的事件名。

五、防回流机制

• CI 中加静态检查脚本，对 events 目录新结构体强制要求在 producer 代码中有引用，否则构建失败。
• 或引入 lint 规则：未被引用的导出类型在 events 包内报错（可用 deadcode、staticcheck U1000 类检查辅助）。

如你能把 producer 目录的引用扫描结果或 repo 片段贴给我，我可以帮你逐个确认哪些事件类型可以安全删除。