直接手写状态机比正则更可控，因std::regex在上下文敏感场景易回溯爆炸或漏匹配；手写可精确控制字符流转、便于调试与错误恢复。
为什么直接手写状态机比用正则更可控
因为 C++ 标准库不带内建的词法分析器，std::regex 在多模式、上下文敏感（比如字符串字面量里的转义、注释嵌套）场景下容易漏匹配或回溯爆炸；而手写状态机可以精确控制每个字符的流转路径，便于调试、插桩、支持自定义错误恢复。你不需要抽象出完整 lexer 框架，只要从 enum class State 和一个 switch(state) 主循环起步，就能稳住分词逻辑。
next_token() 的核心循环怎么组织才不容易漏状态
关键不是“覆盖所有字符”，而是“只在状态退出时产出 token”。常见错误是边读边产 token，导致空格、换行、注释末尾等“非终结”位置误触发产出。正确做法是：用一个 std::string buf 缓存当前识别中的内容，仅当状态转移到 State::END 或遇到非法字符强制终止时，才根据当前 state 类型构造 Token 并清空 buf。
例如识别数字：
case State::IN_NUMBER:
if (std::isdigit(ch)) { buf += ch; }
else if (ch == '.') {
buf += ch; state = State::IN_FLOAT;
}
else {
emit_token(Token::NUMBER, buf);
state = State::START;
unget(ch); // 把非数字字符推回输入流
}
break;
注意三点：
-
unget(ch)必须存在，否则下一个 token 会丢首字符 - 所有
emit_token调用前必须确保buf已含完整词素，不能依赖后续状态补全 - 状态转移要显式覆盖“默认 fallback”，比如
default: state = State::ERROR;，避免静默跳过非法字符
关键字与标识符怎么区分才不冲突
不能先匹配所有字母数字串再查表判断关键字——那样会把 if 当成标识符再覆盖，增加额外哈希查找且破坏单次扫描原则。应该在 State::IN_IDENTIFIER 结束时，立即用 std::string_view(buf) 查静态关键字表（如 std::unordered_set 或 switch 字符串字面量，C++17 起支持）。
示例片段：
if (is_keyword(buf)) {
return Token{keyword_to_type(buf), buf};
} else {
return Token{Token::IDENTIFIER, buf};
}
这里 is_keyword 必须是 O(1) 查询，否则会拖慢整个 lexer；同时注意大小写敏感性要和目标脚本语言一致（比如 Python 关键字全小写，但变量名可大写）。
容易踩的坑：
- 把
buf传给std::string_view前没确认其生命周期 —— 必须保证buf在Token构造完后才被清空 - 关键字表没包含所有保留字（比如漏了
elif或as），导致语法分析阶段报“unexpected identifier”而非“unexpected keyword” - 标识符允许下划线开头但关键字不允许，这种边界情况要在状态机里提前拦截，而不是靠查表兜底
字符串字面量里的引号转义怎么处理才不崩状态
双引号字符串中遇到 "
" 或 """ 不能简单跳过反斜杠，必须进入 State::IN_ESCAPE 子状态，并严格限制合法转义序列（如
、 、"、\）。否则用户写 "A" 或 "u{61}" 就会卡死或越界读取。
实操建议：
- 用一个
bool in_escape = false辅助标志比新增状态更轻量，但需在每次循环开始检查：if (in_escape) { ...; in_escape = false; continue; } - 对
后字符做白名单判断：if (ch != '"' && ch != '\' && ch != 'n' && ch != 't') { state = State::ERROR; } - 字符串结束必须严格匹配起始引号类型（
"vs'），混用要报错，不能自动闭合
最常被忽略的是换行：未闭合的字符串字面量如果跨行，必须报错并停止，不能默默吞掉换行符继续——这会导致后续所有行偏移错乱，调试器定位行号失效。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
