STM32F401双串口OLED调试面板：USB CDC与USART数据链实战
2026/9/8 10:30:41
简介：raylib 压缩包是一套开箱即用的完整开发包，面向需要快速上手或直接移植 raylib 的 C/C++ 游戏开发者和图形编程学习者，省去自行下载依赖、配置编译环境的繁琐步骤。包内共 1079 个文件，约 75.97MB，包含 218 个 C 源码、77 个头文件、146 个 Visual Studio 工程文件及 22 个 CMake 构建脚本，覆盖 raylib 核心库、示例工程与跨平台构建配置；另有 233 个 PNG 纹理、字体、音频与模型素材，以及 118 个 GLSL/FS 着色器文件，可满足学习与原型验证需求。开发包还附带 Makefile、批处理脚本和 Android 打包配置，配合预编译的静态库，可在 Windows、Linux、Web 与安卓平台快速生成程序。目录结构清晰，构建说明与许可证齐全，解压后可直接引用或二次开发。目前已有 381 人学习下载，适合希望绕过环境配置、专注代码逻辑与游戏效果实现的开发者。
1. raylib是什么，为什么它值得你花半小时试一下
先直接说结论：raylib是一个面向C语言（也支持C++、Rust、Python等一堆语言）的简单易用图形库，专门用来做游戏原型、图形程序、交互式工具和教学演示。它跟SDL2、SFML、Allegro这类库最大的区别是——它刻意保持"骨感"，整个核心加起来就几个文件，没有复杂的配置流程，没有庞大的依赖树，你下载一个压缩包，解压出来，配好编译器就能画窗口、画三角形、播放声音、处理键盘鼠标输入。对，就是这样直接。
我第一次接触raylib的时候，刚从OpenGL的"手动创建窗口、手动管理上下文、手动绑定VAO/VBO"流程里爬出来，整个人是被恶心坏了的。OpenGL很好很强大，但它的开发体验对新手和原型阶段来说太沉重了：几十行代码才能让一个窗口显示出来，中间任何一个步骤错了都够你查半天。raylib把这个过程压缩到了几行代码，而且不需要你理解渲染管线的底层细节就能跑起来。它就像是一把瑞士军刀——刀身不大，但刀刃够利，日常用的功能都有，且开刃即用。
但真正让我愿意写这篇东西推荐它的，是标题里那句"下载解压后可以直接使用"。这句话看着普通，实际是raylib整个项目哲学的外在体现：它不想让你在环境配置上浪费一秒钟。我见过太多人兴冲冲学图形编程，结果卡在"配置依赖"这一步，连窗口都没看到就放弃了。raylib不一样，它的官方Release页面提供针对Windows、Linux、macOS的预编译开发包，你下载对应系统的压缩包，解压，include目录里有头文件，lib目录里有现成的库文件——理论上你不需要编译任何东西，不需要手搓CMake，不需要跑vcpkg或apt-get，就能开始写第一个程序。
这篇文章就是帮你把"理论上"变成"实际上"。
2. 下载、解压、摆对位置：提前搞懂这三件事，后面才不慌
2.1 去哪儿下载，怎么选版本
raylib的官方下载渠道其实很简单，优先去GitHub的Release页面找。搜索"raylib releases"，你会看到一排版本号，选最新的稳定版就行。下载的时候需要注意，它提供的压缩包是按平台区分命名的，比如Windows版一般是raylib-x.x.x_win64_mingw-w64.zip，Linux版可能是raylib-x.x.x_linux_amd64.tar.gz，macOS则是以.tar.gz结尾的包。
Windows用户这里有个容易踩的坑：官方Windows预编译包默认是用MinGW-w64工具链编译的。如果你的编译器不是MinGW系（比如你用的是MSVC/Visual Studio），直接拿这个包去编译会报一堆链接错误。所以下载之前先想清楚你电脑上装的是什么编译器。如果你还没装编译器，建议直接下载MinGW-w64（或者装个Dev-C++、Code::Blocks这种自带MinGW的IDE），然后用官方那个win64_mingw-w64的包，这是最省心的组合。
Linux和macOS用户相对好一些，因为系统自带的GCC/Clang通常就能用，raylib的Linux包和macOS包也都是按GCC/Clang工具链编译的，直接配合系统编译器使用，基本不会遇到工具链不匹配的问题。另外，你还可以通过包管理器安装raylib，比如apt install libraylib-dev，但这类仓库里的版本一般比较旧，标题既然写的是"下载解压直接使用"，我们就按官方压缩包的路线走。
2.2 解压之后的目录结构，每个文件夹是干嘛的
拿Windows版举例，解压之后你会看到这样一个结构：
raylib-5.0_win64_mingw-w64/ ├── include/ │ ├── raylib.h │ ├── raymath.h │ ├── rlgl.h │ └── ... ├── lib/ │ ├── libraylib.a (静态库) │ ├── libraylib.dll.a (动态库导入库) │ └── raylib.dll (运行时动态库) └── licenseinclude目录是头文件，里面装了raylib的核心API声明、数学库raymath.h（向量、矩阵操作，做游戏开发基本必用）、还有底层渲染接口rlgl.h。你写代码的时候只需要#include "raylib.h"，剩下的头文件通常不会直接用到，但有它们在，扩展开发会方便很多。
lib目录是核心。.a文件是静态库，链接时直接编译进你的可执行文件里，程序可以独立运行；raylib.dll是动态链接库，程序运行的时候必须跟你的exe放在同一个目录，或者放在系统能找到的路径里，否则程序打开会直接报"找不到raylib.dll"。这一点我后面还会重点讲，因为它是新手最常见的问题来源之一。
2.3 把库"注册"给系统：环境变量与库路径的两种玩法
解压之后，你需要让编译器知道"头文件在哪里、库文件在哪里"。方法有两种：
第一种，装到系统全局路径。把include里的文件复制到MinGW的include目录，把lib里的文件复制到MinGW的lib目录。这样做一劳永逸，之后你写任何raylib程序都不用再指定路径，直接gcc main.c -lraylib就能编译。缺点是污染系统目录，而且以后升级raylib版本时容易因为文件残留引发版本冲突，我个人不太推荐新手这么干。
第二种，也是我更推荐的——把raylib压缩包解压到一个固定目录，然后给系统加一个环境变量，或者直接在编译命令里手动指定路径。比如我把raylib解压在D:/libs/raylib，那么编译的时候只需要额外写一句-I D:/libs/raylib/include -L D:/libs/raylib/lib，编译器就能找到头文件和库文件。这样做的好处是项目之间隔离干净，不会互相污染，而且万一你电脑里的MinGW目录混乱了，也不影响raylib的使用。
注意：如果你用的是VS Code + MinGW这套组合，还可以在
c_cpp_properties.json里配置includePath指向raylib的include目录，这样代码自动补全和跳转都能正常工作，写起来舒服很多。
3. 真正跑通一个窗口：从编译命令到可视化结果
3.1 第一个程序：画一个窗口，验证一切
配置好环境之后，写一个最简单的程序来验证是否真的能跑通。新建一个main.c，代码如下：
#include "raylib.h" int main(void) { const int screenWidth = 800; const int screenHeight = 450; InitWindow(screenWidth, screenHeight, "raylib 解压即用测试"); SetTargetFPS(60); while (!WindowShouldClose()) { BeginDrawing(); ClearBackground(RAYWHITE); DrawText("raylib works!", 190, 200, 20, LIGHTGRAY); EndDrawing(); } CloseWindow(); return 0; }这段代码做的事情非常直白：初始化一个800x450的窗口，标题叫"raylib 解压即用测试"；然后用SetTargetFPS(60)把帧率限制在60FPS；进入主循环，每帧清空背景为白色，并在屏幕中间画一行字"raylib works!"；用户点窗口右上角的关闭按钮后，WindowShouldClose()返回true，循环退出，CloseWindow()收尾。
3.2 编译命令的完整分解：每一个参数都是什么意思
在终端（cmd或PowerShell都行）进入main.c所在目录，执行下面的编译命令（以MinGW的GCC为例）：
gcc main.c -o main.exe -I D:/libs/raylib/include -L D:/libs/raylib/lib -lraylib -lopengl32 -lgdi32 -lwinmm如果你把raylib的头文件和库文件复制到了MinGW的系统目录里，命令可以简化成：
gcc main.c -o main.exe -lraylib -lopengl32 -lgdi32 -lwinmm拆开看这条命令里的几个关键参数：
-I指定头文件的搜索路径，让编译器找得到raylib.h。-L指定库文件的搜索路径，让链接器找得到libraylib.a或libraylib.dll.a。-lraylib表示链接raylib库。库文件名在链接器眼里就是libraylib.a，前缀lib和后缀.a都是默认约定，所以只需要写-lraylib。-lopengl32 -lgdi32 -lwinmm是三个Windows系统库。opengl32让raylib能调用OpenGL函数，gdi32负责窗口绘制和图形设备接口，winmm提供多媒体计时和音频相关的底层支持。raylib在Windows上依赖这三个系统库，所以链接时必须带上。这也是新手最容易遗漏的部分——很多人只写了-lraylib，结果报了几十个"undefined reference"错误，全是在这些系统函数上。
编译成功之后，目录下会生成一个main.exe。如果你用的是静态库，直接双击运行就行；如果你用的是动态链接库，记得把raylib.dll复制到exe旁边，或者给系统环境变量PATH里加上raylib的lib目录，不然会提示找不到dll。
3.3 踩坑实录：最常见的问题排查
我在用raylib的过程中，包括带朋友入门时，遇到过不少问题。这里挑几个频率最高的，做成一个速查表：
| 现象 | 原因 | 解决方案 |
|---|---|---|
| 编译器报"raylib.h: No such file or directory" | -I路径写错了，或者根本没写 | 确认include目录的路径是否正确，检查命令里有没有-I |
| 链接时报大量"undefined reference toimp_..." | 链接时没加系统库，或者库的顺序不对 | 在-lraylib后面补上-lopengl32 -lgdi32 -lwinmm，注意顺序 |
| 运行exe时报"找不到raylib.dll" | 程序依赖动态库，但dll不在搜索路径里 | 把dll复制到exe同目录，或把raylib的lib目录加入PATH |
| 编译通过，但运行后弹出英文乱码或异常退出 | 下载了与编译器位数不匹配的库（比如64位编译器配了32位库） | 确认下载的是win64还是win32的包，跟编译器架构保持一致 |
| 在IDE里写代码，raylib函数全是红色波浪线 | IDE不知道头文件在哪里 | 在IDE的include path配置里加上raylib的include目录 |
这里面最隐蔽的是库顺序问题。GCC链接器在解析符号时是从左往右扫描的，它会按顺序处理每个库，如果-lopengl32放在-lraylib前面，链接器先处理opengl32的时候还不知道后面需要哪些符号，处理到raylib的时候再回头找前面的库就已经找不到了。所以标准做法是把用户库放前面，系统库放后面，-lraylib永远在-lopengl32 -lgdi32 -lwinmm之前。
还有个Windows下特有的坑：很多国内用户在终端里运行exe报"找不到dll"后，第一反应是去系统目录里乱拷dll文件。千万别这么干，你根本不知道那个目录里有什么版本的系统库，拷进去一个旧版本可能导致系统里其他软件出问题。正确做法就一条：把你的raylib.dll和exe放在同一个目录，完事。
4. 从"能用"到"好用"：锐化你的raylib工作流
4.1 静态库还是动态库，开发中到底应该选哪个
raylib的Windows压缩包里同时提供了静态库libraylib.a和动态库raylib.dll（外加一个配合动态库使用的导入库libraylib.dll.a）。这两个怎么选，其实取决于你的使用场景。
静态库编译出来的exe是独立的，拿到任何一台Windows电脑上都能直接运行，不需要额外装依赖。缺点是exe体积会大一些（raylib的静态库加进去大概多几百KB），而且以后升级raylib版本时需要重新编译整个程序。
动态库则反过来：exe体积小，但发布程序时必须带着dll一起打包；好处是你可以只替换dll就完成raylib的版本升级，完全不需要重新编译程序。对游戏开发这种经常要迭代的项目来说，动态库的工作流反而更方便。
我的习惯是：开发阶段用动态库，因为改代码编译快、调试方便；正式发布打包时，直接把dll文件丢进exe同一个目录一起发布，这样对用户来说也没有任何心智负担。如果你实在不想管dll的问题，也可以用静态库，一条命令搞定所有事。
4.2 配好一个顺手的构建脚本，把编译命令固化下来
前面提到的那条编译命令其实挺长的，每次手敲一遍非常折磨人。我的建议是，从第一天起就写一个构建脚本，把这条命令固定下来。Windows上最简单的方式是写一个build.bat文件：
@echo off gcc main.c -o main.exe -I D:/libs/raylib/include -L D:/libs/raylib/lib -lraylib -lopengl32 -lgdi32 -lwinmm echo build done.以后每次改完代码，双击build.bat就完事了。这步虽然简单，但真的能极大提升你的开发体验。等你的项目文件多了，一个文件变成两个三个、再加资源文件、再加配置文件，还可以逐步升级成Makefile或者CMake脚本。但那都是后话——至少第一步，先把批处理脚本跑起来。
4.3 能做什么，不能做什么：给raylib一个合理的预期
说完了环境配置，最后聊聊raylib的能力边界。
raylib能做的东西真的不少：2D游戏、3D游戏（内置了简单的模型加载和3D渲染）、数据可视化、交互式教学工具、音乐可视化、小工具软件、教学演示，这些都有人用它做过，而且效果不错。我自己用它写过几个2D小游戏原型，从零到能跑一个带物理碰撞的demo，一个下午就搞定了，在"原型验证"这个环节确实吊打很多重型引擎。
但它也有一些明显不适合的场景。raylib官方定位就是"简单易用、适合学习和原型开发"，它没有成熟的场景编辑器、没有内置物理引擎、没有资源管线的概念、代码规模过万行之后项目组织会比较费劲。你要做一个商业级的3A大作，或者要做一份需要多人协作数月的大型项目，那还是老老实实去用Unity、Unreal、Godot。raylib的定位更像是"一块干净的白板"，让你专注于想法本身，而不是在工具链里挣扎。
如果你之前被OpenGL直接劝退，或者被SDL2的初始化流程绕晕过，我非常建议你花一个下午试试raylib。下载解压，写好第一段代码，看着那个窗口亮起来——那种"我做到了"的即时反馈，是很多图形库给不了你的。我个人是觉得，学习图形编程的第一步不应该是一本六百页的API手册，而应该是屏幕上亮起的一个窗口。raylib恰好就能帮你做到这一点。
本文还有配套的精品资源，点击获取