close()仅设置hchan.closed为1并唤醒recvq上的goroutine，不置nil也不清缓冲区；已关闭channel读取时，缓冲区有数据则正常读出，空后返回零值和false，false是关键信号。
close() 不会把 channel 变成 nil，也不会清空缓冲区，它只改变底层 hchan.closed 字段为 1，并唤醒所有阻塞在 recvq 上的 goroutine。后续对已关闭 channel 的读取行为，取决于是否还有未读数据。
已关闭 channel 的读取行为：ok 判断比零值更关键
从已关闭的 chan int 读取，若缓冲区还有剩余数据，仍能正常读出；缓冲区空了之后，每次读都返回 0, false —— 这里的 false 是关键信号。
val := ：永远不 panic，但可能拿到零值（比如 <code>0、""、nil），无法区分是“刚关闭”还是“真数据”val, ok := ：<code>ok == false才表示 channel 确实已关闭且无更多数据- 用
for range ch自动处理关闭逻辑，等价于持续val, ok := 直到 <code>ok为false
向已关闭 channel 发送数据：panic 不可恢复
只要执行 ch 向已关闭的 channel 写入，运行时立即触发 <code>panic: send on closed channel，且无法被普通 recover() 捕获（除非在 defer 中嵌套 recover 并确保调用栈未退出）。
Colly Golang Web Scraper and Crawler Framework
下载
Colly 是一个用于 Go 语言的快速开源爬取和爬虫框架。它适用于从简单的页面提取到异步爬虫处理大量页面集合，支持请求回调和结构化解析。
- 常见错误：多个 goroutine 共享一个 sender，各自判断“该不该关”，结果重复
close(ch)或先关后发 - 正确做法：仅由**唯一 sender** 负责关闭；receiver 绝不调用
close() - 没有“安全发送”函数，
select+default只能避免阻塞，不能防止 panic
nil channel 在 select 中的特殊作用
nil channel 在 select 语句中永远不可就绪，因此常被用来临时禁用某个 case 分支。
-
var ch chan int声明即为nil，此时或 <code>ch 会永久阻塞（不是 panic） - 配合
select使用：case 若 <code>ch == nil，该分支永不触发，相当于“逻辑开关” - 注意：不能靠
ch == nil判断 channel 是否关闭 —— 关闭后的 channel 仍是非nil的有效指针
底层状态机只有三种：未关闭 / 已关闭 / nil
Go 运行时对 channel 的操作判定完全基于这三态，没有“正在关闭中”或“半关闭”概念。每种状态对应确定的行为组合，见下表：
操作 | 未关闭 | 已关闭 | nil ----------|------------|----------------|--------- 发送 | 阻塞或成功 | panic | 永久阻塞 接收 | 阻塞或成功 | 成功或 (零值,false) | 永久阻塞 关闭 | 成功 | panic | panic
真正容易被忽略的是：channel 关闭后，其底层结构体（hchan）的 buf、sendx、recvx 等字段依然有效，只是 closed 标志位翻转。这意味着缓冲区里残留的数据必须被显式消费完，否则会卡住 receiver 的退出逻辑。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
