C++游戏开发入门：从零搭建你的第一款完整2D游戏

这次我们来看一门 Udemy 上的 C++ 游戏开发入门课：“C++ Gamedev course for beginners - Your first big C++ game!”。和很多从语法讲起的 C++ 教程不同，这门课的名字就摆明了思路——用“做出第一款完整游戏”来驱动你学会 C++。如果你已经看腻了“变量、循环、函数”三件套，想直接上手写一个能跑、能玩、能拿出去展示的 C++ 游戏，这门课值得你先花几分钟看完我下面的拆解。

我先给你一个快速结论：这不是一门教你游戏引擎（Unreal、Unity）操作的课，而是一门用纯 C++ 从零搭游戏逻辑、逐步做出一款完整成品游戏的入门课。它的核心特点可以归纳为四条：

1. 零基础友好：面向没有系统学过 C++ 的初学者，语法讲解会在游戏项目的推进中穿插完成。
2. 项目驱动：整个课程围绕“你的第一款大型 C++ 游戏”展开，不是一道一道刷语法题。
3. 成品导向：学完会得到一个可运行、可操作、可扩展的完整游戏项目，能作为简历作品或继续开发的起点。
4. 技术栈经典：课程涉及 C++ 核心语法、游戏循环、状态管理、输入处理、基础图形渲染等通用能力，换到其他框架或引擎也能迁移。

本文下面会把这门课从“值不值得学”到“怎么跟着做”拆开讲，包括课程定位、开发环境搭建、游戏工程骨架、核心技术点测试顺序、常见踩坑和性能观察方法。即使你还没买课，也可以先把环境、编译流程和“先做最小 Demo”的方法跑通，再决定要不要跟完整套课程。

1. 核心能力速览

先把大家最关心的信息放在前面。下表根据课程标题、Udemy 平台属性和 C++ 游戏开发通用流程整理，具体章节安排和课时数量请以课程页面为准。

能力项	说明
平台	Udemy，在线视频课程，中英文字幕一般由 Udemy 平台提供，需以课程实际配置为准
课程目标	从零开始，完成“你的第一款大型 C++ 游戏”
前置要求	理论上零基础可跟；有一点编程概念会更快
开发语言	C++（以现代 C++ 标准为主，具体标准取决于讲师配置）
主要技术栈	C++ 语法、游戏循环、类设计、状态管理、输入处理、图形库（SFML/SDL 或类似 2D 库，以课程大纲为准）
最终产出	一个完整可运行的 2D C++ 游戏项目
学习形式	视频讲解 + 代码编写 + 项目里程碑
适合人群	C++ 初学者、从脚本语言转 C++ 的开发者、想用游戏项目作为学习动力的学生
不适合人群	想学 Unreal/Unity 编辑器操作的人；想直接学网络游戏多人架构的人
外部依赖	需安装 C++ 编译器、代码编辑器，可能需安装图形库和构建工具

需要注意，**“大型 C++ 游戏”**在这个入门课框架内，一般指功能完整、代码结构清晰、可玩性完整的 2D 游戏，而不是 3A 级商业作品。按 C++ 游戏开发入门课的常见惯例，游戏类型大概率是打砖块、飞机射击、俄罗斯方块、横版跳跃或贪吃蛇这一级别。课程真正的价值在于：让你完整走一遍“设计 → 编码 → 编译 → 运行 → 修 Bug → 优化”的闭环。

2. 课程定位与适用场景

2.1 这门课解决什么问题

很多初学者学 C++ 的现实困境是：语法书看了三章，指针还没搞懂，就开始怀疑人生。游戏开发课程的好处在于，每一个语法点都有明确的“使用场景”。比如：

• 结构体/类，可以在游戏中表示玩家、敌人、子弹。
• 数组/vector，可以管理一批子弹、一组敌人。
• 循环和条件，天然对应游戏的“每帧更新”和“碰撞判断”。

这门课用“做游戏”这个目标把零散语法串起来。你在课程中不光会写代码，还会反复调试、重构，最终体会到一个 C++ 小游戏从零到一的全过程。相比只讲语法的课程，这种方式的知识留存率更高。

2.2 适合谁，不适合谁

适合：

• 学过一点 C++，但只写过控制台程序，不知道 GUI/游戏项目从何下手的人。
• 做过 Python/JavaScript 小项目，想转 C++ 并希望有个有画面感的项目练手的人。
• 学生党，想完成一个课程设计、毕业设计的小游戏模块，或者单纯想用游戏提升编程兴趣。

不适合：

• 想学 Unreal Engine 5 或 Unity 的 C++ 脚本开发，方向不匹配。这类课程需要单独找引擎专项教程。
• 想深入图形渲染、Shader、3D 数学的人。入门游戏课程一般不会覆盖太多底层渲染细节。
• 想“看课就能学会”而不动手写代码的人。任何编程课都一样，只看不做等于没学。

2.3 使用边界与版权提醒

课程通常会提供示例代码、图片、音频素材。学习时可以自由修改和练习，但如果后面要把游戏上传到 Steam 或自己的网站公开发布，需要注意：

• 素材（音乐、图片、字体）是否有商用授权。
• 代码是否遵循讲师的开源协议（看课程描述和资源文件里的许可证）。
• 如果想基于课程项目做二次开发，建议彻底重写界面资源，换成自制素材。
• 涉及公开分享时，最好标注“基于 Udemy 课程项目重构”，避免版权纠纷。

3. 本地开发环境准备

用 C++ 做游戏，第一步不是写游戏逻辑，而是把“写代码 → 编译 → 运行”的环境搞定。很多新手在课程前 20 分钟就卡在编译器上，这里先给出一套通用检查清单。

3.1 操作系统

Windows、macOS、Linux 都可以。区别主要在于编译器和图形库的安装方式：

• Windows：优先推荐 Visual Studio Community 或 Visual Studio Code + MinGW-w64。
• macOS：可以用 Xcode Command Line Tools 自带的 clang，配合 Homebrew 安装依赖库。
• Ubuntu/Debian：使用 g++ 和 apt 安装图形库开发包。

3.2 编译器和工具链

如果你用的是 Windows 并选择 VS Code，需要先确认编译器和调试器能正常运行。在命令行执行：

g++ --version

如果能输出版本号，说明 MinGW-w64 或 MSYS2 环境已经可用。如果提示“g++ 不是内部或外部命令”，说明编译器没有安装或没有加入 PATH 环境变量。这个坑在“VSCode 配置 C/C++ 环境”相关教程里非常常见，核心就是三件事：

1. 安装 MinGW-w64 或 Visual Studio Build Tools。
2. 把编译器的 bin 目录加入系统 PATH。
3. 重启终端再验证版本。

3.3 代码编辑器

• Visual Studio Code+ C/C++ 扩展，轻量，适合课程跟做。
• Visual Studio Community，功能更全，断点调试方便，Windows 上做 C++ 项目很省心。
• CLion，如果可以接受商业 IDE 的授权模式，体验也很好。

初学阶段不用纠结哪个 IDE 最好，能把编译错误信息看明白的编辑器就是好编辑器。

3.4 图形库与运行时

游戏课程一般会引入一个 2D 图形库，常见的是 SFML 或 SDL。如果课程用的是 SFML，Windows 下注意把 SFML 的 bin 目录下的 DLL 放到 exe 同目录，否则运行时会提示缺少sfml-graphics-2.dll。如果你只是运行别人的 C++ 程序，有时会提示缺少VCRUNTIME140.dll或MSVCP140.dll，对应的是 Microsoft Visual C++ Redistributable 运行库没有安装，去微软官网下载对应的 x86/x64 Redistributable 安装即可。

3.5 磁盘与依赖管理

C++ 游戏项目一般不大，但建议预留 5-10 GB 空间，因为中间会有编译缓存、素材文件、多个版本迭代。如果你用 CMake 管理构建，保持源码目录和构建目录分离：

project/ ├── CMakeLists.txt ├── src/ ├── assets/ ├── build/ └── bin/

build/放编译中间文件，src/放源码，assets/放图片音频，bin/放最终可执行文件。这样项目结构清晰，后续做版本管理也方便。

4. 工程骨架与首个可运行 Demo

不管理论讲多少，先跑通一个窗口才是王道。这里给出一个基于 SFML 的最小游戏骨架，帮助你在正式跟课程之前就验证环境是否通顺。

4.1 CMake 配置示例

cmake_minimum_required(VERSION 3.16) project(MyFirstGame) set(CMAKE_CXX_STANDARD 17) set(CMAKE_CXX_STANDARD_REQUIRED ON) find_package(SFML 2.6 REQUIRED COMPONENTS graphics window system) add_executable(game src/main.cpp) target_link_libraries(game PRIVATE sfml-graphics sfml-window sfml-system)

如果 SFML 没安装，这一句find_package会报错。SFML 的安装方式因系统而异：Windows 可以下载官方二进制包，Linux 可以用 apt 安装libsfml-dev，macOS 可以用 Homebrew 执行brew install sfml。

4.2 最小游戏循环

#include <SFML/Graphics.hpp> int main() { sf::RenderWindow window(sf::VideoMode(800, 600), "My First Game"); sf::CircleShape player(20.f); player.setFillColor(sf::Color::Green); player.setPosition(400.f, 300.f); while (window.isOpen()) { sf::Event event; while (window.pollEvent(event)) { if (event.type == sf::Event::Closed) window.close(); } window.clear(sf::Color::Black); window.draw(player); window.display(); } return 0; }

这个代码做了一件事：打开一个 800x600 的窗口，画一个绿色圆点。看起来很简单，但它包含了一个游戏引擎最核心的骨架：

• 窗口初始化
• 事件处理循环
• 清屏 → 绘制 → 显示的帧循环

如果这个 Demo 能跑起来，说明你的编译器、图形库、链接配置全部正常。后面的课程内容，基本都是在这个循环里加入游戏逻辑。

4.3 编译与运行

如果你的环境是 VS Code + MinGW + CMake：

mkdir build cd build cmake .. cmake --build . ./game

如果编译成功却没有窗口弹出，优先排查：

• DLL 是否齐全。
• 显卡驱动是否存在兼容性问题。
• 是否在无图形界面的远程终端里运行。

5. 核心技术点拆解与测试顺序

课程的项目推进过程，一般会逐步引入下列 C++ 知识点。我把它们整理成“按游戏功能测试顺序”的清单，你跟着这个顺序验证，就能知道自己的理解有没有到位。

5.1 游戏循环：理解“每帧更新”

游戏和普通程序最大的区别是：普通程序跑一遍就结束，游戏需要每秒刷新几十次。这个刷新机制叫游戏循环。

课程里你会反复看到这样的结构：

while (游戏运行中) { 处理输入 更新游戏状态 渲染画面 }

你需要理解的几个点：

• while循环的退出条件。
• 每帧处理事件和每帧更新的区别。
• 为什么不能用sleep来控制帧率（会造成输入卡顿）。
• 帧率和时间步长（delta time）的关系。

验证方法：在更新函数里让角色每帧移动一个固定数值，观察游戏运行速度是否和帧率有关。如果帧率越高跑得越快，说明你要引入时间步长修正。

5.2 类与抽象：把游戏对象封装起来

当你开始写一个游戏，不能让所有数据都堆在main函数里。你需要定义玩家类、敌人类、子弹类。

一个典型的类设计：

class Player { public: void update(float dt); void draw(sf::RenderWindow& window); private: sf::Vector2f position; float speed; int hp; };

测试重点：

• 类的成员变量和成员函数怎么划分。
• 哪些数据是公有的，哪些必须是私有的。
• 构造函数怎么初始化。
• 后续要扩展新敌人时，是否需要重构。

这个阶段可能会接触到继承和多态。比如用基类Entity表示所有游戏对象，玩家和敌人继承它。课程里如果用了继承，一定要动手写一遍，而不是只看视频。

5.3 碰撞检测：让游戏有交互

游戏里“子弹击中敌人”“玩家碰到障碍物”都靠碰撞检测实现。最简单的形式是包围盒碰撞：

两个矩形相交，就认为发生碰撞

课程会带你怎么用矩形坐标判断重叠。判断逻辑不复杂，但你自己写一遍和直接抄代码，调试体验完全不同。你可以自己造几个测试用例：

• 两个矩形完全不重叠。
• 一个矩形在另一个矩形内部。
• 两个矩形边刚好接触。

然后输出结果，验证碰撞函数是否在每个用例下都正确。

5.4 数组 / vector / 字符串处理：管理大量对象

当屏幕上同时有多个子弹和敌人时，你需要容器来管理它们。C++ 里最常用的是std::vector。

课程会用类似下面的逻辑：

for (auto it = bullets.begin(); it != bullets.end();) { it->update(dt); if (it->isOutOfBounds()) it = bullets.erase(it); else ++it; }

这里涉及一个 C++ 新手非常容易踩的坑：在遍历 vector 的同时删除元素，不能简单用for (auto b : bullets)，因为迭代器会失效。课程如果没细讲，你自己测试时一定会遇到“删除子弹后程序闪退”的问题。

字符串处理在游戏里主要用在 UI 上，比如显示分数、生命值。你可以把分数存成int，每次变化后用std::to_string转成字符串再显示。C++ 的std::string和字符数组（char[]）的区别，建议在这个阶段彻底搞明白。

5.5 状态管理：让游戏结构清晰

游戏的运行不是从头到尾一条直线，而是有“主菜单 → 游戏进行中 → 暂停 → 游戏结束”这些状态。课程一般会用枚举或状态模式来做简单管理。

enum class GameState { Menu, Playing, Paused, GameOver }; GameState currentState = GameState::Menu;

每个状态下，更新逻辑和渲染内容都不同。这里可以测试：

• 按 Enter 从菜单进入游戏。
• 按 Esc 暂停游戏。
• 角色血量归零时跳转到 GameOver。
• 从 GameOver 是否能重新开始。

如果状态切换里遇到 Bug，先不要改代码，先在纸上画出状态转移图，再检查代码中的分支条件。

5.6 文件与资源管理

游戏需要加载图片、字体、音频。课程里一般会教你：

• 图片：sf::Texture先加载，再赋给sf::Sprite。
• 字体：sf::Font负责加载.ttf文件。
• 音频：sf::Music或sf::SoundBuffer。

关键坑是资源生命周期。很多人会写：

sf::Sprite player; void init() { sf::Texture tex; tex.loadFromFile("player.png"); player.setTexture(tex); // 错！tex 在这个函数结束时就被销毁了 }

结果是画面变成一片空白或者直接崩溃。你需要理解sf::Texture对象的生命周期必须比sf::Sprite更长，通常的做法是把纹理作为类的成员变量，或者用资源管理器统一加载。课程里如果讲到资源加载，建议测试三样东西：

1. 图片能不能正常显示。
2. 窗口大小改变后，画面是否保持正常比例。
3. 加载不存在的文件时，程序是优雅退出还是闪退。

6. 课程项目里程碑与效果验证

跟着课程做项目时，不建议看完一节课才写一次代码。更好的方式是：每个里程碑自己先尝试实现，再对照课程讲解。下面给出一套典型里程碑和对应的验证标准。

6.1 里程碑一：窗口和移动对象

目标：创建一个窗口，显示一个可控制的方块或圆，能用方向键/WASD 移动。

验证标准：

• 按住方向键时角色持续移动。
• 松开按键后角色停止。
• 窗口关闭按钮生效。
• 角色不会移出屏幕边界，或者移出后能从另一侧出现。

常见失败：角色移动不平滑、按键反应迟钝。原因通常是事件处理逻辑写在了pollEvent里而不是每帧更新里，或者没有使用isKeyPressed来获取连续按键状态。

6.2 里程碑二：加入可交互对象

目标：游戏中有一个玩家可控对象，多个可收集物品或敌人。

验证标准：

• 玩家和对象发生碰撞后，对应效果触发。
• 收集物品后，计数增加。
• 敌人碰到玩家后，玩家生命值减少或游戏结束。
• 碰撞效果不会反复触发（这是最常见的 Bug，比如碰到敌人一次就疯狂掉血）。

6.3 里程碑三：游戏流程完整

目标：主菜单、游戏画面、游戏结束三个状态可切换。

验证标准：

• 启动后进入菜单。
• 菜单按指定键进入游戏。
• 游戏结束后能显示分数和重新开始选项。
• 整个流程中没有未处理的崩溃。

6.4 里程碑四：打磨与扩展

目标：加入音效、粒子特效、得分动画、存档等功能中的至少一项。

验证标准：

• 新增功能不影响原有逻辑。
• 游戏帧率没有明显下降。
• 代码结构和课程前几个阶段相比有合理扩展。

这一步是区分“跟完课”和“学明白”的分水岭。建议不要把代码停留在“能跑”的程度，试着增加一个敌人类型、增加一张地图、改写一个 UI 布局。这样课程学完，你实际获得的经验会超出视频本身。

7. 工程化实践：构建脚本、日志与自动化

入门课程可能不会花太多时间讲工程化，但你自己练习时可以从一开始就建立好习惯。这里单独列一节，是因为这部分能把你和“只会写小 Demo”的初学者区分开。

7.1 使用 CMake 管理构建

哪怕课程用的是简单的g++ main.cpp -o game，我也建议你同时学习 CMake。理由很直接：

• 后续加源文件时，g++ 命令会越来越长。
• CMake 能自动处理平台差异。
• CMake 配合 IDE 时，调试配置更省心。

真实的项目结构和课程不同，你需要自己组织。一个轻量写法：

file(GLOB_RECURSE SOURCES "src/*.cpp") add_executable(game ${SOURCES}) target_include_directories(game PRIVATE include)

GLOB_RECURSE会自动收集src目录下所有 .cpp 文件，适合小项目快速迭代。项目变大后，建议手动列源文件或按目录分组。

7.2 日志与调试

游戏崩溃时，只靠弹窗和输出很难快速定位。建议在项目中加一个简单的日志函数，输出文件名、行号和消息：

#include <iostream> #define LOG(msg) std::cout << __FILE__ << ":" << __LINE__ << " -> " << msg << std::endl

在碰撞检测、状态切换、对象生成这些关键位置打印日志，运行后就能看到程序的执行流程。批量任务、自动化测试的逻辑也可以用同样的思路：把游戏的某个模块抽出来做单元测试，输入一组配置，检查输出是否符合预期。

7.3 批量资源处理

游戏素材多的时候，手动重命名和转换非常痛苦。用 C++ 的std::filesystem写一个小工具脚本，可以批量检查资源是否缺失、文件大小是否异常：

#include <iostream> #include <filesystem> namespace fs = std::filesystem; int main() { for (const auto& entry : fs::directory_iterator("assets")) { auto size = entry.file_size(); std::cout << entry.path() << " - " << size << " bytes" << std::endl; } return 0; }

编译和运行这个工具时，只需要标准库和-std=c++17编译选项，不需要图形库。对于课程项目来说，这会节省大量手工检查时间。

8. 资源占用与性能观察

如果你是做 2D 入门游戏，性能压力没有 3D 游戏那么大，但仍有两个指标值得关注：CPU 占用和内存增长。

8.1 帧率观察

在游戏窗口标题栏显示当前 FPS，是最简单的性能反馈方式：

sf::Clock clock; float fps = 0.f; int frameCount = 0; float elapsed = 0.f; // 在游戏循环中 float dt = clock.restart().asSeconds(); elapsed += dt; frameCount++; if (elapsed >= 1.f) { fps = frameCount / elapsed; window.setTitle("FPS: " + std::to_string(fps)); frameCount = 0; elapsed = 0.f; }

观察重点：

• 持续运行 10 分钟后 FPS 是否下降。
• 是否出现内存持续上涨（可能是每帧创建对象但没有销毁）。
• 窗口最小化再恢复后，是否恢复正常运行。

8.2 如何降低开销

常见优化手段：

• 避免每帧加载纹理和字体。
• 尽量复用对象而不是频繁 new/delete。
• 不要每帧创建sf::Text字符串，容易造成字符串频繁构造。
• 粒子数量控制在一个合理范围。

入门阶段不需要追求极致性能，但要养成“看到掉帧就排查资源是否反复加载”的习惯。

8.3 显存和 GPU 占用

2D 游戏对显存要求很低，但如果你用的电脑是核显，开很多窗口或屏幕分辨率过高时，也可能卡顿。这时可以降低窗口大小、减少特效透明层数量。课程项目如果只是 800x600 的窗口，常规电脑基本都能流畅运行。

9. 常见问题与排查方法

C++ 学习过程中，90% 的时间不是写代码，而是解决编译和运行错误。这里整理一张高频问题表。

问题现象	可能原因	排查方式	解决方案
窗口弹出后黑屏，没有任何绘制内容	纹理加载失败或资源路径错误	检查loadFromFile返回值	使用绝对路径测试，确认图片文件存在
按键没有反应	事件处理逻辑错误或没有调用pollEvent	在按键分支加日志	确认使用的是isKeyPressed而不是KeyPressed事件
角色移动卡顿	未使用 delta time，或窗口有垂直同步问题	看 FPS 是否高于 60	引入浮点时间步长，启用垂直同步
程序闪退	访问空指针、vector 迭代器失效、DLL 缺失	查看系统日志或调试器输出	在 Debug 模式下编译，检查崩溃调用栈
提示缺少 VCRUNTIME140.dll	没有安装 Visual C++ Redistributable	确认系统是否缺少运行库	安装 Microsoft Visual C++ Redistributable 对应版本
SFML 链接失败	没有正确链接库或库版本不匹配	查看 CMake 缓存中的 SFML_DIR	使用与编译器位数匹配的库文件
代码编译成功但运行时没有声音	音频文件格式不支持或路径错误	检查音频文件格式	转换成 wav/ogg，检查文件路径
FPS 持续下降	对象每帧创建未清理	打开任务管理器观察内存	用 vector 管理对象并定期清理
游戏窗口无法关闭	没有处理sf::Event::Closed事件	检查事件循环	在事件循环中加入关闭分支
界面中文乱码	字体不支持中文	检查字体文件的字符集	使用支持中文的字体，或改用 UTF-8 加载

补充一点：C++ 新手常常在“编译通过”和“程序正确”之间混淆。课程中如果看到程序能编译，就以为代码没问题，这不对。要在不同边界情况下测试，比如狂点鼠标、快速按多个按键、窗口反复拖拽大小，看程序是否还能稳定运行。

10. 最佳实践与学习建议

10.1 先小步验证，再扩展功能

第一次跟课程时，建议每看到一个可运行的小节点就停一下，自己动手把代码重新写一遍，再继续看下一个视频。如果跟到第 3 章才发现前面基础没打牢，回看成本比中途暂停高得多。

10.2 维护“最小可运行配置”

课程进行到中后期，你会加很多文件。这时保留一份“最小可运行版本”很实用：一个main.cpp，一个窗口，一个会移动的方块。后续功能出问题，回退到最小配置逐步添加，就能较快定位问题。

10.3 素材和源码分目录管理

把课程代码、自己写的外部测试代码、最终作品分开。目录清晰之后，后面做“批量任务”“自动化测试”或者简历展示都会方便很多。建议每次完成一个里程碑就打个 Git commit，这样改坏代码还能恢复。

10.4 动手调试，不要只抄代码

课程里如果讲师有一行代码写得很快，建议暂停，自己推断这行是做什么的，再和视频对照。学 C++ 的常见误区是“能看懂别人代码，自己一写就废”。游戏项目是很好的训练场，因为出错反馈非常直接：画面不对、操作不对、程序崩溃，马上能感知到。

10.5 合规与发布

课程项目中通常包含讲师提供的素材，直接发布到网上下载要谨慎。如果想作为作品集展示，建议：

• 替换所有美术和音频资源，使用免费可商用素材（如 CC0 协议）。
• 在 README 中说明原创部分和资源来源。
• 如果要发布到 Steam 或应用商店，先确认课程是否允许商业使用，必要时联系讲师或版权方获取书面授权。

11. 总结

这门 Udemy 的 C++ 游戏开发入门课，最大的价值不是教你背语法，而是让你在“做游戏”的完整流程里学会 C++。它的核心路线可以概括为：搭好编译环境 → 跑通窗口循环 → 用类组织游戏对象 → 用碰撞和状态管理让游戏可玩 → 打磨成完整成品。这套流程比单纯刷语法题更能建立工程感。

最值得先验证的点：本地 C++ 编译环境是否正常。如果你能编译并运行一个 SFML/SDL 的窗口 Demo，说明你已经跨过了这门课最基础也最容易卡住的门槛。

最容易踩的坑有三个：一是环境配置阶段 GCC 或运行库缺失；二是不理解资源生命周期，纹理被提前销毁导致黑屏；三是在遍历容器时删除元素，导致迭代器失效闪退。

后续可以继续扩展的方向很多：学完 2D 游戏项目后，可以深入研究更完整的架构模式（如组件系统、实体组件系统）、学习引入物理引擎，或者把 C++ 项目接入 CMake + CI 做自动化构建。从这门课开始，你拿到的不仅是一个游戏，还是一条能继续深入的开发路径。建议收藏备用，准备动手前先把环境准备好。