go通道声明与初始化必须严格匹配字符串类型，如ch := make(chan string)，chan string与chan int不兼容；误用会导致编译错误；无缓冲通道要求收发同时就绪，否则阻塞；关闭后不可再发送，接收需用msg, ok :=
通道声明和初始化必须匹配字符串类型
Go 里通道是类型安全的，chan string 和 chan int 完全不兼容。如果误用 make(chan int) 却往里塞字符串，编译直接报错：cannot use "hello" (type string) as type int in send。
正确做法是显式声明字符串通道：
ch := make(chan string)
常见错误包括：
- 忘记指定类型，写成
make(chan)—— Go 不允许未指定类型的通道 - 用
chan（只送）或 <code>（只收）后，试图反向操作，比如对只送通道调用 <code> - 在函数参数中混用双向/单向通道，例如函数期望
，却传入 <code>chan string—— 实际可以，但反过来不行
发送和接收字符串必须配对且不阻塞（或明确处理阻塞）
无缓冲通道（make(chan string)）要求发送和接收同时就绪，否则 goroutine 会永久阻塞。典型错误是只发不收，程序卡死在 ch 这一行。
实操建议：
- 若确定有接收方，用无缓冲通道最简洁；否则优先用带缓冲的：
ch := make(chan string, 2)，可暂存 2 个字符串 - 避免在主线程直接
等待，除非你启了 goroutine 发送，否则永远等不到 - 加超时防止死锁：
select { case msg :=
关闭通道后不能再发送，但可继续接收已存在的数据
关闭通道（close(ch)）只是告诉接收方“不会再有新数据”，不是销毁通道。之后再执行 ch 会 panic：<code>send on closed channel。
接收侧行为更关键：
msg := 在关闭后仍能读完缓冲区剩余内容，读完才返回零值（空字符串）- 想区分“零值”和“通道已关”，要用双返回值：
msg, ok := ；当 <code>ok == false表示通道已关闭且无更多数据 - 多个 goroutine 同时从同一通道接收没问题，但关闭操作应由唯一生产者完成，否则 panic：
close of closed channel
字符串传递要注意内存和所有权，但通常无需额外拷贝
Go 中字符串是只读的底层数组 + 长度结构体，传递 string 值本身开销很小（16 字节），通道传输时不会深拷贝底层字节数组。所以传大 JSON 字符串或长日志行，性能压力主要在分配和 GC，不在通道本身。
真正要留意的是：
- 别把
string当作可变对象去修改 —— 任何修改都会生成新字符串，原值不受影响 - 如果字符串来自
unsafe.String()或 C 互操作，确保底层内存生命周期覆盖整个通道传递过程，否则可能读到垃圾数据 - 高吞吐场景下，频繁创建短字符串（如循环中
fmt.Sprintf）比通道本身更容易成为瓶颈
通道传字符串这件事本身很简单，难的是设计好谁发、谁收、何时关、怎么容错 —— 多数问题出在控制流，不在语法。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
