_read/_write比fread/fwrite慢因无缓冲、频繁系统调用；性能提升关键在自管缓冲区，推荐64KB–256KB对齐页大小，需检查返回值、循环写入、避免栈分配与句柄混用。
为什么 _read 和 _write 复制文件比 fread/fwrite 慢？
因为 _read 和 _write 是底层 POSIX 风格接口（Windows 上是 CRT 封装），默认无缓冲，每次调用都触发一次系统调用。而 fread/fwrite 自带用户态缓冲，能批量吞吐数据，减少内核态切换开销。
但如果你已经决定用 _read/_write（比如要绕过 FILE* 层、做细粒度控制、或对接已有低层 I/O 逻辑），那唯一能提升性能的点就是——自己管好缓冲区大小。
- 缓冲区太小（如 1KB）：系统调用频次高，CPU 花在上下文切换上的时间远超实际拷贝
- 缓冲区太大（如 1MB）：可能触发缺页中断、占用过多栈/堆空间，且对小文件反而更慢
- 典型甜点区间是 64KB–256KB，在大多数 Windows 和 Linux 系统上实测吞吐较稳
怎么设置合理的缓冲区大小并避免内存越界？
缓冲区必须是 malloc 或 _aligned_malloc 分配的可读写内存块，不能用栈数组（大缓冲易栈溢出），也不能用未初始化指针。
关键细节：
立即学习“C++免费学习笔记（深入）”；
-
_read返回值可能小于请求长度（尤其在 EOF 或设备忙时），必须检查返回值，不能直接拿nBytes当有效数据长度用 -
_write同样可能只写出部分字节，需循环调用直到全部写完，否则文件损坏 - 缓冲区大小建议设为 4096 的整数倍（对齐页边界），某些 SSD 或文件系统在对齐访问时有额外优化
- 示例中用
65536（64KB）是兼顾兼容性与性能的常见选择：char *buf = (char *)_aligned_malloc(65536, 4096);
Windows 下 _read/_write 复制大文件的典型陷阱
Windows CRT 的 _read 对普通文件句柄行为正常，但遇到重定向句柄（如管道、stdin）、网络句柄或某些加密卷时，可能返回 -1 并设 errno = EBADF 或 EINVAL，不是所有句柄都支持。
- 务必用
_get_osfhandle检查句柄是否来自CreateFile，避免混用 C 运行时句柄和 Win32 句柄 - 复制超过 4GB 文件时，
_read返回int，无法表达 >2GB 单次读取（虽然实际不会读那么大），但累计偏移要用__int64计算，别用int或long存总长度 - 若源文件被其他进程独占打开（如 Excel 正在编辑 .xlsx），
_read可能立即返回 0，而非阻塞——这不是 bug，是 Windows 文件共享策略所致
要不要加 FILE_FLAG_NO_BUFFERING？
不要轻易加。这个标志要求：缓冲区地址 512 字节对齐、传输大小是扇区大小（通常 512 或 4096）整数倍、文件偏移也必须对齐。一旦不满足，_read 直接失败并设 errno = EINVAL。
它只在极少数场景有用：比如你正在实现数据库日志写入，需要绕过系统缓存确保落盘顺序。普通文件复制不仅没收益，反而大幅增加出错概率。
- 开启后，
_read不再自动处理“部分读”，哪怕只剩 1 字节也要读满一个扇区，容易读到脏数据 - 关闭系统缓存意味着每次读都走磁盘，SSD 寿命和延迟都会明显上升
- 绝大多数情况下，靠用户态缓冲 + 默认系统缓存组合，性能已接近理论上限
真正难搞的从来不是缓冲区数字本身，而是跨平台时 Windows 的 _read 和 Linux 的 read 对中断信号（EINTR）的处理差异，以及大文件偏移在 32 位环境下的截断风险——这些地方一漏，程序就静默出错。
