结论：手写C++词法分析状态机的核心是每个状态必须明确回答“是否吃字符、下一状态、是否emit token”，缺一即导致死循环或漏词；需预分类字符、用peek/consume分离读取与消费、绑定token生成与状态退出、安全处理string_view生命周期，并实现错误恢复跳转。
直接说结论：用纯 C++ 手写词法分析状态机，核心不是“跳转逻辑多酷”，而是每个状态必须明确回答“当前字符该不该吃？下一个状态是什么？要不要 emit token？”——漏掉任一判断，while 循环就会卡死或漏词。
为什么不能靠 switch (state) + if (c == 'x') 硬编码所有跳转
真实脚本词法（比如类 Lua 的轻量语法）里，空格、换行、注释、数字前导零、字符串转义、十六进制字面量这些场景，会让分支爆炸。硬编码会迅速失控，且无法处理 '\n' 和 '\r\n' 行尾差异、Unicode 字母判定等边界。
实操建议：
- 把字符分类预计算好：
is_digit(c)、is_id_start(c)、is_whitespace(c)，返回枚举值（如CHAR_DIGIT），而不是在每个case里重复std::isdigit - 状态跳转表用二维数组或
std::map<:pair charclass>, Transition></:pair>，避免嵌套if-else堆叠 - 拒绝“读一个字符判一次”的写法；改用
peek()+consume()分离“看”和“吃”，否则回退逻辑（如0x123G中的G）极易出错
Token 生成时机必须和状态退出强绑定
常见错误现象："123abc" 被切分成 NUMBER(123) 和 IDENTIFIER("abc")，但实际解析器期望的是 NUMBER(123) + IDENTIFIER("abc") —— 这没问题；但如果 "123.45" 被切成 NUMBER(123) + DOT + NUMBER(45)，就彻底错了。
立即学习“C++免费学习笔记（深入）”；
关键点：
- 只有状态明确“终结”时才 emit
Token，例如从STATE_NUMBER_DECIMAL退出到STATE_START，才产出完整浮点数；若还在STATE_NUMBER_DECIMAL_FRACTION就 emit，会切碎 - 字符串字面量中遇到未闭合引号（
"hello），必须在 EOF 处强制 exit 并报错，不能静默吞掉剩余输入 -
COMMENT类型 token 通常不参与后续语法分析，但必须 consume 掉全部内容（包括嵌套注释的终止符），否则下个 token 位置偏移会错
如何安全处理 std::string_view 生命周期与 token 内容存储
很多实现直接存 std::string_view{src.data() + start, len}，看似零拷贝，但一旦输入缓冲区（如 std::string）被移动、释放或 resize，所有 string_view 全变悬垂指针。
实操方案选其一：
- 简单脚本场景：token 内容统一存
std::string（哪怕只是"+"），用token.text = std::string{first, last}；内存开销可控，杜绝悬挂 - 高性能需求：lexer 输入必须是 stable storage（如
std::vector<char></char>持有完整源码，且生命周期长于所有 token），再用string_view - 绝对不要用
std::string_view指向栈上临时std::string，比如parse_number() { std::string tmp = "..."; return string_view{tmp}; }
最易被忽略的点：状态机没有“全局错误恢复”能力。遇到 0xGG 这种非法十六进制，不能只报错然后停在原地——要跳到最近的 STATE_START 并 consume 至下一个空白或换行，否则整个文件后续全乱。这个“跳过坏字符直到安全位置”的逻辑，比跳转表本身更难测全。
