<p>tokenize.tokenize() 读取字节流而非字符串，因其需模拟 Python 解释器底层词法扫描器，依赖原始字节以准确识别编码声明（如 # -- coding: utf-8 --）并按 PEP 263 自动解码；传入字符串会触发 TypeError。</p>
tokenize.tokenize() 为什么读取字节流而不是字符串？
因为 tokenize.tokenize() 的设计初衷是模拟 Python 解释器的底层词法扫描器，它要求输入为 bytes 或支持 readline 方法的类文件对象。直接传入 str 会报 TypeError: tokenize() argument must be a bytes object。
常见错误是用 open(file).read() 得到字符串后直接传给 tokenize.tokenize() —— 这会立刻失败。
- 正确做法：用
open(file, 'rb')打开文件，保持二进制模式 - 若已读取为字符串，需先编码：用
source.encode('utf-8')转为bytes，再用io.BytesIO()包装 - 注意源码编码声明（如
# -*- coding: gbk -*-）会影响解码逻辑，tokenize会自动识别并处理，但前提是输入确实是原始字节流
如何安全遍历 token 并避免 StopIteration 异常？
tokenize.tokenize() 返回一个迭代器，当遇到文件结尾或语法错误时，会生成一个 ENDMARKER token 后停止。但如果输入流提前耗尽（比如空文件、损坏字节），可能抛出 StopIteration —— 这不是 bug，而是迭代器协议的一部分，但容易被忽略。
实际使用中不应依赖 for token in tokenize.tokenize(...) 无条件循环，尤其在处理不可信输入时。
立即学习“Python免费学习笔记（深入）”；
- 推荐用
try/except StopIteration包裹单次__next__()调用（适合精细控制） - 更稳妥的是用
itertools.takewhile截断到token.ENDMARKER为止 - 注意：每个 token 是
tokenize.TokenInfo实例，字段顺序固定：type, string, start, end, line；不要按索引取值，应始终用属性名（如t.string）
COMMENT 和 NL token 的区别与实际意义
很多人以为注释只对应 COMMENT，但 Python 的换行处理会让 NL（Non-Logical Newline）和 NEWLINE 都参与缩进判断。漏掉 NL 可能导致缩进解析错位。
NL 出现在续行符 \ 后、三引号字符串中间、或未触发语句结束的换行处；而 NEWLINE 标志逻辑行结束。两者都影响 AST 构建，但在简单词法统计中常被忽略。
-
COMMENT的t.string包含#及之后全部内容（含末尾换行符） -
NL的t.string就是换行符本身（'\n'或'\r\n'），位置信息（t.start）对格式检查很重要 - 过滤时别写
t.type != tokenize.COMMENT就完事——如果目标是“非代码内容”，还得排除NL和ENCODING
如何提取所有标识符而不误抓关键字？
想提取变量名、函数名等标识符，不能只看 NAME 类型 token，因为 Python 关键字（如 if、def）也属于 NAME 类型。必须结合 tokenize.NAME 和 keyword.iskeyword() 二次判断。
另外，PEP 8 规定下划线开头的名称有特殊含义（私有、魔法方法），是否纳入结果取决于用途，但 tokenize 本身不区分这些语义。
- 用
import keyword，然后if t.type == tokenize.NAME and not keyword.iskeyword(t.string) - 注意：Python 3.7+ 新增的
async和await在某些上下文中是关键字，在另一些（如字符串内）不是，keyword.iskeyword()已正确覆盖 - 不要用正则匹配
[a-zA-Z_][a-zA-Z0-9_]*替代 token 检查——无法处理 Unicode 标识符（如中文变量名）
真正麻烦的不是怎么拿到 token，而是理解每个 token 的边界何时由物理行决定、何时由逻辑行决定。比如括号跨多行时，NL 和 NEWLINE 的分布直接影响缩进恢复逻辑。没在真实代码里跑过几轮 token 流，很难意识到 start 和 end 元组里的列偏移是相对于当前行首，而不是整个文件。
