go 1.23 的 range over func 要求函数签名必须为 func(yield func(t) bool) 或其键值变体，否则编译报错；数据库分页需在 yield 内按需查询，避免全量加载；yield 返回 bool 是强制控制流开关，漏判将导致迭代失控。
Go 1.23 的 range over func 不是语法糖，而是有硬性签名约束的迭代机制：必须用 func(yield func(T) bool) 或其键值变体，否则编译直接报 cannot range over。
为什么 func() int 不能被 range？
编译器只靠函数参数是否含 yield func(T) bool 来识别迭代器，不看返回值、不推理逻辑、不认函数名。
-
func() int：被当普通函数，range拒绝接收 -
func() (int, bool)：Go 1.22 试验写法，1.23 已弃用，报错cannot use ... as iter.Seq[int] value -
func(yield func(int) bool)：唯一被认可的标准签名，range能识别并驱动迭代 - 建议直接用
iter.Seq[int]类型别名，语义清晰，避免手写冗长签名
数据库分页迭代器怎么写才不查爆内存？
核心原则：DB 查询必须放在 yield 回调内部，而不是函数开头一次性查完。否则每次 range 迭代都触发全量查询，性能直接崩。
Golang Samber Hot
下载
在 Golang 中使用 samber/hot 进行内存缓存，支持 LRU、LFU、TinyLFU、W‑TinyLFU、S3FIFO、ARC、TwoQueue、SIEVE、FIFO 等淘汰算法，提供 TTL、缓存加载器及分片功能。
- 错误做法：
rows := db.Query(); for rows.Next() { ... }—— 一调用就查完所有页，缓存全在内存里 - 正确做法：把
offset和缓存切片作为闭包变量，在yield循环体内按需查下一页 -
db.Select(&ids, "SELECT id FROM users LIMIT ? OFFSET ?", limit, offset)必须在for循环内执行 - 查不到数据或出错时，直接
return；yield不会被调用，range自然终止，无需panic或显式 error 返回
组合多个迭代器时常见陷阱
别直接嵌套 for 循环，否则失去流式控制、无法复用 iter 工具链，还容易引发 N+1 查询。
- 错误示范：
for id := range UserIDs() { for detail := range GetUserDetail(id) { ... } } -
GetUserDetail(id)若返回iter.Seq[User]，但你传入的是int，类型不匹配会报cannot use ... as iter.Seq[int] value - 正确思路：用
iter.Map包装，或手写一个新迭代器，把 ID 流和详情获取逻辑收束到一个yield闭包里 - 调试时卡死或没输出？大概率是
yield调用漏了if !yield(x) { return }判断，导致无限循环或越界
最易忽略的一点：yield 回调的返回值 bool 是迭代的生命线——它不是可选提示，而是强制控制流开关。漏判、误判、或在 yield 外部做副作用（比如提前 close DB 连接），都会让迭代行为失控。这不像 channel 那样有 goroutine 缓冲兜底，它是纯同步、零中间态的推模型。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
