std::filesystem::current_path() 返回进程启动时的工作目录；它既非源文件所在目录，也非可执行文件所在目录，而是由启动环境（如IDE或终端）决定的当前工作目录。
std::filesystem::current_path() 返回的是谁的当前路径
它返回的是进程启动时所在目录，不是源文件（.cpp）所在的目录，也不是编译产物（如 a.out）所在目录。很多开发者误以为“源文件在哪，当前路径就是哪”，结果用 std::ifstream("data.txt") 在 IDE 里能读，在终端里就失败——根本原因是 IDE 启动进程时自动把工作目录切到了项目根，而你手动运行时可能在任意路径下执行。
实操建议：
- 不要依赖
std::filesystem::current_path()推断源码位置；它和源文件物理位置完全无关 - 调试时加一行
std::cout 看清实际路径 - 若需定位源文件同级资源，必须靠构建系统传入路径（如 CMake 的
CMAKE_CURRENT_SOURCE_DIR），或硬编码相对路径（仅限开发测试）
std::ifstream 构造时路径解析规则
路径是纯字符串，C++ 标准库不做任何“智能补全”或“源码映射”。传入 "config.json" 就是在当前工作目录下找；传入 "./assets/config.json" 就是在当前工作目录下的 assets 子目录找；传入绝对路径（如 "/etc/myapp/config.json"）才跳过工作目录。
常见错误现象：
立即学习“C++免费学习笔记（深入）”；
- 在 VS Code 中按 Ctrl+F5 运行，文件读取成功；终端进到
build/目录运行./myapp，报错basic_ios::clear: iostream error - 用 CMake 构建后安装到
/usr/local/bin，程序硬编码"../share/myapp/data.bin"，但安装时没同步部署资源，直接崩溃
实操建议：
- 永远用
std::ifstream::is_open()检查打开结果，别只靠异常（默认不抛异常） - 路径拼接务必用
std::filesystem::path操作，避免手拼"/"或"\"：auto p = std::filesystem::current_path() / "data" / "input.txt"; - Windows 下路径分隔符用
/完全合法（Win10+ 支持），不必写\
std::format 与文件内容读取无直接关系
std::format 是格式化输出工具，不是 I/O 函数。它不能读文件，也不能自动解析路径。有人看到 “C++20 format” 就以为它是新版文件读取 API，其实它连 std::ifstream 的边都没挨上。
典型误用场景：
- 写
std::format("{}.txt", filename)拼路径，却忘了检查拼出来的路径是否存在 - 试图用
std::format替代std::getline去读多行文本，结果编译失败（std::format只接受 const char* 或 string_view，不接受 stream）
实操建议：
- 读文件还是老老实实用
std::ifstream+std::string缓冲，或 C++23 的std::ranges::istream_view（目前支持有限） -
std::format只该出现在日志、错误提示、配置生成等“输出端”，例如：throw std::runtime_error(std::format("failed to open {}", p.string())); - 注意
std::format默认不支持宽字符（std::wstring），别拿它格式化std::filesystem::path::wstring()
跨平台获取源文件所在目录的现实方案
C++ 标准没有提供“获取 __FILE__ 所在目录”的函数。预定义宏 __FILE__ 是字符串字面量，值由编译器决定（可能是相对路径、绝对路径，也可能被裁剪），不可靠。
真正能落地的做法只有两个：
- 构建时注入：CMake 中用
add_definitions(-DSOURCE_DIR="${CMAKE_CURRENT_SOURCE_DIR}")，代码里用std::filesystem::path(SOURCE_DIR) / "data" - 运行时约定：要求用户通过命令行参数（如
-r /path/to/resources）或环境变量（如MYAPP_RES_PATH）指定资源根目录，程序启动时校验该路径存在且可读
别碰这些坑：
- 用
__FILE__+std::filesystem::canonical()—— 若__FILE__是相对路径，canonical会相对于当前工作目录解析，结果不可控 - 假设 IDE 和终端行为一致 —— 它们对工作目录的处理逻辑完全不同
- 在 release 构建中保留
__FILE__路径信息 —— 编译器可能优化掉或重写路径
最麻烦但最稳的方式：把资源打包进二进制（如用 xxd -i 转成 C 数组），彻底绕过文件系统路径问题。不过这就不是“读取文件”而是“嵌入数据”了。
