结论：goroutine池中无法真正丢弃已启动task，只能通过context协作式退出；必须为每个task单独设超时ctx并周期检查ctx.done()，否则会导致goroutine泄漏和worker阻塞。
直接说结论：goroutine 池里不能“丢弃”已启动的 task，只能让 task 主动感知超时并提前退出；所谓“丢弃”，本质是主流程不再等待它、也不再消费它的结果——这靠 context.Context + 带缓冲的 result 通道 + select 非阻塞发送实现。
为什么不能真“丢弃”正在运行的 goroutine
Go 没有提供终止其他 goroutine 的机制，runtime.Goexit() 只对当前 goroutine 有效。强行用 panic 或关闭通道中断执行，会导致资源泄漏、状态不一致、甚至 send on closed channel panic。所有“超时丢弃”的正确解法，都是协作式退出：task 自己检查 ctx.Done() 并 return。
- 常见错误：只在函数开头检查
ctx.Err()，后续仍执行耗时逻辑 - 更隐蔽的坑：HTTP 客户端没传
ctx，底层连接不受控，超时信号进不去 - 后果：goroutine 卡住不退出，池中 worker 被长期占用，新任务排队或被拒绝
用 context.WithTimeout 给每个 task 单独配超时
别给整个池设一个全局 timeout —— 那会让所有 task 同时被 cancel，失去独立性。每个 task 必须有自己的 ctx, cancel := context.WithTimeout(parentCtx, 3*time.Second)，并在 defer 中调用 cancel()。
- worker 函数内部必须周期性检查：
select { case - 若 task 内部调用
http.Client.Do()，记得把ctx传进去：req := req.WithContext(ctx) - 避免把同一个
ctx复用给多个 task，否则一超时全崩
结果通道要带缓冲且非阻塞发送
如果用无缓冲 resultChan，而主 goroutine 还没来得及接收，worker 就想发结果，就会死锁；如果结果通道满了又没处理，后续发送会阻塞 worker，导致它无法及时响应 ctx.Done()。
- 建议初始化为
make(chan Result, len(tasks))或至少make(chan Result, 100) - worker 发送时用非阻塞写法：
select { case resultChan - 这样即使主流程已超时、不再读取
resultChan，worker 也能立刻继续检查ctx.Done()并退出
主流程如何安全“放弃”超时 task
主 goroutine 不该等每一个 task 返回，而是用一次 select 监听总超时 + 结果通道，收到第一个结果就处理，超时就跳过剩余未完成的 task。
- 不要循环里每个 task 都起一个
time.After()—— 它们互不干扰，根本不算“总超时” - 正确做法：
timeoutChan := time.After(10 * time.Second)只创建一次 - 然后
select等待：case r := 或 <code>case - 一旦进入超时分支，就不再从
resultChan接收，已启动但未返回的 task 由它们自己的ctx控制退出
最容易被忽略的一点：worker 退出前是否释放了所有资源？比如打开了文件、占用了数据库连接、持有 mutex —— 这些都得在 defer 或 ctx.Done() 分支里显式清理。否则“丢弃”只是表面，内存和句柄还在悄悄增长。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
