★ FEATURED ARTICLE 简介CMake 3.30.3 Windows x86-64 版本资料面向在 Windows 64 位环境下使用 C 的开发者尤其适合需要离线查阅构建系统配置、迁移旧项目或排查生成器与编译参数问题的人群。包内共 2000 个文件以 1147 个 txt 和 853 个 html 为主html 多为命令、变量、生成器表达式、构建系统、预设与 CTest 等参考页面txt 则可作纯文本检索与摘录压缩包约 43.34MB。已有 511 人学习说明该版本文档对实际开发具有一定参考价值。读者可据此了解 CMakeLists.txt 的组织方式、生成器表达式写法、File API 与 Presets 的用法并借助索引页面快速定位命令说明适合作为 Windows 平台 C 项目构建配置的案头查阅材料。1. 从「cmake 不是内部或外部命令」说起cmake-3.30.3-windows-x86-64 装给谁用上周给一台刚重装的 Windows 机器配 C 环境Visual Studio 装完cl 编译器也在敲cmake --version却只回一句「cmake 不是内部或外部命令」。还有一种更难受的机器上其实有 cmake但某个 IDE 自带的旧版本占了 PATH 首位configure 跑到一半报「CMake 3.20 or higher is required」。cmake-3.30.3-windows-x86-64 这个包解决的就是这类问题一份版本明确、路径干净、原生 x86-64、不依赖额外运行库的 CMake。它适合两类人用 Visual Studio 做主力的和用 MinGW、Ninja 走命令行流派的 C Windows 开发者。装错了不会立刻报错而是在生成器选择、presets 解析、链接路径上一点点消耗时间。2. 装前把环境列清Windows 上两套 C 工具链和 3.30.3 的版本门槛CMake 本身只是个构建系统的生成器它不编译任何东西真正的编译活是 MSVC 或者 GCC 干的。所以装 CMake 之前先确认机器上已经有能用的编译器否则装完 3.30.3 也只会得到一句「No CMAKE_CXX_COMPILER could be found」。这一步很多人跳过后面所有报错都从这儿来。2.1 三张对照表先过一遍系统、编译器、生成器在 Windows 上做 C路线基本就两条MSVC 系Visual Studio 或 Build Tools和 MinGW 系GCC 移植版 Ninja 或 make。两条路线对应的 CMake 生成器完全不同装之前心里要有数。环节MSVC 路线MinGW 路线说明编译器cl.exeg.exe二者只需一套装两套也能共存构建器MSBuildninja.exe 或 mingw32-make.exeNinja 需要单独放CMake 生成器Visual Studio 17 2022 / NMake MakefilesNinja / MinGW Makefiles名字必须一字不差构建类型多配置Debug/Release 同时存在单配置configure 时定死决定了 --config 参数要不要写平台位宽-A x64由编译器自身决定x86-64 包不用额外指定这张表最关键的信息是最后两行。多配置生成器Visual Studio在 configure 阶段不区分 Debug 和 Release构建时用--config Release指定单配置生成器Ninja、MinGW Makefiles必须在 configure 阶段用CMAKE_BUILD_TYPE定下来之后再改就得重新 configure。搞混这两个会出现「明明加了 --config Release 却还是 Debug 产物」的玄学现象。系统层面Windows 10 1809 以后的版本都能跑 3.30.3Windows 11 同理。x86-64 这个后缀指的是安装包和可执行文件都是 64 位32 位系统用不了。如果你还在维护 32 位目标程序那也不冲突CMake 是 64 位进程但可以通过-A Win32交叉生成 32 位工程。2.2 安装前扫一遍机器四条命令摸清家底别急着双击安装包先开一个普通命令提示符把下面几条挨个敲一遍。这一步在运维里叫「基线确认」花两分钟能省掉后面半小时的排查。:: 1. 看看现在有没有 cmake有的话在哪 where cmake :: 2. 如果有版本是多少 cmake --version :: 3. 看 MSVC 编译器在不在 PATH 里多半不在正常 where cl :: 4. 看 MinGW 编译器在不在 where gwhere是 Windows 上的路径查询命令它会按 PATH 顺序把所有同名可执行文件列出来而不是只列第一个。这一点非常有用如果输出里出现两行以上说明你机器上装了多份 cmake后面一定要处理顺序问题。where cl大概率是「找不到」这不代表没装 Visual Studio只是 VS 的开发者环境变量要进 Developer Command Prompt 才会注入属于正常现象。where g则能反映 MinGW 是否已经在 PATH 里。第二条要看的不只是有没有版本号还要看版本数字。如果机器上已经有一个 3.16 之类的老版本而你的项目里CMakePresets.json用了较新的 schema那份老 cmake 会直接报 schema 不认识的错误而错误信息往往只写「Unsupported presets version」不告诉你是谁在解析。这种情况我一般先把老版本从 PATH 里摘干净再装 3.30.3。2.3 版本取舍为什么落在 3.30.3 而不是别的号CMake 的版本兼容策略是「向后能读、向前不能读」高版本能读低版本写的 CMakeLists反过来不行。所以选版本的核心不是追新而是找到一条下限足够低、上限足够覆盖现代特性的线。3.30 这条版本线对 Windows C 项目来说值得注意的能力集中在三块。一是CMakePresets.json的 schema 演进到较新的版本configurePresets里的architecture、toolset、cacheVariables组合写起来更顺手团队里共享一份 presets 就能对齐所有人的构建参数。二是对 Visual Studio 生成器的支持覆盖到较新的 VS 版本不用为了生成器名去改 CMake 版本。三是若干模块修了路径处理和依赖查找的小问题这些在日常 configure 里表现为「偶发失败」很难定位。3.30.3 是 3.30 分支上的补丁版本。补丁版本修的是发布之后发现的缺陷不动接口不动行为约定所以它比 3.30.0 稳又不像跨大版本那样引入行为变更。我个人选版本的顺序是先看项目里cmake_minimum_required写的多少再看团队 CI 镜像里装的多少最后在同一条版本线上取最新补丁。三个条件取交集往往就落在某个 x.y.z 上。这次是 3.30.3。反过来说什么情况下不该用这个包如果项目里明确写死了cmake_minimum_required(VERSION 3.31)或者用到了 3.31 才有的特性那 3.30.3 就不够。如果团队统一在某个更老的版本上协作你一个人装 3.30.3 通常没问题因为高版本能读低版本的项目但如果你的 3.30.3 生成了某些新格式的缓存或 presets 提交进仓库别人的老版本就可能读不了。这种情况我一般建议把版本要求写进 README而不是靠口口相传。2.4 安装位置和权限别装进带空格和中文的路径最后一件装前要定的事是把 CMake 放哪。安装包默认会往C:\Program Files\CMake走这是最省心的选择路径里虽然有空格但 CMake 自己处理得没问题问题是某些第三方脚本和老的 Makefile 生成器对空格敏感。我的做法是把源码目录、构建目录、CMake 安装目录全部放在纯英文短路径下比如C:\dev\和C:\tools\。原因不复杂Windows 上有一批工具链组件对路径长度有 260 字符的限制构建目录本身就很深build\CMakeFiles\xxx.dir\Release\再叠上中文用户名或者长项目名很容易在中途某个中间文件上翻车报错还指向一个看不出问题的文件名。这种事经历过一次就长记性了。权限方面装到C:\Program Files需要管理员权限装到C:\tools这类自建目录则普通用户即可。如果你是给多人共用的机器做部署装到 Program Files 更规矩如果只是自己开发机装到自建目录反而方便多版本共存和手工切换。3. 装 3.30.3msi 安装包和 zip 便携版各走一遍拿到的包有两种形态.msi安装程序和.zip免安装压缩包。它们里面的 cmake.exe 是同一个差别只在「谁来管 PATH」和「能不能多版本共存」。选哪种取决于你是给自己装还是给一批机器装。3.1 msi 安装向导三个必须停下来看一眼的选项双击 msi 之后一路下一步也能装完但有三处值得停一下。第一处是许可协议之后的安装路径。默认C:\Program Files\CMake保持默认即可除非你和我一样把工具链统一放在C:\tools下集中管理。改路径的代价是后面配 PATH 时要用新路径别忘了。第二处是 PATH 选项向导里通常给三个选择不加入 PATH、为当前用户加入 PATH、为所有用户加入系统 PATH。这是整个安装里影响最大的一步。:: 安装完成后验证先看 cmake 落在哪 where cmake :: 再看版本必须是 3.30.3 cmake --versionwhere cmake应该输出你刚选的安装路径下的bin\cmake.exe。如果输出为空说明 PATH 没生效最可能的原因是当前终端是安装之前就打开的环境变量还是旧的。关掉重开一个终端再试这一步能解决九成的「装完了但找不到命令」。关于 PATH 选项怎么选给当前用户装选「当前用户」给多账户共用的构建机装选「所有用户」后者需要管理员权限。我个人偏好「所有用户」加固定路径因为 CI 机器上跑构建的账户可能不是安装时登录的那个账户用户级 PATH 在别的账户下不生效这个坑很隐蔽。第三处是安装完成前的确认页注意看它有没有勾选「Add CMake to the system PATH for all users」这一类复选框有些版本会把它放在最后一页。别一路回车点过去。3.2 zip 便携版解压落位、目录规划和多版本共存zip 版适合三类场景没有管理员权限、需要同时装多个 CMake 版本、以及需要把工具链打进镜像或压缩包分发。解压之后目录结构是这样的cmake-3.30.3-windows-x86_64\ ├── bin\ │ ├── cmake.exe │ ├── ctest.exe │ ├── cpack.exe │ └── cmake-gui.exe ├── doc\ ├── share\ │ └── cmake-3.30\ │ └── Modules\ # 所有 FindXXX.cmake 模块都在这 └── bin\ # 部分运行库 dll真正要进 PATH 的只有bin这一层。share\cmake-3.30\Modules里是 CMake 自带的查找模块find_package能不能找到某个库很大程度上取决于这里的模块和你的CMAKE_PREFIX_PATH配合得好不好。doc目录可以不管。我的落位习惯是给每个版本一个独立目录再用 PATH 顺序切换:: 目录规划每个版本独立一层不互相覆盖 C:\tools\cmake\3.30.3\bin C:\tools\cmake\3.28.6\bin :: 需要切回旧版本时只改 PATH 顺序不动文件 set PATHC:\tools\cmake\3.30.3\bin;%PATH%这种做法的好处是随时能切回去对比行为差异排查「是不是 CMake 版本引起的」这类问题时特别值。代价是你得自己维护 PATH装新版本时记得把旧目录从系统 PATH 里摘掉不然两个版本会打架。还有一种更干净的做法完全不进系统 PATH只在使用时临时set PATH...或者写进项目的构建脚本开头。这样机器上可以放五六个版本互不干扰缺点是每次开新终端都得设一遍适合脚本化程度高的团队。3.3 卸载与回滚装坏了怎么退回上一个版本msi 安装的卸载走「设置 → 应用 → 已安装的应用」找到 CMake 卸载即可也可以用命令行静默卸载:: 静默卸载/x 后面跟的是 msi 的产品码需先在注册表或安装日志里查到 msiexec /x {产品码} /qn :: 卸载完检查残留 where cmake/qn表示无界面静默执行适合批量机器。卸载之后where cmake如果还能找到路径说明 PATH 里还留着旧条目需要手工去环境变量里删掉否则终端会一直报「找不到指定路径」这类干扰信息。zip 版的「卸载」就是删目录但 PATH 里的条目不会自动清掉得手动编辑环境变量。这一点在批量部署时要写进操作手册。回滚这件事我有个教训升级 CMake 之前先确认项目能接受新版本。曾经有一次把构建机从老版本升到新版本结果项目里的某个FindXXX.cmake自写模块依赖了旧版的内部变量升级后行为变了构建虽然通过但链接的库路径不对跑起来才崩。从那以后我升级前都先在分支上完整跑一遍 configure build test确认没问题再动构建机。CMake 本身的安装是可逆的麻烦的是它生成的构建缓存不可逆。4. 配置PATH 顺序、默认生成器与一份能跑的最小工程装完只是把文件放到位真正让它在你机器上「顺」起来还得处理三件事PATH 顺序、默认生成器、以及构建目录的位置。4.1 PATH 怎么写顺序决定你实际用的是哪个 cmakeWindows 的 PATH 是从前往后找的先找到谁就用谁。所以「装了 3.30.3 但cmake --version显示 3.22」这类问题本质就是老版本排在前面。:: 按 PATH 顺序列出所有 cmake第一行才是实际生效的 where cmake :: 想确认某个具体文件的版本直接带全路径调 C:\Program Files\CMake\bin\cmake.exe --versionwhere的输出是有序的第一行就是系统实际会执行的那一个。这个命令在排查「版本对不上」时比cmake --version更有价值因为后者只告诉你结果前者告诉你原因。常见的抢占者有几个某些 IDE 会把自带的 cmake 塞进 PATHPython 的某个包会装一份 cmake 到 Scripts 目录还有一些 SDK 会把工具链目录整体加进环境变量。处理办法不是逐个卸载而是把你自己的安装路径挪到 PATH 最前面。另一个容易被忽略的点是在 Developer Command Prompt 里打开终端VS 会重新排一遍 PATH可能把它的 cmake 顶到前面。我一般在这种环境里用where cmake再确认一次不放心就直接用全路径调用。4.2 CMAKE_GENERATOR 与 -G把默认生成器固定下来不指定生成器时CMake 会自动挑一个。Windows 上的挑选逻辑是如果装了 Visual Studio选版本最高的那个否则退回 NMake Makefiles 或 MinGW Makefiles。这个「自动」在单机开发时挺省事在多机协作时就是灾难三个人三台机器configure 出来的东西不一样问题复现不了。:: 显式指定生成器多配置写法需要对应 VS 已安装 C 工作负载 cmake -S . -B build -G Visual Studio 17 2022 -A x64 :: 单配置写法需要 ninja.exe 已在 PATH 中 cmake -S . -B build -G Ninja -DCMAKE_BUILD_TYPERelease :: 查看本机所有可用生成器名字必须一字不差地抄 cmake --help-G后面的生成器名必须和cmake --help列出来的完全一致包括空格和大小写。写成Visual Studio 2022会直接报找不到生成器因为正确的名字里带版本号17。-A x64只在 Visual Studio 这类多配置生成器上有效作用是声明目标平台不写的话默认按宿主平台走多数情况下也是 x64但显式写出来更保险。如果不想每次敲-G可以用环境变量固定默认值:: 设成当前会话的默认生成器新开终端就失效 set CMAKE_GENERATORVisual Studio 17 2022 set CMAKE_GENERATOR_PLATFORMx64 :: 设成用户级永久变量需要重开终端生效 setx CMAKE_GENERATOR Visual Studio 17 2022 setx CMAKE_GENERATOR_PLATFORM x64set只影响当前终端适合临时试验setx写进用户环境变量永久生效但不会影响已经打开的窗口。这两个变量 CMake 都会读优先级低于命令行-G所以设了默认值之后仍然可以单次覆盖。4.3 一份最小工程CMakeLists、main.cpp、Presets 三件套配置讲再多不如跑一遍。建一个空目录放三个文件能 configure、能编译、能出 exe就说明 3.30.3 在你这台机器上是通的。# CMakeLists.txt cmake_minimum_required(VERSION 3.20) project(hello_cmake LANGUAGES CXX) set(CMAKE_CXX_STANDARD 17) set(CMAKE_CXX_STANDARD_REQUIRED ON) # MSVC 下强制 UTF-8 源码与执行字符集避免中文输出乱码 add_compile_options($$CXX_COMPILER_ID:MSVC:/utf-8) add_executable(hello main.cpp)cmake_minimum_required我写的是 3.20 而不是 3.30原因是这个值代表项目能接受的最低版本不是本机版本。写高了会让同事和 CI 直接 configure 失败写 3.20 既能用上 3.30.3 的新特性又不会把门槛抬死。LANGUAGES CXX只声明 C能省掉一次 C 编译器探测configure 快一点。/utf-8那条生成器表达式只在 MSVC 下生效MinGW 不受影响这样一份 CMakeLists 两套工具链都能用。配套的源文件和 presets// main.cpp #include iostream int main() { std::cout cmake 3.30.3 ok\n; return 0; }{ version: 6, configurePresets: [ { name: msvc-x64, generator: Visual Studio 17 2022, architecture: x64, binaryDir: ${sourceDir}/build/msvc-x64, cacheVariables: { CMAKE_CXX_STANDARD: 17 } }, { name: ninja-release, generator: Ninja, binaryDir: ${sourceDir}/build/ninja-release, cacheVariables: { CMAKE_BUILD_TYPE: Release, CMAKE_CXX_STANDARD: 17 } } ], buildPresets: [ { name: msvc-x64, configurePreset: msvc-x64, configuration: Release }, { name: ninja-release, configurePreset: ninja-release } ] }presets 里的version: 6对应较新的 schema3.30.3 完全支持。这里故意写 6 而不写最新的 schema 号是因为 schema 版本越高能读它的 CMake 版本就越少团队里只要有一台机器版本偏低就全组用不了。binaryDir用${sourceDir}加预设名分开两套生成器不会互相覆盖缓存这是多工具链并存的关键。buildPresets里configuration只有多配置生成器才需要Ninja 那份不写因为构建类型在 configure 阶段已经定死了。调用方式:: 用预设 configure不需要背生成器名 cmake --preset msvc-x64 :: 用预设构建 cmake --build --preset msvc-x64 :: 直接跑产物 build\msvc-x64\Release\hello.exe--preset是 3.19 之后引入的用法它把生成器、架构、缓存变量打包成一个名字团队协作时只要保证大家拿到同一份CMakePresets.jsonconfigure 结果就是一致的。这比在 README 里写一长串命令行靠谱得多。4.4 构建目录的位置为什么不该放在源码里默认情况下在源码目录里直接cmake .会把缓存文件、生成的项目文件全撒在源码旁边git status一片红。虽然能靠.gitignore挡住但清理起来仍然烦。标准的做法是 out-of-source也就是在源码目录之外单独建构建目录。-S指定源码-B指定构建目录这两个参数是 3.13 之后的形式比老式的进目录再 cmake 更清晰。构建目录放哪也有讲究。放在源码下的build/是最常见的好处是相对路径稳定坏处是路径深度叠加快。放在C:\b\项目名\这种短路径下能有效规避 Windows 260 字符限制引发的中间文件报错。如果项目层级深、目标名长我一般直接把构建目录丢到短路径盘根目录下。另外构建目录里最重要的文件是CMakeCache.txt它记录着上次 configure 时探测到的所有路径和变量。切换生成器、换编译器、移动源码位置之后这个缓存就失效了必须整个目录删掉重来。很多「明明改对了还是不生效」的问题删掉构建目录就好了这条经验后面还会再提一次。5. 排查装完 cmake 却 configure 不过的五种典型现场下面这几条都是我实际踩过的按「现象 → 原因 → 解决」记方便对照。5.1 命令层面找不到、版本不对、多个共存坑 1cmake --version显示的版本不是 3.30.3现象是装完包、重开终端版本号还是老样子或者干脆提示命令不存在。原因多半是 PATH 里有更靠前的老版本或者安装时根本没勾选加 PATH还有一种情况是当前终端沿用了安装前的环境快照。解决方式是先用where cmake把候选全列出来第一行不是 3.30.3 的路径就去环境变量里把它挪后面或者直接删掉那条。如果where cmake什么都没输出去「系统属性 → 环境变量」手工加一条C:\Program Files\CMake\bin然后重开终端。别在已打开的窗口里反复试环境变量不会热更新。坑 2CI 机器上能装不能用现象是安装过程没报错但构建脚本执行 cmake 时提示找不到命令。原因是安装时选了「仅当前用户」而 CI 的执行账户是另一个。用户级环境变量在别的账户下读不到。解决办法是改用「所有用户」安装或者干脆走 zip 版在构建脚本开头显式把bin目录拼进 PATH。批处理里这么写:: 构建脚本开头显式设置不依赖系统环境变量 set CMAKE_DIRC:\tools\cmake\3.30.3 set PATH%CMAKE_DIR%\bin;%PATH% cmake --version这么做的好处是整个构建的环境依赖在这个脚本里是自解释的换台机器也不用去翻系统设置。5.2 生成器与编译器层面选错了就一路错坑 3No CMAKE_CXX_COMPILER could be found现象是 configure 一开始就失败提示找不到 C 编译器。原因有两种一是机器上确实没装编译器只装了 CMake二是装在 PATH 之外CMake 默认探测不到。前者去装 Visual Studio 的「使用 C 的桌面开发」工作负载或者装 MinGW。后者用-DCMAKE_CXX_COMPILER显式指定路径:: 显式指定编译器路径换成你机器上的实际位置 cmake -S . -B build -G Ninja ^ -DCMAKE_CXX_COMPILERC:/tools/mingw64/bin/g.exe ^ -DCMAKE_C_COMPILERC:/tools/mingw64/bin/gcc.exe路径用正斜杠或者双反斜杠都行单反斜杠会被当成转义。这条命令只在首次 configure 有效缓存生成之后再改要用新目录。坑 4生成器名报错 could not find any instance of Visual Studio现象是-G Visual Studio 17 2022报找不到对应的 VS 实例。原因通常是 VS 装了但没装 C 工作负载或者装的是更老的版本。先去 VS Installer 里确认「使用 C 的桌面开发」已勾选再用cmake --help看生成器列表里到底有哪些 VS 条目按列出来的名字改。列表里没有的版本就是不支持硬写没用。5.3 缓存与路径层面最像玄学的一类坑 5改了 CMakeLists 却完全不生效现象是改了源码目录里的配置重新构建行为一点没变。原因一般是构建目录里的CMakeCache.txt还记着旧值或者你在另一个构建目录里构建。解决办法很直接删掉构建目录重来。:: 彻底重来注意 build 目录会整个消失 rmdir /s /q build cmake --preset msvc-x64 cmake --build --preset msvc-x64我一般把这条当成「后悔药」任何配置层面的诡异问题先删缓存重来一次能排除掉大半。剩下的才是真问题。另外从别的机器拷过来的 build 目录一定要删缓存里存的是绝对路径换台机器全部失效报错信息还常常指向不存在的路径看着像黑匣子。还有一类和路径长度有关。现象是 configure 通过编译到某个中间文件时报「文件名或扩展名太长」。原因是 Windows 默认的 260 字符路径限制。解决办法是把构建目录挪到短路径或者在系统里开启长路径支持组策略里的「启用 Win32 长路径」再不行就精简目标名。这个问题在深层嵌套的第三方依赖里特别常见。6. 验收三档检查确认 3.30.3 真的能编译出 exe装完不验证等于没装。我习惯分三档验收从「命令存在」到「产物能跑」一档不过就别往下走。档位检查内容通过标准不通过大概率原因一档where cmake、cmake --version首行是 3.30.3 的路径PATH 顺序、安装未勾选 PATH二档cmake --help生成器列表、configure目标生成器在列表里且 configure 返回 0编译器缺失、生成器名写错三档build 出 exe 并执行exe 存在且输出预期文本构建类型选错、启动配置错误一档的命令前面已经用过重点看where的第一行。二档有个小技巧cmake --help输出很长可以直接过滤生成器那一段。:: 只看生成器列表确认目标生成器确实存在 cmake --help | findstr /C:Visual Studio 17 2022 /C:Ninja /C:MinGW Makefiles :: 二档验收configure 并观察返回码 cmake --preset msvc-x64 echo %ERRORLEVEL%findstr的/C:表示按完整字符串匹配比默认的分词匹配准。%ERRORLEVEL%为 0 才是成功非 0 时不要急着看后面的输出先往上翻找第一处Error那才是根因后面的大多是连锁反应。三档最关键的一步不是 build 成功而是产物真的能跑起来。有些配置错误只影响运行时比如运行库链接方式不一致编译链接都过一执行就报缺少 dll。所以我的习惯是编译完立刻执行一次。:: 三档验收构建 执行一步到位 cmake --build --preset msvc-x64 build\msvc-x64\Release\hello.exe :: 顺便验证 install 规则检查安装前缀是否正确 cmake --install build\msvc-x64 --prefix dist dir dist--install是 3.15 之后的形式替代了老式的make install。它会把install()规则里声明的文件拷到--prefix指定的目录如果这一步报「file INSTALL cannot find」说明构建产物路径和目标配置对不上多半是构建类型选错比如构建了 Debug 却按 Release 去找。还有一条容易被忽略的验收项ctest。如果项目里有测试装完新版本 CMake 之后跑一遍ctest --test-dir build\msvc-x64 -C Release能顺带验证测试发现机制是否正常。-C参数在多配置生成器下必须给否则 ctest 不知道跑哪个配置的用例。从那以后我每次装完 CMake不管多急都强制走一遍「where cmake → cmake --version → configure → build → 执行产物」这套流程五分钟的事能挡掉后面几小时的莫名其妙。装工具这件事验收到产物这一层才算真的装完看到cmake 3.30.3 ok从自己编出来的 exe 里打出来心里才踏实。希望帮到你。本文还有配套的精品资源点击获取
阅读完成 · 觉得有帮助？
