std::filesystem::remove 是 c++17 起删除文件的首选方式，跨平台、语义清晰、错误可判；需包含 头文件、启用 c++17 标准，建议配合 exists() 和 is_regular_file() 预检，并捕获 filesystem_error 异常处理失败原因。
用 std::filesystem::remove 删除文件最稳妥
这是 C++17 起标准库提供的首选方式，跨平台、语义清晰、错误可判。别再手写 remove()（C 标准库函数）或调用系统命令，前者不报错原因，后者平台绑定强、难调试。
常见错误现象：std::filesystem::remove 返回 false 却没检查，结果文件没删掉还毫无提示；或者传入目录路径却期望删文件，直接失败。
- 必须包含头文件：
#include <filesystem></filesystem>，编译时加-std=c++17（GCC/Clang）或启用 C++17（MSVC） - 路径参数建议用
std::filesystem::path类型传入，避免字符串拼接出错 - 删除前可用
std::filesystem::exists(p)和std::filesystem::is_regular_file(p)预检，避免误删目录或处理不存在路径 - 失败时抛
std::filesystem::filesystem_error异常，建议捕获并读取.what()查具体原因（比如权限不足、路径不存在、正被占用）
try {
std::filesystem::path p = "data/temp.log";
if (std::filesystem::exists(p) && std::filesystem::is_regular_file(p)) {
if (std::filesystem::remove(p)) {
std::cout
<h3>Windows 下用 <code>DeleteFileA</code>/<code>DeleteFileW</code> 的坑</h3>
<p>如果项目不能用 C++17，或需精细控制 Windows 特有行为（比如绕过回收站），会直接调 Win32 API。但极易踩坑：编码、路径格式、权限、句柄残留都可能导致静默失败。</p>
<p>使用场景：遗留代码维护、嵌入式 Windows 环境、或需配合 <code>MoveFileEx</code> 实现“强制删除”（如先解除只读属性）。</p><div class="aritcle_card flexRow artxards">
<div class="artcardd flexRow">
<a class="aritcle_card_img" rel="nofollow" href="/xiazai/gongju/2823" title="C++14"><img
src="https://img.php.cn/upload/manual/001/431/639/6ac8b33c327c4749.png" alt="C++14" onerror="this.onerror='';this.src='/static/lhimages/moren/morentu.png'" ></a>
<div class="aritcle_card_info flexColumn">
<a rel="nofollow" href="/xiazai/gongju/2823" title="C++14" class="overflowclass">C++14</a>
<p class="overflowclass">C++14 对 C++11 的修正与增强版本，适合旧系统维护和较老工具链兼容。</p>
</div>
<a rel="nofollow" href="/xiazai/gongju/2823" title="C++14" class="aritcle_card_btn flexRow flexcenter"><b></b><span>下载</span>
</a>
</div>
</div>
- 务必用宽字符版本
DeleteFileW，传L"xxx"字面量，避免 ANSI 编码导致中文路径乱码 - 路径必须是绝对路径，或确保当前工作目录正确；相对路径容易因执行环境不同而失效
- 若返回
FALSE，立即调GetLastError()判断原因：ERROR_ACCESS_DENIED（文件被打开/只读）、ERROR_SHARING_VIOLATION（其他进程正读写）、ERROR_FILE_NOT_FOUND - 删除前建议先用
SetFileAttributes清除FILE_ATTRIBUTE_READONLY，否则即使有写权限也会失败
std::remove（C 标准库）为什么慎用
它在 C++ 里仍可用，但行为模糊、错误反馈弱、不区分文件/目录，且某些平台（如 Windows）对 Unicode 路径支持差。新手常以为它和 Python 的 os.remove 一样可靠，实际不是。
常见错误现象：传入含中文的路径时返回 -1 但 errno 是 0；删目录时不报错却什么也没发生；Linux 下能删，Windows 下静默失败。
- 仅接受
const char*，无法原生处理 UTF-8 路径（Windows 控制台默认非 UTF-8） - 成功返回 0，失败返回 -1，但
errno在某些实现中不可靠，尤其多线程下易被覆盖 - 在 Windows 上，它底层调用的是
_unlink，对目录无效；Linux/macOS 上对目录调用会失败（EPERM），但错误码含义不统一 - 没有原子性保证，也不提供“是否真的删了”的确认机制
删除失败时最该查的三件事
90% 的删除问题不在于代码写法，而在于运行时状态。别急着改代码，先看这三项。
- 目标文件是否被其他进程打开？包括 IDE、文本编辑器、资源管理器预览窗格、杀毒软件实时扫描——关掉再试
- 当前进程是否有对应目录的写权限？Windows 下注意“获取所有权”和“修改”权限要同时存在；Linux/macOS 检查父目录的
w权限（删除操作实际修改的是父目录的 inode） - 路径是否真实存在且类型匹配？用
std::filesystem::status(p).type()明确判断是regular_file、directory还是not_found，别只靠字符串后缀猜
跨平台项目里，std::filesystem::remove 的行为一致性比想象中高，但 Windows 对长路径、符号链接、挂载点的处理仍更敏感。真遇到诡异失败，优先打印完整路径和 status(p) 结果，比反复改代码快得多。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
