用std::ifstream读C++源码应逐字符读取而非operator>>，需处理BOM、行尾、注释、字符串字面量（含转义与原始字符串）及token缓存优化。
用 std::ifstream 读取源码文件时，别直接用 operator>>
读 C++ 源码不是读纯数字或单词列表，空格、换行、注释、字符串字面量里的内容都影响语义。用 operator>> 会跳过所有空白符（包括换行），且无法区分 int x; 和 intx; —— 它俩被读成同一个 std::string “intx”。
正确做法是逐字符读取：
- 用
std::ifstream::get()或std::istream::peek()保证不跳过任何字符 - 手动缓存当前字符序列，根据状态机决定何时切分出一个 token
- 特别注意：Windows 行尾
）需提前跳过，否则第一个 token 可能带乱码
写简单 lexer 时，优先处理 // 和 /* */ 注释再进主循环
注释不是 token，但会影响后续解析。比如 int/*a*/x; 应拆为 int、x、;，中间注释必须完全跳过，且不能误吞掉后面的 /（如 /= 是一个运算符）。
建议在读到 / 后立刻判断下一个字符：
立即学习“C++免费学习笔记（深入）”；
token-tracker-daily
下载
Token 消耗追踪工具。当用户需要监控 API token 使用情况、生成每日/每周消耗报告、分析使用趋势时使用此 Skill。功能包括：自动记录每次对话的 token 消耗、生成数据表格报告、计算使用趋势和预测、支持定时推送日报。
- 若下一个是
/→ 跳到行尾（读到 - 若下一个是
*→ 循环读直到匹配*/，注意支持跨行和嵌套注释不合法（C++ 不支持嵌套） - 否则，这个
/就是除法或/=的起始，留到运算符逻辑里处理
std::string 存 token 值，但别用 std::vector<std::string> 存全部 token
大量小字符串反复分配内存会拖慢速度，尤其处理大文件（>1MB）时明显。Clang 和 GCC 的 lexer 都用 arena allocator 或 string view + 源文件整体映射来避免拷贝。
实操建议：
- 先用
mmap（Linux/macOS）或CreateFileMapping（Windows）把整个文件映射进内存，所有 token 用std::string_view指向原地址 - 如果必须用
std::string，至少预分配足够空间：file_content.reserve(file_size) - token 类型建议用 enum class 区分，比如
enum class TokenType { IDENTIFIER, INT_LITERAL, PLUS, SEMICOLON, ... }，别全靠字符串比较
遇到 "hello "world"" 这种字符串字面量，状态机要进 IN_STRING 模式
双引号内的内容不是独立 token，整个 "..." 是一个 STRING_LITERAL token。难点在转义序列："、\、
等必须识别但不结束字符串；而未转义的换行或 EOF 直接报错。
典型漏点：
- 没处理八进制（
S）和十六进制（）转义，导致 token 值错误 - 把
R"(raw string)"这种原始字符串字面量当成普通字符串处理（它里面没有转义） - 忽略 u8/u/U/L 前缀，如
u8"中文"应标记为 UTF-8 字符串，而非普通字符串
真正写严整的 C++ tokenizer，光处理字符串字面量就得覆盖十几种边界情况。实际项目中，除非练手，否则建议用 clang::Lexer 或 libtooling 接口——自己写的 lexer 很难通过 __cplusplus 宏或模板特化等复杂语法校验。
