词法分析器的核心任务是将源代码字符流按规则切分为有意义的token（如关键字、标识符、运算符等），并输出含类型、属性值和行号的token序列，不负责语义判断或语法合法性检查。
词法分析器的核心任务是什么
词法分析器（Lexer）不负责理解语义，只做一件事：把输入的字符流切分成有意义的token，比如把 int x = 42 + y; 拆成 INT、ID、ASSIGN、NUMBER、PLUS、ID、SEMI。关键在于「按规则切分」，而不是「判断是否合法」——语法错误留给后续的 parser 处理。
用 std::string_view 和状态机实现基础 Lexer
避免频繁拷贝字符串，用 std::string_view 配合游标（pos）移动；不用正则库，手写简单状态机更可控、更易调试。常见坑是忽略空白符跳过逻辑、数字后紧跟字母未报错、字符串字面量没处理转义。
- 从左到右扫描，每次调用
next_token()返回一个struct Token { TokenType type; std::string_view lexeme; int line; };</li> <li>遇到空格、<code>\t、\n直接跳过，但要更新line计数器 - 识别
NUMBER时，允许前导-，但禁止123abc这种混杂——读到非数字就停，后续字符留给下一轮处理 -
ID和关键字（如if、while）共享同一段逻辑：先读出标识符，再查表匹配；注意ifx不是关键字，不能误判 - 单行注释
//要吃掉直到换行，但换行符本身仍需计入line++
switch 分支怎么处理多字符操作符
像 ==、!=、=> 这类操作符必须「向前看一位」，否则会把 == 错切成两个 =。不能只靠当前字符决定 token 类型。
- 读到
=后，检查view[pos+1]是否为=；是则返回EQ，否则返回ASSIGN -
<后可能是<=或<<，需分别判断；<<常见于模板或流操作，但词法层不区分用途，统一视为SHL即可 - 遇到
/要立刻判断：后面是/就进单行注释，是*就进块注释，否则才是除号SLASH - 所有「向前看」操作前必须检查
pos + 1 < view.size()，越界直接按单字符处理
为什么不用 std::regex 做词法分析
std::regex 在 C++11 中性能差、构造开销大，且无法自然支持「最长匹配」和「位置追踪」（比如哪一行、哪个列）。真实项目中，手写 lexer 通常比正则快 3–10 倍，也更容易加断点调试。
立即学习“C++免费学习笔记（深入）”；
- 正则难以表达「跳过空白但保留换行计数」这类混合行为
- 多个正则模式并行匹配时，C++ 标准库不保证优先级顺序，容易漏匹配或错序
- 错误定位困难：正则失败时只告诉你「不匹配」，但不知道卡在第几个字符、哪条规则
- 若真要用正则，至少用
std::sregex_iterator扫描，但依然得手动维护line和col，反而更重
最易被忽略的是换行计数时机：必须在跳过 \n 的**同时**执行 line++，而不是等整个 token 构造完再算——否则注释、字符串跨行时行号就全偏了。
