最直接有效的手段是用编译器开关强制拦截：GCC/Clang用-Werror=deprecated-declarations配合-D_FORTIFY_SOURCE=2，MSVC用/we4996；需全局注入CMake根文件，验证方式为写strcpy(nullptr, "");看是否立即报错。
用编译器开关强制拦截不安全函数调用
最直接有效的手段不是靠人工 review，而是让编译器在构建阶段就报错。GCC/Clang 支持 -Werror=deprecated-declarations，配合 -D_FORTIFY_SOURCE=2 可触发对 strcpy、sprintf 等函数的弃用警告并升级为错误；MSVC 则需启用 /we4996（将 C4996 警告转为错误）。关键点在于：这些开关必须作用于所有编译单元，包括第三方子模块——若用 CMake，应在根 CMakeLists.txt 中通过 add_compile_options() 全局注入，而非只加在主 target 里。
常见误操作是只对主工程开开关，结果 vendor/libfoo 里的 strcpy 依然静默通过。验证是否生效的方法很简单：在任意 .cpp 文件里写一行 strcpy(nullptr, "");，看构建是否立即失败。
替换策略要分优先级，不是所有函数都值得立刻重写
真正该优先干掉的是三类高危函数：gets（已从 C11/C++14 标准移除）、strcpy 和 sprintf。它们没有长度参数，溢出风险不可控；而 strncpy、snprintf 虽带长度但语义有坑（strncpy 不保 \0，snprintf 返回值易被忽略），属于“次危险”，应逐步迁移到 std::string 或 std::format（C++20）。
-
gets→ 必须全量替换成fgets，且fgets第二个参数必须是缓冲区总大小（不是 size-1），否则仍可能丢结尾 \0 -
strcpy→ 优先用std::string或std::copy_n；若必须用 C 风格，strcpy_s仅限 Windows/MSVC 环境，跨平台项目慎用 -
sprintf→ C++20 起无条件用std::format；旧环境用snprintf，但必须检查返回值是否 ≥ 缓冲区大小
建立头文件拦截层，让不安全函数根本不可见
比逐个替换更彻底的做法，是在项目最顶层加一层“禁用头文件”：新建 unsafe_blocker.h，在里面用 #undef 清空所有相关宏，并用 #define strcpy _disabled_strcpy 这类方式让调用直接编译失败。然后通过 CMake 的 include_directories(BEFORE ...) 或编译器 -include 参数，确保它在所有标准头之前被拉入。
这个方法能捕获到宏展开产生的隐式调用（比如某些日志宏里藏着 sprintf），但要注意：它会干扰部分第三方库的内部逻辑，所以实际落地时建议先用 #warning 替代 #define 做灰度，确认无误后再切到硬拦截。
CI 流程里加一道静态扫描卡点
编译器开关和头文件拦截能拦住显式调用，但拦不住宏拼接、函数指针赋值或模板实例化间接引入的不安全函数。这时需要在 CI 的 build step 后插入一次 clang++ -Xclang -ast-dump | grep -E "(strcpy|sprintf|gets)" 类似的 AST 扫描，或者用 Cppcheck 配置规则 --enable=warning,style --suppress=missingInclude 扫源码树。
重点不是扫出多少问题，而是把扫描结果转成可追踪的 issue —— 每个匹配项必须关联到具体文件行号和 git blame 作者，否则很容易变成“已知问题长期搁置”。实践中发现，超过 70% 的残留调用集中在历史遗留的解析器、序列化模块和测试桩代码里，这些地方往往缺乏 owner 维护，需要专项清理计划。
真正的难点不在技术方案本身，而在于如何让整个团队在不中断交付的前提下持续收敛。那些藏在条件编译块里、只在特定硬件平台上激活的 strcpy，或是被封装了四层的私有日志宏，才是最后啃不动的硬骨头。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
