fgetc读文件前必须检查FILE*是否有效，否则导致崩溃或未定义行为；接收变量必须为int以区分0xFF与EOF；逐字节读取性能差，应优先批量读；跨平台二进制读需注意换行处理与EOF判定。
用 fgetc 读文件前必须检查流是否打开成功
直接调 fgetc 却没验证 FILE* 是否有效，是崩溃或未定义行为的常见源头。C++里混用C风格IO时，这点比C更易被忽略——毕竟C++程序员常默认“std::ifstream 会抛异常”，但 fgetc 不会。
-
fopen返回nullptr时，立刻 return 或 throw，别往下走 - Windows 上用文本模式（
"r"）打开二进制文件，fgetc可能提前遇到0x1A（Ctrl+Z）就返回EOF，改用"rb" -
fgetc返回int，不是char：要能区分0xFF字节和EOF（通常是 -1），所以接收变量必须是int
get() 在 std::ifstream 中怎么避免隐式类型截断
std::ifstream::get() 有多个重载，最常用的是无参版，它返回 int，语义和 fgetc 一致；但新手常写成 char c = ifs.get();，导致 EOF 被截断成 0xFF，后续判断 c == EOF 永远为假。
- 始终用
int c = ifs.get();接收，再判断c == EOF - 如果真要存字节，等确认不是
EOF后再转static_cast<unsigned char>(c)</unsigned> - 注意：用
get(char&)重载时，失败不返回值，而是置位failbit，需检查ifs.fail()，不能靠返回值判断
逐字节读取性能差？别硬扛，该换就换
单次 fgetc 或 get() 调用背后是库级缓冲管理，但频繁调用仍比批量读慢一个数量级。不是所有场景都适合逐字节——比如解析协议头、跳过BOM、找分隔符可以，但解压、转码、哈希计算就不该这么干。
C++ Code Review Master
下载
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
- 用
fread(buf, 1, size, fp)一次读几千字节，再在内存里遍历 -
std::ifstream可用read()+gcount()，比循环get()快 3–5 倍（实测 clang 15 / Linux） - 如果只是跳过前 N 字节，用
fseek(fp, N, SEEK_CUR)或ignore(N)，别傻循环
跨平台读取二进制文件时，fgetc 和 get() 的行为一致吗
底层都是从文件描述符读，行为基本一致，但有两个实际差异点容易翻车：
立即学习“C++免费学习笔记（深入）”；
- 换行处理：Linux/macOS 下
"r"和"rb"对fgetc没区别；Windows 下"r"会把\r\n合成一个\n，而"rb"原样返回两个字节——get()同理，取决于std::ios::binary标志是否设置 - EOF 判定：某些嵌入式 libc（如 newlib）对空文件的
fgetc行为不一致，建议统一用feof()+ferror()双检，而非只信返回值 - Unicode BOM 处理：UTF-8 文件开头的
0xEF 0xBB 0xBF，逐字节读没问题；但若后续交给std::codecvt_utf8，得自己跳过，库不自动识别
字节级 IO 看似简单，真正卡住人的往往是流状态、符号位、平台换行和缓冲策略这四点交叉作用的结果。
