windows下fstream读写>2gb文件失败，因msvc默认链接旧crt导致32位偏移截断；应改用_fseeki64/_ftelli64、createfile+setfilepointerex，或全程统一i/o范式。
fstream 在 Windows 上读写 >2GB 文件为什么会失败
默认编译下，std::fstream 底层调用的是 32 位偏移的 _lseek 或 fseek，即使你用 seekg/seekp 传入 std::streamoff（通常是 long long），Windows CRT 仍可能截断高 32 位——表现为文件指针跳转错乱、read() 返回 0、eof() 提前触发。
这不是 C++ 标准问题，是 MSVC 默认链接旧版 CRT 的行为；Linux/glibc 下通常无此限制（off_t 默认 64 位）。
必须启用 _FILE_OFFSET_BITS=64 和 /D"_CRT_SECURE_NO_WARNINGS"
仅加 /D"_USE_32BIT_TIME_T" 没用，关键在两处：
- 编译时定义
_FILE_OFFSET_BITS=64（MSVC 不原生支持该宏，但需等效操作） - 链接时强制使用支持大文件的 CRT 版本：VS2015+ 默认已支持，但必须关闭“SDL 检查”并确保未手动链接
libcmt.lib等旧库 - 更稳妥的做法：用
std::ios_base::ate | std::ios_base::binary打开，避免依赖seekp(0, std::ios::end)计算大小（该调用在旧 CRT 下极易出错）
用 _fseeki64 + _ftelli64 替代标准流定位（最稳方案）
绕过 fstream 的封装，直接操作底层 FILE* 句柄。虽然失去 RAII，但对超大文件控制更精确、行为可预测。
实操步骤：
- 用
fopen打开文件，模式加"b"（如"rb"） - 用
_fseeki64(fp, offset, SEEK_SET)定位，offset类型为__int64 - 用
_ftelli64(fp)获取当前位置，返回__int64 - 读写仍用
fread/fwrite，别混用fstream::read
示例片段：
FILE* fp = fopen("huge.bin", "rb");
if (fp) {
_fseeki64(fp, 3000000000LL, SEEK_SET); // 跳到 3GB 处
char buf[4096];
size_t n = fread(buf, 1, sizeof(buf), fp);
__int64 pos = _ftelli64(fp); // 正确拿到 3GB+ 偏移
fclose(fp);
}
用 CreateFile + SetFilePointerEx（Windows 原生 API）
当需要精确控制缓存、重叠 I/O 或处理稀疏文件时，C Runtime 层已不够用。Windows 原生 API 天然支持 64 位偏移。
注意点：
-
CreateFile必须指定FILE_FLAG_NO_BUFFERING（若需对齐读写）或至少FILE_ATTRIBUTE_NORMAL -
SetFilePointerEx的lpDistanceToMove是LARGE_INTEGER，直接支持 64 位 - 不能和
stdio函数混用同一文件句柄（会破坏内部缓冲区状态） - 记得用
CloseHandle，不是fclose
关键调用示例：
HANDLE h = CreateFile(L"bigfile.dat", GENERIC_READ, 0, nullptr, OPEN_EXISTING, 0, nullptr);
if (h != INVALID_HANDLE_VALUE) {
LARGE_INTEGER li;
li.QuadPart = 5000000000LL; // 5GB
SetFilePointerEx(h, li, &li, FILE_BEGIN);
DWORD read;
ReadFile(h, buf, sizeof(buf), &read, nullptr);
CloseHandle(h);
}
真正容易被忽略的是：哪怕用了 _fseeki64，如果之前用 fstream 打开过这个文件，再用 fileno() 取句柄去调 _fseeki64，依然可能因缓冲区不同步导致位置错乱。最干净的做法是——从头到尾只用一种 I/O 范式，别交叉。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
