★ FEATURED ARTICLE 我知道很多人第一次看到 CMake 这名字第一反应是“又一个构建工具”然后打开一篇教程看到一堆add_executable、target_link_libraries和长长的尖括号变量转身就跑了。但事实上CMake 的核心价值恰恰不是多了一个工具而是它把“描述项目是怎么构成的”和“在具体平台上把它构建出来”这两件事彻底分开。这几年我在好几个跨平台 C/C 项目里折腾过手写 Makefile、试过各种 IDE 工程文件最后把所有项目都迁移到 CMake 之后才真正意识到它值得花一个周末认真学一下。这篇内容就基于我真实项目里的使用经验把 CMake 从安装到写 CMakeLists.txt再到组织多目录项目、处理依赖、排查报错一次讲清楚。适合刚接触 CMake 的 C/C 开发者也适合那些已经能用 CMake 但一直被各种隐性问题绊住的工程实践者。1. CMake 到底解决了什么问题先把手写 Makefile 的痛苦说清楚1.1 编译链路的本质与 Makefile 的边界要理解 CMake先得看清 C/C 项目的构建链路。一个源文件要变成可执行程序要经过预处理、编译、汇编、链接四个阶段。你当然可以每次都手敲g -c main.cpp -o main.o g -c utils.cpp -o utils.o g main.o utils.o -o app两个文件还好项目一旦变成二十个文件、三个子目录、还要链接一些第三方库问题就来了哪些文件需要重新编译怎么并发编译提高速度头文件路径怎么传静态库和动态库的链接顺序是什么于是人们写 Makefile把编译规则记下来app: main.o utils.o g $^ -o $ %.o: %.cpp g -c $ -o $这套东西在 Linux 上没问题但如果你要让项目同时支持 Windows 的 MSVC、macOS 的 Clang那 Makefile 的每条规则都要针对不同编译器写不同参数。更难受的是Visual Studio 根本不直接认 Makefile你还得维护一份.vcxproj工程文件。于是同一个项目在三个平台上有三套完全不同的构建描述改一个源文件列表三处都要同步。我见过最夸张的项目光是维护这些构建文件的人一个迭代周期就要花掉三分之一的时间。1.2 CMake 为什么是“生成器”而不是又一个 MakeCMake 的设计思路是你用一种中立的 CMakeLists.txt 把项目结构、编译目标、依赖关系描述清楚然后 CMake 根据当前平台和用户选择的“生成器generator”把描述转换成本地构建系统能识别的文件——在 Linux/macOS 上通常是 Makefile 或 Ninja在 Windows 上可以是 Visual Studio 工程文件也可以生成 Ninja 配合 MSVC 编译器。这有点像后端把一份 JSON 数据渲染成不同前端框架的页面数据只有一份展示方式随平台变化。这个“生成器”思路带来几个实实在在的好处项目描述只维护一份换平台不用重写构建脚本。跨平台路径拼接、编译器检测、库查找这类脏活CMake 帮你干了一大半。基于 CMake 的第三方库可以通过find_package统一方式被发现和链接而不需要每个项目手撸-I和-L。所以核心认知先立起来CMake 不是替代 Makefile 的“另一个 Make”而是管理“如何生成 Makefile (或工程文件)”的工具。你用 CMake 写的是项目说明书不是编译器指令。1.3 一个表格看清 CMake、Makefile、IDE 工程的关系维度MakefileCMakeIDE 工程文件如 .vcxproj定位构建规则脚本项目描述 生成器特定 IDE 的构建描述跨平台差需手动适配编译器/平台好一套描述多端生成差绑定 IDE第三方库集成靠 pkg-config 或手写路径find_package / FetchContent靠 IDE 手动配置适合场景小型 Linux 项目、快速验证中大型跨平台项目、库发布团队统一使用某 IDE看完这个对比就明白为什么现代 C/C 开源项目几乎清一色选择 CMake。你从 GitHub 上拉下来的库大概率都带着一份 CMakeLists.txt目的就是让你能无缝把它集成进自己的项目里。2. 从安装到版本选择这里藏着很多人入门就踩的坑2.1 Linux 下安装的两种姿势与版本陷阱在 Ubuntu 这类 Debian 系发行版上很多人的第一反应是sudo apt install cmake。这条命令能装上 CMake但版本往往偏旧。Ubuntu 18.04 自带的 CMake 是 3.10.2而很多现代库最低要求 3.16 甚至 3.20。一旦你在 CMakeLists.txt 里写了cmake_minimum_required(VERSION 3.16)系统自带的 CMake 会直接报错CMake 3.10.2 is lower than required然后你才开始经历“装新版 CMake”这个环节。比较省事的方式是使用 pip 安装pip install cmake --user没错pip 也发布了 CMake 预编译包装完以后~/.local/bin/cmake就是较新的版本。另一个常见做法是到 CMake 官网下载源码包自己编译但编译 CMake 本身又依赖 OpenSSL、libcurl 等开发库如果只是为了工具链我个人不太建议走源码编译这条路除非你的机器完全内网隔离、必须离线安装。2.2 离线环境怎么装 CMake一个完整思路热搜词里“ubuntu cmake 离线安装”被反复点出来说明很多人确实遇到内网机器的场景。这里给出我踩过坑之后的一套离线安装流程。第一步找一台能联网的、和目标机器同架构都是 x86_64的机器下载官方提供的编译好的二进制压缩包而不是源码包。比如你要装 3.27 系列下载cmake-3.27.9-linux-x86_64.tar.gz。第二步把压缩包拷贝到内网机器解压到/opt/cmake-3.27.9之类的目录tar -zxvf cmake-3.27.9-linux-x86_64.tar.gz sudo mv cmake-3.27.9-linux-x86_64 /opt/cmake-3.27.9第三步把/opt/cmake-3.27.9/bin加入 PATH。不建议直接覆盖/usr/bin/cmake因为系统很多组件可能依赖旧版本。export PATH/opt/cmake-3.27.9/bin:$PATH echo export PATH/opt/cmake-3.27.9/bin:$PATH ~/.bashrc用cmake --version验证一下输出里能看到版本就说明环境变量生效了。离线环境里的另一个选择是下载.deb包旧版本官方有提供但如果依赖库不满足照样装不上所以通用性最强的是 tar.gz 二进制包。2.3 Windows 与 macOS 的安装要点Windows 下直接去官网下载.exe安装器安装时注意勾选“Add CMake to the system PATH for all users”。如果你用 Visual Studio它带有一套 CMake 插件IDE 内部也能生成、执行构建不一定需要独立安装。但命令行工具链场景下还是建议装一份独立 CMake避免 VS 版本升级时把捆绑的 CMake 版本一起换掉。macOS 上最省心的是 Homebrewbrew install cmake装完同样是cmake --version验证。2.4 版本选择的核心建议关于版本我的建议非常直接新项目直接用 3.16 以上能用 3.22 以上就用 3.22 以上。原因有三个3.16 引入了许多跨平台改进FetchContent也足够成熟。3.19/3.20 之后的 CMake Presets 机制CMakePresets.json大幅提升了大型团队协作体验但要求 CMake 版本够新。老版本 CMake 对target_*命令的支持参差不齐为了避免踩到“我这写法明明照着官方文档为什么还报错”的问题版本越新越省心。最后提醒一句如果你改了 CMakeLists.txt 但编译行为总是“不变”先别急着怀疑 CMake 配置写错了去检查一下 CMakeCache.txt 是否在帮你“记住”旧配置。关于这个坑放到后面专门讲。3. 第一份 CMakeLists.txt从单文件到多文件把语法当函数调用看3.1 最简项目的完整流程建一个hello_cmake目录里面只有一个main.cpp#include iostream int main() { std::cout Hello CMake std::endl; return 0; }在同一个目录下写 CMakeLists.txtcmake_minimum_required(VERSION 3.16) project(HelloApp LANGUAGES CXX) add_executable(hello_app main.cpp)这三行就是 CMake 的入门口诀。第一行声明最低版本第二行指定项目名和启用语言第三行声明要生成一个名为hello_app的可执行目标源文件是main.cpp。CMake 的语法很像函数调用命令名如project、add_executable后面跟参数参数用空格分隔字符串可以加引号也可以不加但路径带空格时必须加引号。换行符和分号在参数里会被当作列表分隔符所以同一行里写多个源文件没问题写成多行也不会出错。然后执行cmake -S . -B build cmake --build build-S .指定源码目录-B build指定构建目录。构建完成后生成的可执行文件在build/hello_app直接运行即可。3.2 为什么强烈建议源码目录和构建目录分离新手最容易犯的“样板式错误”就是直接cmake .然后把一堆生成文件全部堆进源码目录里。生成的CMakeCache.txt、Makefile、.cmake文件会污染源码树以后清理麻烦多套编译配置Debug/Release也没法并存。而cmake -S . -B build这种“out-of-source”构建保持了源码目录干净想要几套构建配置就建几个目录cmake -S . -B build-debug -DCMAKE_BUILD_TYPEDebug cmake -S . -B build-release -DCMAKE_BUILD_TYPERelease两个目录互不干扰。build目录可以被随时删除删除后重新跑一次cmake -S . -B build就满血复活。在我实际维护的项目里build目录还往往直接写进.gitignore因为它本质是生成物不值得进版本库。3.3 GUI 是谁在用聊聊 cmake-gui 的真实价值热搜里出现了 “cmake gui”这里也多说一句。装好 CMake 后你可以在命令行里敲cmake-gui打开图形界面。这个界面能做的本质上就是设置源码目录、构建目录、生成器类型以及各种 CMake 缓存变量Cache 变量会在第 6 章详细讲。那什么时候需要图形界面我见过两种典型场景一是 Windows 上刚接触 CMake 的 IDE 用户图形界面比命令行更直观二是在调试“为什么某个 CMake 变量没生效”的时候gui 里能直接看到所有缓存变量、路径、类型比在文本文件里翻方便得多。但对于日常操作命令行足够GUI 更像一个可视化排错工具不是必需品。3.4 多文件项目引入头文件路径与 add_library现在把项目扩展成三个文件目录结构hello_cmake/ ├── CMakeLists.txt ├── main.cpp └── utils/ ├── calc.h └── calc.cppmain.cpp里#include calc.h但这个头文件在utils子目录里编译器怎么找需要在 CMakeLists.txt 里声明头文件搜索路径。推荐用target_*风格cmake_minimum_required(VERSION 3.16) project(HelloApp LANGUAGES CXX) add_executable(hello_app main.cpp utils/calc.cpp ) target_include_directories(hello_app PRIVATE ${CMAKE_CURRENT_SOURCE_DIR}/utils )target_include_directories告诉构建系统“hello_app 这个目标在编译时要把utils目录加入头文件搜索路径而且这个路径只对 hello_app 有效”。PRIVATE 表示这些头文件路径仅在构建 hello_app 自己的源文件时生效细节放到下一章展开。这里有一个容易踩的坑写main.cpp里的include时要小心。如果utils目录下还有个同名头文件编译器搜索路径的顺序是“源文件所在目录优先然后是传入的-I路径”。所以上面的写法更推荐在代码里写#include utils/calc.h然后再把hello_cmake/根目录加进 include 路径这样头文件归属清晰不同模块之间也不容易撞名。4. 多目录组织与依赖管理PUBLIC、PRIVATE、INTERFACE 是怎么传播的4.1 一个典型项目的目录骨架实际项目的规模不会停留在单目录。假设你有这样一个结构myapp/ ├── CMakeLists.txt ├── core/ │ ├── CMakeLists.txt │ ├── engine.h │ └── engine.cpp ├── io/ │ ├── CMakeLists.txt │ ├── reader.h │ └── reader.cpp └── app/ ├── CMakeLists.txt └── main.cpp顶层 CMakeLists.txt 负责全局配置和添加子目录cmake_minimum_required(VERSION 3.16) project(MyApp LANGUAGES CXX) set(CMAKE_CXX_STANDARD 17) set(CMAKE_CXX_STANDARD_REQUIRED ON) add_subdirectory(core) add_subdirectory(io) add_subdirectory(app)add_subdirectory会进入每个子目录执行那个目录里的 CMakeLists.txt。每个子目录各自定义自己的编译目标互不干扰。core/CMakeLists.txtadd_library(core SHARED engine.cpp) target_include_directories(core PUBLIC ${CMAKE_CURRENT_SOURCE_DIR})io/CMakeLists.txtadd_library(io SHARED reader.cpp) target_include_directories(io PUBLIC ${CMAKE_CURRENT_SOURCE_DIR}) target_link_libraries(io PRIVATE core)app/CMakeLists.txtadd_executable(main_app main.cpp) target_link_libraries(main_app PRIVATE io core)这里注意add_library(core SHARED ...)的含义创建一个名为core的目标类型为共享库动态库。SHARED 会产出.so或.dllSTATIC 会产出.a或.lib如果你不写类型CMake 默认会根据BUILD_SHARED_LIBS决定。新手很容易漏写类型导致最终生成的是静态库和预期不一致——链接符顺序、部署方式都会受影响。4.2 PUBLIC/PRIVATE/INTERFACE这三个关键字是 CMake 的精髓很多人背了target_link_libraries(app PRIVATE io core)但不理解为什么是 PRIVATE。其实这三个关键字解决的是“目标的使用者需不需要继承某些属性”PRIVATE这个属性只在当前目标编译时使用链接器、下游目标都不需要知道。比如core内部才需要某个头文件目录那就用 PRIVATE。PUBLIC当前目标需要并且链接到当前目标的下游目标也需要。典型场景是core的头文件本身引用了自己的头文件目录而io通过#include core/engine.h使用 core那io也必须能搜到 core 的头文件目录所以core/target_include_directories要用 PUBLIC。INTERFACE当前目标自己不需要但下游目标需要。比如你不想让某个编译选项用在编译当前库本身的过程中却想让链接了这个库的可执行程序带上这个选项就用 INTERFACE。这个传播机制本质上避免了早期 CMake 用全局include_directories()、link_libraries()带来的“全局污染”。全局命令会把路径和库强加给整个构建树里所有的目标一旦同名头文件出现在多个目录谁先被搜索到全看目录顺序特别容易产生“我这台机器能编译他那台就报错”的诡异问题。所以在现代 CMake 实践里我对include_directories和link_libraries的态度是尽量别用老项目的写法迁移过来时也值得主动换成target_*系列虽然前期改动看着麻烦但长远收益非常可观。4.3 引入第三方库的两种主流姿势find_package 与 FetchContent第三方依赖是现代项目绕不开的一环。CMake 最标准的做法是find_packagefind_package(OpenSSL REQUIRED) target_link_libraries(my_lib PRIVATE OpenSSL::SSL OpenSSL::Crypto)find_package的核心逻辑是CMake 在预设的搜索路径里查找名为 OpenSSL 的配置模块如果找到就定义出OpenSSL::SSL这种带命名空间的目标你只需要把它链接进自己的目标里。找不找得到由很多因素决定系统是否装了开发包、CMAKE_PREFIX_PATH是否指向库的安装目录、模块是否存在。后面报错章节里那个 NOTFOUND 变量告警八成就是卡在这一步。另一个实践里越来越常用的是FetchContentinclude(FetchContent) FetchContent_Declare( json URL https://github.com/nlohmann/json/releases/download/v3.11.2/json.tar.xz ) FetchContent_MakeAvailable(json) target_link_libraries(my_app PRIVATE nlohmann_json::nlohmann_json)FetchContent适合小体量、不想让用户自己安装的纯头文件库。它会在首次配置时把依赖源码下到构建目录之后作为构建目标参与编译。要注意的是URL 下载依赖网络离线环境会很痛苦所以这种模式我一般用在内部工具或 demo 项目对外发布的库仍然优先find_package让使用方自己管理依赖。5. 构建类型、安装与导出让项目不只是“能编译”5.1 Debug 与 Release 的差异及 CMAKE_BUILD_TYPE 的适用边界CMake 内置了几种构建配置最常用的是 Debug 和 Release。它们的差异不只在优化级别Debug 默认不优化、带调试符号方便 gdb 断点定位Release 默认-O3优化会去调试符号可能有各种编译期断言被裁剪。设置方式是在配置阶段传参数cmake -S . -B build -DCMAKE_BUILD_TYPEReleaseGitHub Actions 之类的 CI 里也常见矩阵跑 Debug/Release 两套。这里有个重要的使用边界CMAKE_BUILD_TYPE只对 Makefile 和 Ninja 这类“单配置生成器”有效。如果你用的是 Visual Studio 这种“多配置生成器”在配置时并不指定类型而是在构建时通过--config指定cmake --build build --config Release很多 Windows 新手在 VS 生成器下用-DCMAKE_BUILD_TYPERelease发现没有任何效果就是这个原因。所以在写跨平台 CI 脚本时我通常用cmake --build build --config $CONFIG而不是直接设CMAKE_BUILD_TYPE。5.2 合理设置编译选项不要直接在全局写 -Wall编译警告选项、优化参数都可以通过target_compile_options按目标设置。如果项目的多个库都想要同一套警告策略可以定义接口库统一管理add_library(warning_flags INTERFACE) target_compile_options(warning_flags INTERFACE $$CXX_COMPILER_ID:GNU,Clang:-Wall -Wextra -Wpedantic $$CXX_COMPILER_ID:MSVC:/W4 ) target_link_libraries(core PRIVATE warning_flags)这段代码里用到了生成器表达式$...它在构建时被求值根据编译器类型选择不同的警告参数。这也是 CMake 脱离“平台绑定”的关键招式你不需要写 if WIN32 判断编译器用生成器表达式的条件判断更清晰。5.3 install 规则让库可以被系统 find_package 找到如果你在做一个库项目光会add_library还不够用户拿到库源码后最终需要install到系统目录并提供一个配置文件让别的项目通过find_package找到它。install的基本用法install(TARGETS core EXPORT CoreTargets LIBRARY DESTINATION lib ARCHIVE DESTINATION lib RUNTIME DESTINATION bin INCLUDES DESTINATION include ) install(FILES engine.h DESTINATION include/core)这里EXPORT CoreTargets是重点它导出目标的信息生成一个可供 find_package 使用的目标列表。再加上CoreConfig.cmake.in模板PACKAGE_INIT include(${CMAKE_CURRENT_LIST_DIR}/CoreTargets.cmake)用configure_package_config_file处理一下这样一个库就具备了“可被外部项目 find_package”的能力。外部项目只需要find_package(Core REQUIRED) target_link_libraries(app PRIVATE Core::core)整条链路打通后你的工程才真正具备了交付能力。而不仅仅是在你的机器上能把二进制编出来。6. 高发报错与极致排查链路亲自把坑踩穿一遍6.1 NOTFOUND 告警一个非常典型的失败现场在热搜里那串红字——CMake Error: The following variables are used in this project, but they are set to NOTFOUND——几乎所有人都见过。我在一个项目里引入 OpenSSL 时第一次碰到它当时 CMake 输出大概是-- Found OpenSSL: /usr/lib/x86_64-linux-gnu/libssl.so CMake Error: The following variables are used in this project, but they are set to NOTFOUND. Please set them or make sure they are set and tested correctly in the CMake files: OPENSSL_CRYPTO_LIBRARY (ADVANCED)从头讲一下排查思路而不是直接背答案第一步先理解这个告警怎么产生。某处代码引用了一个变量变量的值是一个特殊的“NOTFOUND”标记。这个标记通常来自find_library、find_path、find_package等查找命令它们找不到目标时会把缓存变量设成VAR-NOTFOUND同时告警提示你这个变量虽然被使用但值等于 NOTFOUND。第二步去仓库里 grep 哪段代码用了这个变量grep -rn OPENSSL_CRYPTO_LIBRARY .常见的结果是某个 Find 模块最底下的逻辑在SET(OPENSSL_LIBRARIES ${OPENSSL_SSL_LIBRARY} ${OPENSSL_CRYPTO_LIBRARY})里引用了它而前一步查找OPENSSL_CRYPTO_LIBRARY失败。第三步确认它为什么失败。在 CMakeCache.txt 里搜grep -i OPENSSL CMakeCache.txt如果全是 NOTFOUND说明find_library(OPENSSL_CRYPTO_LIBRARY crypto ...)没有找到系统里的libcrypto。这时候需要看额外的诊断信息比如-- Found OpenSSL却找不到 crypto 库通常是因为系统缺少 libssl-dev或者安装了多个 OpenSSL 版本导致路径混乱。第四步解决后重新配置。注意如果你直接改 CMakeLists.txt 里的查找路径变量旧缓存可能继续失效。最稳的是删掉 build 目录重新配置至少也要删掉缓存里对应的 NOTFOUND 条目。我个人的习惯是凡是出现 NOTFOUND先删缓存重建能排除 50% 的“灵异问题”。6.2 缓存不更新为什么改了 CMakeLists.txt 却没效果CMake 配置阶段会把大量变量写到build/CMakeCache.txt里之后每次重新配置缓存里的值会被保留。这意味着你改了 CMakeLists.txt 新增了一个源文件重新构建时是生效的因为add_executable每次配置都会重新执行但如果你改了的是某个option变量值或从find_package解析的库版本那缓存里旧值会优先于你的新配置。我曾经在一个项目里发现find_package(OpenSSL 1.1.1 REQUIRED)一直链接到一个 1.0.2 的旧库排查半天发现 CMakeCache.txt 里OPENSSL_ROOT_DIR还被钉在旧路径上。问题根源是缓存变量和普通变量优先级不同——缓存的变量拥有更高持久性普通set()无法覆写它们除非用set(FORCE)或通过-D传入。实操中遇到“配置不生效”我的排查顺序是打开 build/CMakeCache.txt搜出相关变量看是普通变量还是 CACHE 类型。如果确定要清理直接rm -rf build然后重新配置。这是最暴力也最有效的方法。如果不想全删可以用cmake -U 变量名 -S . -B build单独剔除缓存条目。这个章节最后提示一下不要养成一改配置就全删缓存的重构习惯。正确做法是理解缓存机制确实需要时精准删除或指定新值但如果你正在快速试错阶段重建 build 目录反而是最省心的事。6.3 路径、空格与大小写你身边最常见的隐蔽雷区路径含空格Windows 上常见C:\Program Files\...。CMake 的命令有些能自动处理有些不行。比如target_include_directories(app PRIVATE C:/Program Files/MyLib/include)加引号能保证 CMake 层面正确透传。而如果路径放到了未加引号的变量里构造列表时空格就会被 CMake 当作多个参数的分隔符变量值会被切分。所以凡是包含路径的参数养成加引号习惯。大小写CMake 的命令名大小写不敏感ADD_EXECUTABLE和add_executable都能跑。但变量名大小写敏感而且目标名大小写敏感。我就遇到过在子目录里定义了add_library(Core ...)顶层链接时写成target_link_libraries(app PRIVATE core)结果报 target not found。排查到后面才意识到目标名大小写不一致。这属于看着离谱但在多人协作的大项目里真实高发的错误尤其当定义目标的文件和引用它的文件不是同一个人写时。链接顺序在写target_link_libraries时链接库的顺序会影响静态库解析。静态链接时符号解析是“从左到右”的被依赖的库要放在依赖方的右边。用 CMake 的target_link_libraries(app PRIVATE io core)理论上 CMake 会处理顺序但如果你长期用link_directories-lcore这种方式手动添加就会踩到 undefined reference 却不知道顺序错了的坑。这也是我一再强调用target_link_libraries而不是手拼参数的理由。6.4 使用 message 输出做微观诊断调试 CMakeLists.txt 时最有力的工具是message()。它可以打印普通信息、警告、错误也可以输出变量的值message(STATUS core binary dir: ${CMAKE_CURRENT_BINARY_DIR}) message(STATUS CMAKE_PREFIX_PATH: ${CMAKE_PREFIX_PATH})我在正式进入大型项目的迁移时经常在关键路径、查找结果前后插入message输出看实际传入的值是否符合预期。很多时候你写对了变量名但值根本不是你想要的。而message(WARNING)和message(FATAL_ERROR)还可以主动做断言一旦条件不满足直接终止配置把问题暴露在配置阶段而不是等到编译阶段。关于 CMake 学习路径的个人体会最后聊一点题外话。这些年我经手过不少 C/C 项目最直观的感受是CMake 的入门曲线其实很友好真正的学习成本在“怎么组织项目”上。很多人能跑通教程但一遇到真实项目就不知道该怎么拆目录、怎么定 PUBLIC/PRIVATE、怎么处理依赖。我的建议是不要一上来就追求把 CMake 里所有命令背熟而是先搭一个最小的多目录工程把可执行程序、静态库、动态库、install 各走一遍。跑通之后再引入 find_package 或 FetchContent 接第三方库。每增加一个环节就停下来看看 CMakeCache.txt 里发生了什么。这样两三个项目下来CMake 就不再是“背命令”的负担而是真正形成“项目说明书”的思维方式。如果你准备给自己的新项目写 CMakeLists.txt我的实操建议是第一天就写好顶层结构和两个库目标不要等项目长大以后再重构。构建系统这东西越晚动手成本越高。
阅读完成 · 觉得有帮助？
