常见原因是未正确初始化 scanner.Scanner 的 Src 字段或传入空/nil 字节切片；go/scanner 仅对已有 []byte 单次线性扫描，必须调用 Init 且 src 不能为空，FileSet 也不能为 nil。
用 go/scanner 扫描 Go 源码时，为什么 Scan 返回的 token 总是 scanner.EOF？
常见原因是没正确初始化 scanner.Scanner 的 Src 字段，或传入了空/nil 字节切片。这个包不读文件、不自动加载内容，它只对已有的 []byte 做单次线性扫描。
- 必须手动调用
Init，且src参数不能为空 —— 即使是空字符串也要写成[]byte("") -
Init第二个参数是*token.FileSet，不能传nil；建议用token.NewFileSet().AddFile(...)构造一个 - 扫描从当前位置开始，不会重置偏移；如果反复调用
Scan但没重置状态，很快就会扫到末尾
示例错因：
var s scanner.Scanner
s.Init(nil, []byte("x := 1"), nil, 0) // panic: src == nil如何用 go/scanner 安全提取所有标识符（identifier）？
go/scanner 不做语法树构建，只返回原始 token 流，所以“标识符”对应的是 token.IDENT 类型，但要注意：它也把关键字（如 func、if）当作 token.IDENT 返回 —— 这是设计如此，词法层无法区分保留字和普通标识符。
- 每次调用
s.Scan()返回pos token.Pos、tok token.Token、lit string，其中lit是原始字面量（比如"main"），tok是类型（如token.IDENT） - 要过滤出真正用户定义的标识符，得结合
token.IsKeyword(lit)判断是否为关键字 -
lit是源码中实际拼写的字符串，含大小写；Go 标识符规则（如首字符不能是数字）已在扫描时校验，无需再检查
简短判断逻辑：
立即学习“go语言免费学习笔记（深入）”；
for {
pos, tok, lit := s.Scan()
if tok == token.EOF {
break
}
if tok == token.IDENT && !token.IsKeyword(lit) {
fmt.Printf("user ident: %s at %v\n", lit, pos)
}
}
go/scanner 和 go/token + go/parser 的分工边界在哪？
很多人误以为 go/scanner 能替代 go/parser，其实它只管“切词”，不管“断句”。比如 a[i] = f(x, y) 这一行，scanner 输出的是 IDENT、LBRACK、IDENT、RBRACK、ASSIGN……共 10+ 个 token；而 parser 才会把它们组装成赋值语句节点、下标表达式、函数调用等 AST 结构。
- 如果你只需要统计变量名、找注释位置、检测裸字符串开头（
`）、跳过某类 token，用scanner更轻量、更快 - 但凡涉及嵌套结构（如括号匹配、大括号作用域、表达式优先级）、需要知道某个
IDENT是函数名还是字段名，就必须上parser -
scanner不处理行注释//和块注释/* */的内容解析，只返回token.COMMENT类型和完整字面量，注释内部格式得自己拆
扫描非 UTF-8 编码的 Go 源文件会怎样？
go/scanner 强制要求输入是 UTF-8 编码的 []byte。如果源码是 GBK、Shift-JIS 等编码，直接传入会导致 token 位置错乱、字面量截断、甚至提前触发 token.ILLEGAL。
- Go 工具链（
go build、gofmt）本身只接受 UTF-8，所以生产环境几乎不会遇到；但若从旧系统导出代码、或处理用户上传文件，需先转码 - 别用
strings.ToValidUTF8或简单替换\xFF\xFD，这会破坏位置映射；应使用golang.org/x/text/encoding包做带位置保持的转换 - 错误现象典型：同一行里
扫描出两个 IDENT中间夹着ILLEGAL，或者lit字符串长度与预期不符（中文变 3 个）
真正难处理的不是“能不能扫”，而是“扫出来之后，怎么让位置信息还能对上原始文件行号列号”——这点容易被忽略，一上来就硬扫，后面定位报错就全偏了。
