text/scanner 扫描后 token 文本为空，是因为未在 scan 成功后立即调用 tokentext() 获取原始字面量；输入需为有效 io.reader，且非法字符需通过 errorhandler 捕获定位。
text/scanner 扫出来的 token 总是空？检查 Scan 后是否调用 TokenText
很多人用 text/scanner 时发现 Scan 返回了非零值，但打印出来却是空字符串。根本原因：扫描器只移动位置、记录类型，不自动缓存文本内容。TokenText 才是真正从源数据里切出原始字面量的方法。
常见错误现象：scanner.Scan() 返回 token.IDENT，但直接 fmt.Println(scanner.TokenText()) 却输出空——其实是没把输入源设对，或忘了在 Scan 后立刻调用它。
- 必须在每次
Scan成功后立即调用TokenText()，不能缓存多次扫描结果再统一取 - 输入必须是
io.Reader（比如strings.NewReader("x := 1")），传nil或未初始化的 reader 会导致静默失败 -
Scanner默认跳过空白和注释，如果想保留换行/制表符，得手动设置Mode：s.Mode = scanner.ScanComments | scanner.SkipComments（注意：二者互斥）
为什么 text/scanner 不支持自定义关键字？它压根不是 parser
text/scanner 是词法扫描器（lexer），只做字符到 token 的映射，不理解语义。它内置的 token 类型（如 token.IDENT、token.INT）是固定的，不会因为你加了 "await" 就自动识别成关键字。
使用场景：适合写轻量 DSL、配置文件解析、教学用解释器前端；不适合替代 go/parser 或构建完整编译器。
立即学习“go语言免费学习笔记（深入）”；
- 若需识别自定义关键字（比如把
"def"当作函数声明），得在扫描后自己比对TokenText()结果，再映射为自定义 token 常量 - 别试图通过修改
scanner源码或反射去“注入”关键字——它没预留扩展点，改了也白改 - 性能上，
text/scanner是纯前向读取，无回溯，所以无法处理需要上下文判断的 token（如 Python 的缩进、Go 的import (后多行导入）
遇到 token.ILLEGAL 却没报错位置？启用 ErrorHandler
text/scanner 遇到非法字符（比如 UTF-8 编码损坏、不可见控制符）默认吞掉错误，只返回 token.ILLEGAL，连行号列号都不暴露。这对调试极其不友好。
解决办法是给扫描器装上 ErrorHandler 回调：
func handleError(s *scanner.Scanner, msg string) {
fmt.Printf("line %d, col %d: %s\n", s.Line, s.Column, msg)
}
s := &scanner.Scanner{}
s.Init(strings.NewReader(src))
s.Error = handleError
-
s.Line和s.Column只有在Error被触发时才可靠；平时它们反映的是上一个 token 结束位置，不是当前扫描点 - 别依赖
msg的具体格式——它可能随 Go 版本变，只建议用于日志，不用于逻辑分支 - 如果输入含 BOM（如 UTF-8 with BOM），
text/scanner会把它当非法字符扫成token.ILLEGAL，提前用bytes.TrimPrefix去掉更稳妥
用 text/scanner 写解释器时，最容易被忽略的是 token 边界处理
比如输入 "foo123bar"，text/scanner 默认会拆成 IDENT("foo123") + IDENT("bar")，但它其实根本不知道 "123" 是数字还是标识符后缀——全靠你后续逻辑判断。
这导致很多新手写的计算器或简单脚本解释器，在变量名含数字、浮点数带指数（1e5）、字符串含转义（"\n"）时突然崩掉。
-
text/scanner对浮点数的支持很基础：只认123.45、.123，不认1e+5或0x1p-3，这些都会被切成多个 token - 字符串字面量只处理基本引号配对，不展开 Unicode 转义（
"\u0061"还是原样字符串），也不校验内部合法性 - 如果你要支持类似 Go 的 raw string（
`...`），得自己识别起始反引号，并跳过中间所有内容直到下一个反引号——text/scanner完全不管这个
边界模糊的地方，永远要靠你自己的状态机补足，而不是指望扫描器“聪明”。
