fscanf易读错或崩溃因不检查缓冲区边界、格式不匹配时指针错位且未限制字符串宽度；应改用fgets+sscanf组合，确保安全可控。
用 fscanf 读结构化文本时，为什么总读错或崩溃？
因为 fscanf 默认不检查缓冲区边界，遇到格式不匹配、空格/换行异常、字段缺失时，会把指针留在错误位置，后续调用直接读脏数据甚至越界。尤其读字符串（%s）或字符数组时，没加宽度限制等于裸奔。
- 常见错误现象：
fscanf返回值突然变小（比如期望读 3 个字段却只返回 1），之后所有读取全乱；char buf[32]配%s导致栈溢出 - 必须检查返回值：它返回成功赋值的项数，不是字节数 ——
if (fscanf(fp, "%d %s", &id, name) != 2)才算读完整一行 - 字符串务必加宽度：写成
%31s（留 1 字节给\0），否则fscanf会一直读到空白符，不管目标数组多小 - 跳过空白行为不可靠：Windows 的
\r\n和 Unix 的\n在格式串中表现一致，但若文件混用换行符，%d%*c%s这类“吃掉一个字符”的写法极易误吞字母
fscanf_s 真的安全吗？哪些参数必须改？
不安全 —— 它只是微软在 MSVC 下对 fscanf 的“带宽检查”补丁，不是 C 标准函数，跨平台代码里用了就废。而且它强制要求所有字符串和宽字符输入都额外传长度参数，漏一个就编译不过。
- 函数签名差异大：
fscanf_s(fp, "%s", buf, sizeof(buf))，第三个参数是缓冲区字节数，不是最大读取数（%31s中的 31） - 只在 Windows + MSVC 生效；GCC/Clang 下直接报错未声明，连编译都过不了
- 数字类型（
%d、%f）不用改，但字符串、字符数组、%c、%[全部要加长度参数，漏一个就触发断言失败或崩溃 - 和
fscanf混用极危险：同一份代码里既有fscanf_s又有fscanf，容易因忘记改参数导致内存踩踏
真正靠谱的替代方案：用 fgets + sscanf 组合
先整行读入，再解析，彻底规避格式串与文件流状态耦合的问题。哪怕某行格式错，也只影响当前行，不会污染后续读取位置。
- 用
fgets(line, sizeof(line), fp)保证不越界，它会把换行符也读进来（或截断），比fscanf的“自动跳过空白”更可控 - 解析时用
sscanf(line, "%d %31s %f", &id, name, &score)，依然要加字符串宽度，但此时目标缓冲区确定、无流状态干扰 - 能轻松处理“注释行”或“空行”：
if (line[0] == '#' || line[0] == '\n')直接跳过，fscanf做不到这点 - 性能影响微乎其微：现代磁盘 IO 瓶颈远大于内存解析，且
fgets是缓冲读，实际比反复调用fscanf更快
读 CSV 或固定列文本时，别硬刚 fscanf 格式串
CSV 里的逗号可能被引号包着，固定列文本可能含空格，用 fscanf 写 %[^,],%[^,] 这类格式串极易被数据内容反杀 —— 比如名字里有逗号、数值里带空格，解析当场失效。
立即学习“C++免费学习笔记（深入）”；
- 简单 CSV：用
fgets读整行，再用strtok_s（Windows）或strtok_r（Linux）按分隔符切，每段再用strtol/strtod转数字 - 固定列（如 10 字符 ID + 20 字符 NAME + 8 字符 SCORE）：直接用
memcpy截子串，比格式化读更稳，还能用std::string_view避免拷贝 - 真要格式化：C++ 里优先用
std::ifstream+std::getline+std::istringstream，比 C 风格函数更难出错，且支持异常控制
最麻烦的不是语法怎么写，而是 fscanf 的错误会静默污染文件指针位置 —— 你改了某处格式串，可能让后面十行全读歪。动手前先想清楚：这数据格式真的稳定吗？有没有可能某天多一列、少一列、字段里塞个空格？这时候，宁可多写两行 fgets，也别赌 fscanf 的运气。
