用 enum class State 定义状态，std::vector 存转移函数，逐字符驱动、零拷贝 Token 设计（const char* + length），关键字查表用 constexpr array 二分查找，数字/字符串/注释等状态需正确处理边界与转义。
如何用C++写一个不依赖第三方库的Token分词状态机
直接说结论：用 enum class State 定义状态，std::vector<:function>></:function> 存转移函数，比硬编码 switch-case 更易维护，也比查表法更直观。核心不是“画状态图”，而是让每个字符触发明确的状态变更和可选的Token产出。
常见错误是把“读到数字就进数字状态”写成单层 if 判断，结果遇到 123abc 时只吐出 123 就卡住，漏掉后续标识符；或者在注释状态里没跳过换行符，导致整行被吞掉。
- 起始状态（
State::INIT）对空格、制表符、换行符直接跳过，不生成 Token - 遇到
/后立刻检查下一个字符：是/进单行注释状态，是*进多行注释状态，否则回退并输出除号 Token - 字符串字面量状态中，必须处理转义序列（如
\"），否则遇到"hello\"world"会提前终止 - 所有状态都需处理 EOF（
std::char_traits<char>::eof()</char>），避免无限循环
为什么不能用 std::string::find 来做关键字匹配
因为词法分析是流式处理，不是全文搜索。用 find 意味着你得先把一整块字符读进来再切片判断，既破坏了状态机的逐字符驱动逻辑，又无法处理跨缓冲区边界的情况（比如关键字 while 被切在两个 read() 调用之间）。
实际做法是：进入标识符状态后，边读字符边累积到 std::string token_buffer，一旦遇到非标识符字符（比如 +、空格、;），立即停止累积，然后拿 token_buffer 去查关键字表（std::unordered_set<:string></:string> 或静态数组二分查找）。
立即学习“C++免费学习笔记（深入）”；
- 关键字表建议用
constexpr std::array配合std::binary_search，编译期确定，无内存分配 - 别用
std::map查关键字——插入和查找都是 O(log n)，而关键字数量固定且极少（通常 - 注意大小写：C++ 关键字全小写，但用户标识符区分大小写，查表前先确认当前 token 是否全由字母/下划线/数字组成且首字符合规
如何正确处理十六进制和浮点数字面量的歧义
关键在于“推迟判断”：读到 0x 或 0X 后进十六进制状态，之后只接受 0-9a-fA-F；读到小数点或 eE 后，才决定是否转入浮点状态。不能一看到 . 就认定是浮点——123. 是合法整数字面量（C++17 起允许），必须等到下一个字符是数字或 eE 才确认为浮点。
-
0x123.45是非法的，状态机应在.处报错并截断为0x123 -
123e+4和123E-4都要支持，e后可选+或-，再跟至少一位数字 - 整数后跟
u、U、l、L等后缀需单独识别，它们不属于数字本身，应作为修饰符附加到 Token 类型上（如TOKEN_UINT_LITERAL）
Token 结构体怎么设计才不拖慢性能
别存原始字符串副本。用 const char* + size_t length 指向源代码缓冲区中的子串，配合一个 enum class TokenType 字段。这样每个 Token 只占 16 字节（64 位系统），构造零拷贝，push_back 到 vector 也极快。
示例结构体：
struct Token {
enum class Type {
IDENTIFIER, INT_LITERAL, FLOAT_LITERAL, PLUS, SEMICOLON, EOF_TOKEN
// ...
} type;
const char* start;
size_t length;
int line; // 可选，用于报错定位
};
容易被忽略的是：如果你用 std::string_view 替代裸指针，必须确保源缓冲区生命周期长于所有 Token 对象——在一次性解析场景下没问题，但在增量解析或回调式 API 中，可能引发悬垂引用。
状态机主体循环里，每次成功产出 Token 后，记得更新当前读取位置（ptr 指针或索引），并重置状态为 INIT；只有注释、字符串等复合状态才保持原状态继续推进。
