非模块化代码能否调用C++20模块？大型代码库迁移疑问

核心结论 #

你的观察基本准确：默认情况下，未采用模块化的代码（仍依赖头文件包含）无法直接引用C++20模块。但并非必须一次性迁移所有消费端代码，存在几种可控的过渡方案，无需完全依赖#ifdef双路径维护。

可行的过渡方案 #

1. 为模块化SDK编写兼容头文件（适配层） #

针对已模块化的SDK，编写兼容头文件，在其中通过import引入SDK模块，直接导出所有对外暴露的符号。上层未模块化的代码可继续通过#include该兼容头文件使用SDK，无需修改自身逻辑。

示例：
假设SDK模块名为sdk.system，模块接口文件sdk.system.cppm导出了class SystemAPI，兼容头文件sdk_compat.h可写为：

#pragma once
import sdk.system;
// 模块导入的符号自动对外可见，无需额外声明

Engine/Editor代码只需保留原有的#include "sdk_compat.h"，就能像之前一样使用SystemAPI，同时SDK内部已完全享受到模块的编译提速、隔离性等优势。

2. 利用头单元（Header Units）过渡 #

C++20的头单元是模块与传统头文件的中间层，可将传统头文件编译为模块单元，既保留头文件的使用习惯，又能获得模块的部分编译优化。

你可以先将SDK的头文件编译为头单元，上层代码只需将#include <sdk_header.h>改为import "sdk_header.h";（部分编译器需额外配置生成头单元），改动成本远低于完全迁移到模块接口单元。后续迁移Engine/Editor时，再将SDK的头单元升级为正式模块接口单元即可。

3. 共享库接口隔离 #

若代码库按共享库（DLL/SO）组织，可将模块化的SDK编译为独立共享库，对外仍保留传统头文件接口。SDK内部用模块实现，但对外暴露的符号通过传统头文件声明，上层代码只需链接共享库并包含原头文件，完全感知不到SDK内部的模块化改造。

关于#ifdef双路径的问题 #

你提到的#ifdef双路径方案确实会大幅增加维护成本，抵消模块的核心优势，仅适合极短期临时过渡，不推荐作为长期方案。上述几种方案均无需维护双路径，通过适配层或中间单元实现平滑过渡。

总结 #

不需要迁移所有消费端代码才能启动底层共享库的模块化改造。通过兼容头文件、头单元或共享库接口隔离的方式，可实现自底向上的逐步迁移：先完成SDK模块化，再逐步推进Engine，最后处理Editor，每一步都能保留上层代码的兼容性，同时享受已迁移部分的模块收益。

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