Go中channel传递错误的正确方式是使用chan error或分离的chan T与chan error双通道，避免chan interface{}混传；需注意缓冲、关闭、零值风险及配合context超时控制。
Go 中 channel 本身不能直接“传递错误”，但可以用 error 类型作为元素发送到 channel，这是最常用、最符合 Go 并发模型的错误传递方式。
用 chan error 接收 goroutine 的错误结果
当启动一个 goroutine 执行异步任务（如网络请求、文件读取）时，不应让 goroutine 自行 panic 或忽略错误。正确做法是通过专用的 chan error 回传错误：
- 定义 channel 时明确类型：
errCh := make(chan error, 1)（带缓冲更安全，避免 goroutine 阻塞） - 在 goroutine 内部，执行完逻辑后，
errCh <- err，无论成功或失败都必须发送一次 - 主 goroutine 用
select或直接接收：if err := <-errCh; err != nil { /* 处理 */ } - 注意：如果 goroutine 已经退出但 channel 未关闭，且主 goroutine 仍尝试接收，会永久阻塞 —— 建议搭配
context或使用带超时的select
组合 chan T 和 chan error 实现结果/错误双通道
很多场景需要同时返回值和可能的错误（类似函数多返回值），这时不推荐把 (T, error) 打包进一个 struct 发送（增加内存分配），而是用两个独立 channel：
-
resultCh := make(chan string, 1)和errCh := make(chan error, 1) - goroutine 中：成功时
resultCh <- data；失败时errCh <- err（二者只走其一） - 主 goroutine 用
select等待任一通道就绪：select { case data := <-resultCh: ... case err := <-errCh: ... } - 这种模式天然支持非阻塞等待、超时控制，也避免了类型断言开销
避免用 chan interface{} 或泛型 channel 混传错误和数据
虽然技术上可行，但会破坏类型安全，让调用方必须做类型断言，还容易漏判 nil：
立即学习“go语言免费学习笔记（深入）”；
- ❌ 错误写法：
ch := make(chan interface{})，然后ch <- errors.New("boom")或ch <- "ok" - ✅ 正确做法：用具体类型 channel，或用
struct{ Data T; Err error }（仅当必须单通道时才考虑，且需确保Err字段始终赋值） - 泛型 channel（如
chan Result[T]）可以封装，但底层仍是显式包含error字段，不是“绕过类型”的捷径
别忘了关闭 channel 和处理接收端的零值风险
channel 关闭不是必须的，但若接收方需知道“不会再有新消息”，则应在发送方完成所有发送后调用 close(ch)。不过对 chan error 来说，更常见的是“只发一次”：
- 接收前不检查 channel 是否已关闭，直接
<-ch是安全的；但如果 channel 被关闭且无数据，会立即返回对应类型的零值（error的零值是nil） - 所以不能靠“接收到
nil”判断成功 —— 必须配合业务逻辑或额外信号（比如用sync.Once控制只发一次） - 更稳妥的做法：用带缓冲的 channel + 明确的发送语义，或改用
context配合errgroup.Group等标准库工具
真正难的不是“怎么发错误”，而是决定谁负责监听、超时怎么设、失败后是否重试、多个 goroutine 错误如何聚合 —— 这些得结合具体业务路径设计，channel 只是其中一环。
