C++ Linux 跨平台开发实战指南
跨平台开发，说起来可能觉得就是写一堆条件编译、搞几个宏定义，但真正落地时，各种小坑能把人折磨得够呛。尤其是从Linux出发，要同时照顾Windows和macOS，稍不留神，一个换行符、一个路径分隔符就能让代码在另一台机器上直接罢工。下面这几条核心原则和实操细节，是这些年踩坑踩出来的经验，希望你能少走一些弯路。
一 核心原则
- 拥抱标准库，远离平台API。 ISO C++标准库（STL）以及C++11/14/17/20的新特性，只要能用就优先用。比如
std::vector、std::string、pthread_create或CreateThread，标准线程库足够应付绝大多数场景。 - 非用不可的平台接口，请隔离。 如果确实绕不开POSIX或Win32 API，那就用成熟跨平台库（Boost、Qt、POCO）来垫一层，或者自己封装一个统一的接口层，把平台差异藏起来。这样业务代码干干净净，换平台时只需要改底层实现就行了。
- 抽象接口，分离平台差异。 路径、线程、文件、网络、时间、进程——这些地方最容易出现平台差异。建议设计一个工具层，用Pimpl模式、策略模式或工厂模式，在编译期或运行期选择具体实现。业务逻辑里永远只调用你定义的抽象接口，不要直接写
#ifdef。
二 条件编译与可移植细节
- 平台宏怎么用？ 常用的是
_WIN32（Windows）、linux（Linux）、APPLE（macOS）。用它们包裹平台相关代码时，尽量把差异集中到少数几个源文件或头文件里，别在业务逻辑里到处写#ifdef，否则代码会变成一锅粥。 - 路径与分隔符。 Linux只认
/，Windows虽然也认/但原生习惯是\。最简单的办法：代码里统一用/，或者直接用std::filesystem::path来拼接和转换，显示或写日志时再按需处理。 - 换行符的坑。 Linux用
\n，Windows用\r\n，旧Mac用\r。跨平台文本处理时，一定要统一换行策略，否则git diff就够你头疼的。建议在版本控制里配置统一换行符（比如LF），工具链里也保持一致。 - 源码编码与BOM。 很多开发者习惯用UTF-8 with BOM保存源文件，但Linux下的编译器（比如GCC）可能直接报错。统一用UTF-8 无 BOM，省心。
- 宽字符的陷阱。
wchar_t的大小在Windows上是2字节（UCS-2/UTF-16），在Linux上是4字节（UTF-32）。跨平台时优先用UTF-8（std::string）配合标准库的字符串和文件API，能不用宽字符就别用。如果非要处理UTF-16，用char16_t更明确。 - 字节序与数据对齐。 网络/文件I/O里必须显式处理大端小端，比如统一转成网络字节序（大端）。跨平台结构体别直接
fwrite/fread——对齐方式不同会直接崩。要么定义固定布局并用#pragma pack，要么老老实实显式序列化/反序列化。
三 构建系统与工具链
- 选对构建系统。 CMake是跨平台开发的默认首选，Linux上生成Makefile或Ninja，Windows上生成Visual Studio工程，一套配置搞定。Meson和Premake也是备选，但社区生态不如CMake成熟。统一指定C++标准（比如
set(CMAKE_CXX_STANDARD 17)），以及编译选项和依赖查找规则。 - 编译器与标准。 Linux上GCC和Clang是主流，Windows上是MSVC。尽量启用较新的C++标准，避免用编译器扩展语法。导出符号时，用宏统一处理：
#ifdef _WIN32
#define API_EXPORT __declspec(dllexport)
#else
#define API_EXPORT __attribute__((visibility("default")))
#endif
- 第三方库管理。 别再手动下载源码扔到项目里了。用
vcpkg或Conan，在Linux上也可以用系统包管理器（apt、dnf、pacman）来安装Boost、Qt、POCO等依赖。这样可以保证版本一致，构建可复现。 - IDE与调试。 Linux下CLion（原生支持CMake）、Qt Creator、VS Code、Eclipse CDT、Code::Blocks都行，配合GDB或LLDB调试。关键是熟悉调试器里跨平台运行时可能出现的路径问题、动态库加载问题。
四 常见差异与解决方案
| 差异点 | 推荐做法 | 说明 |
|---|---|---|
| 文件路径 | 统一用 std::filesystem::path 或 / |
避免手写分隔符，跨平台一致 |
| 线程与并发 | 用 std::thread、 |
替代 pthread_create / CreateThread |
| 网络编程 | 用 Boost.Asio 或跨平台网络库 | 避免直接使用 socket / WinSock |
| 动态库导出 | 用宏封装 __declspec(dllexport) / visibility |
保证符号导出跨平台一致 |
| 字节序 | 统一网络字节序（大端） | 文件/协议格式显式序列化 |
| 结构体对齐 | 避免直接 fwrite/fread 结构体 |
定义序列化方法或使用 #pragma pack 并注释 |
| 换行符 | 统一 LF（\n） |
工具链与版本控制保持一致 |
| 源码 BOM | 使用 UTF-8 无 BOM | 防止 Linux 编译报错 |
| 宽字符 | 优先 UTF-8 与标准库 | 规避 wchar_t 宽度差异 |
| 第三方依赖 | vcpkg / Conan / 系统包管理器 | 可复现构建与版本对齐 |
五 最小示例与工程骨架
- 代码示例：跨平台文件存在性检查与路径拼接
#include
#include
namespace fs = std::filesystem;
int main() {
fs::path p = "data/config.json";
if (fs::exists(p)) {
std::cout << "Exists: " << p << '\n';
} else {
std::cout << "Not exists: " << p << '\n';
}
return 0;
}
- 工程骨架（CMake）
cmake_minimum_required(VERSION 3.16)
project(MyApp LANGUAGES CXX)
set(CMAKE_CXX_STANDARD 17)
set(CMAKE_CXX_STANDARD_REQUIRED ON)
find_package(Boost REQUIRED COMPONENTS filesystem system) # 可选
add_executable(myapp main.cpp)
target_link_libraries(myapp PRIVATE ${Boost_LIBRARIES})
- 持续集成建议
在 GitHub Actions 或 GitLab CI 里配置矩阵构建：{os: [ubuntu-latest, windows-latest], compiler: [gcc-12, clang-16, msvc]}，统一运行单元测试和静态分析。这种自动化能最快暴露平台差异问题，省得等到上线才发现。
跨平台开发没有银弹，但把上面这些原则和细节内化成习惯之后，你会发现代码的可移植性自然就提高了。关键在于“隔离”和“抽象”——别让平台细节污染了业务逻辑。
