手写词法分析状态机更可控，因其将每个字符响应逻辑显式拆分为状态分支，避免正则的灾难性回溯；需明确定义token类型、用switch-case驱动enum State流转、用string_view避免深拷贝，并注意换行处理、Unicode支持及关键字查表时机。
为什么手写词法分析状态机比用正则更可控
因为正则在处理嵌套注释、字符串转义、行号追踪等细节时容易失控，而状态机把每个字符的响应逻辑显式拆开，出问题能准确定位到某个状态分支。比如遇到 " 后必须进字符串状态，而不是靠正则回溯匹配——后者在长字符串里可能触发灾难性回溯。
实际写的时候，别一上来就画完整状态图。先列清楚要识别的 token 类型：IDENTIFIER、NUMBER、STRING、COMMENT、OPERATOR（如 +、==）、KEYWORD（如 if、return），再为每类设计进入/退出条件。
如何用 switch-case 实现核心状态流转
用一个 enum State { START, IN_NUMBER, IN_STRING, IN_COMMENT, IN_IDENTIFIER } 配合 char c = input[pos] 做单字符驱动。关键不是“状态多”，而是“每个状态只关心当前字符该做什么”：
-
START状态：跳过空白；遇到/判断下一个是不是/或*；遇到"进IN_STRING；遇到数字进IN_NUMBER；遇到字母或_进IN_IDENTIFIER -
IN_STRING状态：遇到非\的"就结束；遇到\就读下一个字符（不管是什么都吞掉）；遇到换行未闭合就报错 -
IN_COMMENT状态：如果是//就读到行尾；如果是/*就一直读直到遇到*/，注意不能跨行漏判*后跟/
别在状态里做 token 内容拼接——用一个 std::string buffer 在进入状态时清空，每个字符 push_back，退出时用 buffer 构造 Token 对象。
立即学习“C++免费学习笔记（深入）”；
Token 结构体怎么设计才不拖慢性能
避免在每次生成 token 时做深拷贝。字段精简到最低必要：TokenType type（枚举）、int line、int col、std::string_view lexeme（指向原始输入缓冲区的视图）。
示例片段：
struct Token {
TokenType type;
int line;
int col;
std::string_view lexeme; // 不持有所有权，构造时传入 input.data() + start_pos
};
这样 lexeme 只存两个指针，不用分配内存。但代价是：输入字符串生命周期必须长于所有 token 对象——调试时如果临时 std::string s = "x=1;" 然后传给 lexer，token 里的 string_view 会悬垂。
常见坑：换行、Unicode 和关键字识别顺序
换行符不止 \n，Windows 是 \r\n，Mac 旧系统是 \r。状态机里遇到 \r 要检查下一个是 \n，然后统一当一行处理，否则行号会错乱。
如果支持 Unicode 标识符（比如中文变量名），不能只用 isalpha(c) 判断——它只认 ASCII。得用 std::iswalpha(std::btowc(c)) 或直接依赖 ICU 库，但多数脚本语言其实只要求 ASCII 关键字+Unicode 标识符，这时关键字表仍用 ASCII 字符串查，而标识符内容允许宽字符。
关键字必须在 IN_IDENTIFIER 退出后立刻查表。顺序很重要：先收完整个标识符，再拿 buffer 去比对 {"if", "else", "while"}，而不是边读边判断——否则 ifx 会被误判成 if + x。
最易被忽略的是：状态机退出后，pos 指针必须停在下一个待处理字符上。比如识别完 ==，pos 应该指向 = 后面那个字符，不是中间。错一位，后面全乱。
