无缓冲通道适合同步通信场景，当两个 goroutine 必须严格“手递手”交接数据时，make(chan int) 创建的无缓冲通道是最直接的选择，其发送方会卡在 ch
无缓冲通道适合同步通信场景
当两个 goroutine 必须严格“手递手”交接数据时，make(chan int) 创建的无缓冲通道是最直接的选择。它天然阻塞：发送方会卡在 ch 直到接收方执行 <code>，反之亦然。这种特性不是缺陷，而是设计意图——它强制了执行顺序，避免竞态。
- 适用于生产者必须等消费者就绪才发数据的场景，比如初始化信号、任务完成确认
- 如果只启动发送 goroutine 而主 goroutine 没有及时接收，程序会 panic：fatal error: all goroutines are asleep - deadlock
- 不要用它来“暂存”数据；它不缓存，只协调
有缓冲通道缓解耦合但需控制容量
make(chan string, 10) 这类带缓冲的通道允许发送方在缓冲未满时立刻返回，接收方在缓冲非空时立刻取值。它让生产者和消费者节奏可以错开，但缓冲区大小不是越大越好。
- 缓冲区设为 0 等价于无缓冲；设为 1 可解耦单次发送/接收；设为 N 仅表示最多暂存 N 个待处理项
- 若生产远快于消费，缓冲区持续满载，发送操作仍会阻塞——这不是 bug，是背压（backpressure）机制在起作用
- 常见误用：把缓冲大小设成 1000 以为“更安全”，结果掩盖了消费瓶颈，最终内存暴涨或超时
多返回值必须封装或拆通道
Go 通道只能传单一类型值，不能直接传递多个不同类型的返回值。硬要传 (string, int, error)，得选其中一种方式：
Go语言（Golang）1.26.0
下载
Go语言（Golang）1.26.0版本提供 Go 官方 Windows amd64 MSI 安装包下载入口，版本号 1.26.0，可用于旧项目维护、兼容性测试和指定版本开发环境配置。
- 定义结构体：
type Result struct { Data string; Code int; Err error }，再用make(chan Result) - 拆成多个通道：
dataCh := make(chan string)、errCh := make(chan error)，但需额外协调关闭时机，容易漏关或重复关 - 绝不推荐用
interface{}强转，会丢失类型安全，且 runtime 类型断言失败时 panic
通道关闭后接收行为要小心
调用 close(ch) 表示“不会再有新数据”，但已入缓冲的数据仍可被接收。此时 v, ok := 中的 <code>ok 才有意义：true 表示收到有效值，false 表示通道已关且无剩余数据。
- 只应由发送方关闭通道；接收方关闭会 panic
- 对已关闭通道再次
close()会 panic - 从已关闭且空的通道接收，
v得到零值（如 0、""、nil），ok为 false——这点常被忽略，导致逻辑误判
通道本身不难写，难的是判断哪个环节该阻塞、哪个该缓冲、谁负责关、关了之后怎么收尾。这些决策点不在语法里，而在业务节奏和资源约束中。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
