关闭 channel 后读取不 panic 是因 chanrecv 函数先检查 c.closed，若已关闭且无数据则直接返回零值和 false；而发送会 panic。该行为由运行时原子置位 c.closed 并唤醒等待 goroutine 保证。
channel 关闭后读取为什么不会 panic，而是返回零值 + false
因为 go 运行时对 chanrecv 的底层处理逻辑做了特殊分支：当 channel 已关闭且缓冲区为空时，不阻塞、不 panic，而是直接写入零值并把 ok 设为 false。这和未关闭 channel 的阻塞/非阻塞读取路径是分离的。
关键点在于：chanrecv 函数内部会先检查 c.closed != 0，再判断缓冲区是否为空；只要满足“已关闭 + 无数据可读”，就跳过等待逻辑，走 cleanup 路径。
- 关闭后的 send 操作会 panic（
panic: send on closed channel），但 read 不会——这是设计上明确区分的行为 - 即使有 goroutine 正在
send，只要 channel 已关闭，后续的 receive 仍按“关闭语义”执行（即返回零值+false），因为关闭动作会原子地置位c.closed字段，并唤醒所有等待的 recv goroutine - 这个行为与 buffer 是否为空无关：关闭前缓存了 3 个元素？那还能读 3 次 true；第 4 次开始就是零值 + false
ok-idiom 的汇编层面实际触发点在哪
不是编译器“翻译”出额外指令，而是 go tool compile -S 显示：带 ok 的接收语句（如 v, ok := ）会生成两条结果写入指令——一条写值到目标变量，一条写布尔结果到 <code>ok 变量。而单纯 v := 只写值。
真正决定 ok 是 true 还是 false 的，是运行时 chanrecv 函数通过其返回的 received 参数（类型为 *bool）回填的值。这个参数仅在生成 ok 变量时才被传入。
- 没有
ok变量时，编译器不传received指针，chanrecv也就不填它 - 有
ok变量时，运行时根据是否成功从队列/缓冲区拿到值，设置该指针指向的内存为true或false - 注意：
ok为false并不意味着 channel 一定已关闭——也可能是非阻塞读（select+default）时没抢到数据
关闭后仍能读到数据，是因为缓冲区和 sendq 的优先级顺序
channel 关闭不影响尚未被消费的缓冲数据，也不影响已排队但尚未完成的发送操作。运行时按固定顺序尝试读取：先缓冲区（c.buf），再 sendq（等待中的 sender 队列），最后才判定“无可读”。只有三者都空，且 c.closed == 1，才返回零值 + false。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
- 缓冲区有数据 → 直接 copy 出来，
ok = true - 缓冲区空，但 sendq 非空（比如某个 goroutine 刚调用
send进入休眠，还没被唤醒）→ 从 sender 的栈 copy 数据，ok = true - 缓冲区空、sendq 空、
c.closed == 1→ 写零值，ok = false - 缓冲区空、sendq 空、
c.closed == 0→ 阻塞或报错（取决于是否 select/default）
容易误以为 “ok == false 就代表 channel 关闭” 的陷阱
这是最常见的逻辑漏洞。实际上 ok == false 只表示“本次接收未获得有效数据”，原因可能是：channel 关闭，也可能是非阻塞读失败，还可能是 select 在多个 case 中选了别的分支。
- 用
select+default做非阻塞读时，ok为false完全不说明 channel 状态 - 多个 goroutine 并发读写同一 channel 时，
close(ch)和的时序不可控，<code>ok == false可能发生在 close 之前（因竞争） - 真正安全判断 channel 是否关闭，只能靠外部同步信号（如额外的
donechannel）或约定：只由 sender 关闭，receiver 读到ok == false后不再读
底层机制很清晰，但把 ok 当作 channel 生命周期的唯一信标，会在并发边界上悄悄出错。
