应改用 std::from_chars 或手写解析替代 std::stoi，读行后清理尾部控制符，单行细粒度 try-catch 并记录错误，显式设置文件缓冲区并限制行长。
读取日志时遇到 std::stoi 抛 std::invalid_argument 怎么办
直接用 std::stoi 解析日志里的数字字段，只要碰到空格、字母、乱码或空字符串，立刻崩——它不接受“尽力而为”，只认严格格式。这不是 bug，是设计使然。
实际日志里常见："user_id=abc"、"duration= 12ms"、"status= "。这些都该跳过或默认处理，而不是让整个解析流程中断。
- 改用
std::from_chars（C++17 起）：它不抛异常，返回状态码，且跳过前导空白，能处理部分有效字符（比如"123abc"中的123） - 若需兼容旧标准，手写简易解析：用
std::stringstream配合failbit检查，或遍历字符串手动判断数字字符 - 别在循环里反复构造
std::stringstream实例——开销大；复用一个对象并调用clear()+str()更稳
日志行末尾有 \r\n、\0、多余空格，导致 std::getline 后 substr 错位
std::getline 默认按 \n 切，但 Windows 日志常带 \r\n，某些设备日志甚至混入 \0 或不可见控制符。这时候 line.size() 看似正常，实际末尾藏了脏字节，line.substr(pos) 一截就偏。
- 读完每行后立即清理：用
line.erase(line.find_last_not_of(" \t\r\n\0")+1)去掉所有尾部空白和控制符 - 避免用
line.c_str()直接传给 C 风格函数（如strtol），因为\0可能出现在中间，提前截断 - 如果日志来自嵌入式设备，优先用
std::vector<char></char>配合read()读固定长度，再手动找行边界，比依赖getline更可控
try-catch 放在哪？捕获 std::exception 还是具体类型
把整个日志循环包进一个大 try 块里，等于放弃恢复能力——出一次错，后面几百行全丢。而捕获太宽泛的 std::exception，又容易吞掉本该中止的严重错误（比如内存耗尽）。
立即学习“C++免费学习笔记（深入）”；
- 只对**单行解析逻辑**做细粒度
try：每行单独try，出错就continue，不影响下一行 - 捕获具体异常：如
std::invalid_argument、std::out_of_range（stoi可能抛），不捕std::exception全集 - 绝不在
catch里静默吞错：至少打日志，记录行号和原始内容片段，否则脏数据会变成“幽灵丢失”
用 std::ifstream 读大日志文件时，为什么越读越慢甚至卡死
不是磁盘慢，是默认缓冲区太小，或者频繁 seekg / peek 导致底层反复系统调用。更隐蔽的是：某些日志包含超长行（比如 base64 堆积），std::getline 会不断扩容内部 buffer，触发多次堆分配。
- 显式设置缓冲区：
std::ifstream file; file.rdbuf()->pubsetbuf(buffer, bufsize);，buffer用new char[64*1024]，bufsize设为 65536 - 避免在循环内调用
file.tellg()或file.peek()——它们可能强制刷新缓冲区 - 对疑似超长行加长度限制：读之前先用
file.read(&c, 1)单字节试探，累计计数，超 1MB 就跳过整行（用file.ignore(...)）
真正麻烦的从来不是某一行解析失败，而是你没意识到：同一份脏数据，在不同编译器、不同 C++ 标准库实现下，std::stoi 和 std::from_chars 的容忍边界可能差一个字符。上线前得拿真实日志样本，在目标环境跑一遍解析覆盖率统计。
