必须配合OFN_EXPLORER，否则多选失效；获取多选结果需手动解析m_ofn.lpstrFile中NULL分隔的字符串，并用GetFolderPath()拼接完整路径。
设置CFileDialog的OFN_ALLOWMULTISELECT标志必须配合OFN_EXPLORER
不加OFN_EXPLORER，多选会失效——这是最常踩的坑。MFC默认用老式对话框（OFN_ENABLEHOOK隐式启用旧UI），而OFN_ALLOWMULTISELECT只在Explorer风格下才真正生效。
正确做法是显式传入两个标志：
CFileDialog dlg(TRUE, nullptr, nullptr,
OFN_HIDEREADONLY | OFN_ALLOWMULTISELECT | OFN_EXPLORER,
_T("All Files (*.*)|*.*||"));-
OFN_EXPLORER不是可选项，是硬性依赖 - 去掉
OFN_HIDEREADONLY之类无关标志不影响多选，但别误删OFN_EXPLORER - 如果用了自定义hook proc（
OFN_ENABLEHOOK），多选大概率崩溃或静默失败
获取多选结果必须手动解析m_ofn.lpstrFile缓冲区
CFileDialog::GetFileName()和GetFileNames()对多选无效——它们只返回第一个文件名。真实数据全在底层OPENFILENAME结构体的lpstrFile里，且格式特殊：多个NULL分隔的字符串，末尾双NULL结尾。
典型解析逻辑：
立即学习“C++免费学习笔记（深入）”；
if (dlg.DoModal() == IDOK) {
CString str = dlg.GetPathName(); // 第一个文件全路径
LPTSTR p = dlg.m_ofn.lpstrFile;
// 跳过第一个文件（已由GetPathName拿到）
while (*p) p += _tcslen(p) + 1;
// p 现在指向第二个文件名起始位置
while (*p) {
CString filename(p);
// 处理 filename，比如拼上路径
p += filename.GetLength() + 1;
}
}- 务必先调用
DoModal()成功后再访问m_ofn.lpstrFile - 缓冲区大小必须足够：构造
CFileDialog时传入足够大的lpszDefExt或预分配缓冲区（通过lpstrFile参数传入自定义缓冲） - 没传自定义缓冲时，MFC内部用
MAX_PATH * 10大小，选太多小文件可能截断
路径拼接不能直接用GetPathName()的结果
GetPathName()只返回第一个文件的完整路径；其余文件名只是纯文件名（不含路径）。必须用GetFolderPath()提取目录，再手动拼接。
例如：
CString folder = dlg.GetFolderPath();
while (*p) {
CString fullpath = folder + _T("\") + CString(p);
// fullpath 才是第二个及后续文件的完整路径
p += _tcslen(p) + 1;
}-
GetFolderPath()返回的是用户选择的初始目录（即对话框打开时所在的文件夹），不是第一个文件所在目录——这点容易误解 - 如果用户切换了目录，
GetFolderPath()会动态更新，但GetPathName()仍返回第一个文件路径，二者可能不一致 - 多选跨目录？不可能。
CFileDialog强制所有选中文件在同一目录下
Unicode工程下注意TCHAR与缓冲区类型匹配
Unicode编译时，lpstrFile是WCHAR*，但CString构造函数能自动适配；真正容易出错的是手动计算长度——_tcslen()必须和字符类型一致，否则越界读取。
- 确认项目字符集：属性 → 常规 → 字符集 → “使用Unicode字符集”
- 不要用
strlen()处理lpstrFile，它会把宽字符当单字节，提前遇到 就停 - 缓冲区分配示例（安全做法）：
TCHAR szBuffer[MAX_PATH * 100] = {0};，然后传给CFileDialog构造函数的lpszFileName参数
实际多选逻辑的健壮性很依赖缓冲区大小和路径拼接时机，这两处出问题不会报错，只会漏文件或路径错误——调试时得打日志看lpstrFile原始内容。
