iwyu 报“no compilation database”错误是因为它依赖 compile_commands.json 文件获取编译参数，不直接解析源码；需用 -DCMAKE_EXPORT_COMPILE_COMMANDS=ON 生成该文件，并通过 -p 指定其所在构建目录。
为什么 include-what-you-use 报 “no compilation database” 错误
直接运行 iwyu 命令却提示找不到编译数据库，是因为它不读取源码本身，而是依赖构建系统生成的 compile_commands.json。没有这个文件，iwyu 就不知道每个 .cpp 文件用了哪些宏定义、包含路径和标准版本。
常见错误现象：执行 iwyu tool.cpp 后报错 Error: no compilation database found，或输出大量“symbol not found”类误报。
- 用 CMake 项目：在调用
cmake时必须加-DCMAKE_EXPORT_COMPILE_COMMANDS=ON，生成后会自动创建compile_commands.json（通常在 build 目录下） - 用 Ninja/Make：确保构建目录里真有该文件；若没有，删掉 build 目录重来，别跳过这步
- 手动指定路径：运行
iwyu -p /path/to/build/dir/ tool.cpp，-p参数必须指向含compile_commands.json的目录，不能是源码根目录
如何让 iwyu 正确识别 C++20 模块和 std::span 等新特性
iwyu 默认按 C++11 解析，遇到 #include <span></span> 或 import std.core; 会报错或漏建议——不是它不支持，而是没告诉它用哪个语言标准。
使用场景：项目已迁移到 C++20，但 iwyu 仍建议把 <span></span> 换成 <array></array>，或完全忽略 import 语句。
立即学习“C++免费学习笔记（深入）”；
- 在
compile_commands.json中检查对应条目的command字段，确认含-std=c++20（而非c++17或缺失）；若没有，CMake 中需设set(CMAKE_CXX_STANDARD 20) - 临时覆盖：运行时加
--std=c++20，例如iwyu -p build/ --std=c++20 tool.cpp - 对模块（
import）：当前稳定版iwyu（v0.19）不解析import语句，也不会建议移除对应的#include；如需处理模块依赖，得等后续版本或配合clang-scan-deps
怎么安全地批量应用 iwyu 的修改建议
iwyu 默认只打印建议，不改代码；强行用脚本自动替换头文件极易破坏编译，尤其当多个头文件导出同名符号、或存在隐式依赖（比如 A.h 里 typedef 了 B.h 里的类型）时。
性能影响：一次扫整个项目可能卡住，且并行处理不同文件时，若共享同一份 compile_commands.json，结果可能不一致。
- 先单文件验证：用
iwyu -p build/ file.cpp --check_also="*.h"查看建议，再手动改 1–2 个最简单的 .cpp 文件，立刻编译验证 - 避免全局替换：不要用
sed批量删#include；iwyu输出的 “should add” 和 “should remove” 是独立判断，顺序和上下文敏感 - 用
fix_includes.py脚本（随iwyu发布）：它读取iwyu的原始输出，做语法树级插入/删除，比正则安全；运行前务必备份，命令形如python fix_includes.py
为什么 iwyu 建议移除 <memory></memory> 却编译失败
这是最典型的误报来源：iwyu 只看当前文件中显式使用的符号，而忽略模板实例化、ADL（Argument-Dependent Lookup）或宏展开引入的间接依赖。
例如：某 .cpp 里没直接写 std::shared_ptr，但用了第三方库函数，其声明在头文件中用了 std::shared_ptr<t></t> 作参数——此时 <memory></memory> 是必需的，但 iwyu 看不到模板实例化后的符号引用。
- 检查是否用了宏：像
MY_API_FUNC(int x)展开后可能含std::unique_ptr，但iwyu不预处理宏，会误判 - 留意 PIMPL 惯用法：头文件里只声明
class Impl;，实现文件里才#include "impl.h"，但若impl.h依赖<vector></vector>，而主头文件又用了std::vector<t></t>的前向声明，iwyu可能建议删掉<vector></vector> - 保守策略：对标准库头文件（
<memory></memory>、<string></string>、<algorithm></algorithm>），只要编译器报错就留着，别硬信iwyu的 “should remove”
iwyu，而是分辨哪些建议反映真实冗余，哪些暴露了它没能力看到的依赖链。尤其在混合使用模板、宏、PIMPL 和跨库调用的项目里，它的输出更像一份待人工交叉验证的清单，而不是可直接执行的指令。 
