import 不会自动找模块文件，因 C++20 Modules 依赖编译器显式预编译接口单元（如 .ixx）生成 PCM 二进制，并通过 -fmodule-file= 等参数指定路径，而非按名查找源文件或头文件。
为什么 import 不会自动找到模块文件
因为 C++20 Modules 不是“按名查找”，而是依赖编译器对模块接口单元（.ixx 或 .cppm）的显式编译与导出。你写 import math_utils;，编译器不会去头文件目录翻 math_utils.h，也不会扫描当前目录找同名文件——它只认已生成的模块二进制（如 math_utils.pcm）且需通过 -fmodule-file= 或 --precompile 显式提供路径。
- Clang 默认不自动生成或缓存 PCM 文件，每次都要手动预编译接口单元
- MSVC 要求模块接口单元必须用
/interface编译，且import语句所在 TU 必须用/reference指向对应 PCM - gcc 13+ 支持有限，仍需
-fmodules-ts+-fmodule-file=，且不支持跨目录隐式解析
如何正确编译一个模块并被其他文件 import
以 Clang 15+ 为例（Linux/macOS），关键在于两步分离：先预编译接口单元，再编译导入单元。
clang++ -std=c++20 -x c++-system-header -fmodules -fimplicit-modules -fmodule-map-file=module.modulemap -c math_utils.ixx -o math_utils.pcm clang++ -std=c++20 -fmodules -fmodule-file=math_utils.pcm main.cpp -o main
其中：
-
math_utils.ixx是模块接口单元，含export module math_utils;和export声明 -
module.modulemap非必需，但若想让模块名映射到文件路径，需显式声明：module "math_utils" { header "math_utils.ixx" isystem "." } -
-fimplicit-modules允许自动加载标准库模块（如import std.core;），但不会帮你找自定义模块
import 后为什么链接失败或符号未定义
模块接口单元（.ixx）只导出声明，不包含实现；实现必须放在模块实现单元（.cpp）中并参与链接。常见错误是只编译了接口单元 PCM，却忘了把对应实现编译进最终可执行文件。
Miller CSV TSV JSON 数据处理器
下载
Miller (mlr) 是一个命令行工具，用于查询、整形和重新格式化名称索引数据，如 CSV、TSV、JSON 和 JSON Lines。它将 awk、sed、cut、join 和 sort 的功能整合到一个专为结构化数据处理而构建的单一工具中。
立即学习“C++免费学习笔记（深入）”；
- 模块接口单元里
export的函数，必须在某个.cpp文件里有非inline定义（除非加inline或写在头文件内联区） - Clang 下，实现单元仍要用
-fmodules编译，否则无法识别模块内部符号依赖 - MSVC 中，模块实现单元必须用
/implementation编译，且不能同时用/interface
编译速度提升真实吗？哪些场景反而更慢
模块确实能跳过预处理器、避免重复解析头文件，但提速效果高度依赖项目结构和构建系统配合。实测中，以下情况可能变慢：
- 小项目（ 头文件重用收益
- 频繁修改接口单元：每次改
.ixx都触发整个模块 PCM 重建，所有import它的文件全量重编 - CI 环境无模块缓存：PCM 文件未复用，等于每次从零预编译
- 混合使用传统头文件和模块：编译器需维护两套依赖模型，中间表示膨胀
真正受益的是大型代码库，尤其是接口稳定、实现常变、头文件嵌套深（如 #include <boost/hana.hpp> 这种）的场景。
模块不是银弹，它把“头文件管理复杂度”换成了“PCM 生命周期管理复杂度”。没配好构建脚本前，别指望一键加速。
