如何通过编译器警告或Clang-Tidy规则禁用直接文件系统访问方法？

一、自定义Clang-Tidy规则（首推） #

这是最适合长期维护的方案，完全匹配你的需求：

• 可以编写自定义检查逻辑，通过遍历Clang的抽象语法树（AST），精准识别直接调用std::ifstream（尤其是带路径参数的构造）、std::filesystem下的目标方法（比如exists、directory_iterator这类）的代码。
• 将规则设为错误级别，不管是本地编译还是CI流水线，只要出现违规调用就直接阻断，从源头杜绝问题。
• 优势明显：无需逐个枚举禁用API，靠命名空间、函数/类的行为匹配就能覆盖场景，后续新增需要禁用的API也能轻松扩展规则；自己的包装器内部调用这些API时，只需添加规则例外即可放行。

二、编译器层面的警告转错误（快速落地） #

1. 废弃声明+编译选项 #

在项目全局头文件里，把要禁用的API重新声明为废弃，并配合编译选项把警告转成错误：

// 项目全局公共头文件中添加
namespace std {
    // 禁用std::ifstream的路径构造
    template <typename... Args>
    [[deprecated("禁止直接用std::ifstream，请使用自定义文件包装器")]]
    ifstream::ifstream(Args&&... args) = delete;

    // 禁用std::filesystem的exists方法
    [[deprecated("禁止直接用std::filesystem::exists，请使用自定义文件包装器")]]
    bool exists(const filesystem::path& p) = delete;
}

编译时加上-Werror=deprecated-declarations，只要有人直接调用这些API，编译就会报错。

2. #pragma GCC poison（评估阶段临时用） #

这个方式确实需要逐个列出禁用符号，比如：

#pragma GCC poison ifstream filesystem

但缺点是粒度太粗，连包装器内部调用都得用#pragma GCC unpoison临时解禁，维护起来比较麻烦，适合评估阶段快速验证效果，不建议长期使用。

三、预提交钩子+代码审查（辅助补漏） #

配合前面的方案，添加预提交脚本（比如用Python扫描代码里的std::ifstream(或std::filesystem::关键字），提前拦截明显的违规调用；再结合代码审查，确保没有漏网之鱼。

内容的提问来源于stack exchange，提问作者lielb