不能——file*需用fclose释放，而std::default_delete调用delete会导致未定义行为；应使用带判空fclose的lambda自定义删除器，并用decltype推导类型。
FILE* 能不能直接用 std::unique_ptr 管理？
不能——默认的 std::default_delete 会调用 delete，而 FILE* 是由 fopen 分配、必须用 fclose 释放的 C 资源，直接 delete 会导致未定义行为，程序大概率崩溃或静默内存泄漏。
怎么写一个能关 FILE 的自定义删除器？
核心是把 fclose 封装成可调用对象，传给 std::unique_ptr 构造函数。它得满足：接受单个 FILE* 参数、无返回值、不抛异常（否则 unique_ptr 析构时可能中止）。
推荐用 lambda（简洁、无状态、内联友好）：
auto file_closer = [](FILE* f) { if (f) fclose(f); };
std::unique_ptr<file decltype> fp(fopen("data.txt", "r"), file_closer);</file>
注意点：
-
fopen可能返回nullptr，删除器里必须判空，否则fclose(nullptr)在部分平台（如旧 glibc）会段错误 - lambda 类型不能直接写在模板参数里（类型名太长且不可名），所以用
decltype推导 - 不要用函数指针（如
void(*)(FILE*)）替代 lambda——它无法捕获上下文，且类型擦除开销略高
为什么不用 std::shared_ptr 或 RAII 封装类？
除非真需要共享所有权，否则没必要。用 std::unique_ptr 更轻量，析构确定、无引用计数开销，语义也更贴合“独占文件句柄”的场景。
C++ Code Review Master
下载
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
对比手写 RAII 类（比如 FileHandle）：
-
unique_ptr写法更短，复用标准库契约（移动语义、get()/release()等） - 但失去类型安全：所有
FILE*都是同一类型，无法区分读/写/二进制等意图；而自定义类可加read_line()等方法 - 若需频繁传递给 C API（如
fprintf(fp.get(), ...)），unique_ptr的.get()比封装类的隐式转换更明确、不易误用
Windows 下用 _wfopen 怎么处理？
宽字符路径需要传 const wchar_t*，但 fopen 删除器仍只认 FILE*——这点不变。问题出在构造时：
#ifdef _WIN32
FILE* f = _wfopen(L"中文路径.txt", L"r");
#else
FILE* f = fopen("中文路径.txt", "r");
#endif
std::unique_ptr<file decltype> fp(f, file_closer);</file>
关键提醒：
-
_wfopen不是标准 C 函数，跨平台代码需条件编译 - 即便用了
_wfopen，删除器还是调fclose（不是_wclose），因为FILE*对象本身与编码无关 - 真正容易被忽略的是：宽字符路径在 Linux/macOS 上无效，而 Windows 下 ANSI 版
fopen对中文路径常失败——这属于编码和 locale 层面的问题，和unique_ptr无关，但实战中总一起出现
事情说清了就结束。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
