CFile打开失败不报错因默认不抛异常且易忽略返回值；需检查Open()返回值、立即调用GetLastError()、处理Unicode路径、避免共享冲突；它不分文本/二进制模式，安全读写文本应改用CStdioFile。
为什么 CFile 打开文件失败却没报错？
因为 CFile 默认不抛异常，Open() 返回 BOOL，但很多人直接忽略返回值，或只检查 GetLastError() 却忘了它只在失败时有效。更常见的是路径含中文、权限不足、文件被占用，而 CFile 不会自动转码或提示具体原因。
- 务必检查
CFile::Open()的返回值：if (!file.Open(_T("data.bin"), CFile::modeRead)) { /* 处理失败 */ } - 失败后立即调用
GetLastError()，不是file.GetStatus()—— 后者只对已打开的文件有效 - 路径中含 Unicode 字符时，确保用
_T()包裹字符串，并确认项目字符集设为“使用 Unicode 字符集”（非“多字节”） - 避免用
CFile::shareDenyWrite打开正在被其他进程写入的日志文件，改用CFile::shareCompat或CFile::shareDenyNone
CFile 读写二进制和文本的区别在哪？
它根本**不区分**文本/二进制模式 —— CFile 始终按原始字节操作。所谓“文本模式”是 CStdioFile 的行为，CFile 没有换行符自动转换、没有 EOF 截断逻辑。误用 CFile 读取文本常导致中文乱码或读不完最后一行，本质是编码没处理，不是模式问题。
- 读写纯二进制数据（如图片、结构体）：直接用
Read()/Write()，安全 - 读写文本：别硬扛，改用
CStdioFile，它封装了fgets行为，支持ReadString() - 若坚持用
CFile处理 UTF-8 文本，需手动分配足够缓冲区、用Read()读整块再转码，不能依赖“一行一读”
如何安全地用 CFile 替代 fopen？
核心是补全 fopen 隐含的细节：CFile 不自动创建目录、不处理路径分隔符斜杠方向、不管理文件指针偏移的隐式重置。直接替换常导致“找不到路径”或“读到旧数据”。
- 路径中用正斜杠
/或双反斜杠\，单反斜杠是非法转义 - 父目录不存在时，
CFile::Open()直接失败；需先调用GetCurrentDirectory+CreateDirectory手动建路径 - 多次读写前，显式调用
Seek(0, CFile::begin)重置位置，CFile不像fopen("r+")那样默认从头开始 - 写入后必须调用
Flush()，否则缓冲区内容可能未落盘，尤其在异常退出时易丢数据
CFile 在 MFC DLL 中使用要注意什么？
静态链接 MFC 时没问题；但动态链接（/MD）下，CFile 内部依赖的 C 运行时文件句柄表与主程序不共享，DLL 中打开的文件在主程序里不可见，且 DLL 卸载后句柄可能泄漏。
立即学习“C++免费学习笔记（深入）”；
- DLL 导出函数若返回
CFile*，调用方必须用同一套 CRT 关闭（极危险），建议改为传入已打开的HANDLE或使用内存映射 - 避免在 DLL 的
InitInstance中全局构造CFile对象，MFC DLL 初始化顺序不稳定，可能导致AfxGetApp()为空 - 调试时注意：Release 版因优化可能跳过
CFile析构函数中的Close()，务必显式调用Close()
实际用起来最麻烦的从来不是 API 调用本身，而是路径合法性、错误码捕获时机、以及 DLL 场景下的资源生命周期 —— 这些地方一漏，问题就藏得深，日志还看不出端倪。
