第1章 · Gazebo仿真环境概述与范式演进
第1章 · Gazebo仿真环境概述与范式演进
本章要回答的三个问题：仿真环境到底替代了真实测试中的什么，不能替代什么？Gazebo 为什么从 Player/Stage 时代一路走到今天的 gz-sim，中间的几次断代重构各自在还什么债？"分层抽象 + 显式契约"这套设计哲学，对使用者意味着什么可依赖的承诺？
为什么会有这一章
很多工程师第一次打开 Gazebo，看到的是一个三维视口、几个菜单、一坨 XML。工具的表层面目掩盖了它真正的角色：一个用因果链换真实风险的实验装置。如果你不清楚它替代的是什么、契约边界在哪，很快就会陷入两种情绪——要么迷信仿真结果（上真机翻车），要么彻底弃用（觉得"反正不像真的"）。这两种态度都源于同一件事：没搞清账本结构。
本章先把"仿真凭什么可信"这件事的因果链摆出来（1.1），再回头看二十多年的版本演化——每一次大重构背后都是一类还不清的旧账（1.2），最后提炼出贯穿后续所有章节的设计哲学（1.3）。读完这一章，你再打开 Gazebo 时看到的就不是视口和菜单，而是一条从物理求解到传感器输出的可追溯链路。
读完能解决什么
- 能向团队讲清楚"我们要在仿真里验证什么、不验证什么"，写出一份仿真验收边界说明；
- 面对 Gazebo Classic / Ignition / 新 Gazebo 的版本乱局，能做出有依据的选型决策；
- 能识别出"这个需求 Gazebo 的架构承诺支持"与"这个需求在跟架构对着干"的区别。
各节怎么分工
| 节 | 回答哪个问题 | 关键产出 |
|---|---|---|
| 1.1 仿真环境的核心定义与价值 | 可信的因果结构长什么样 | 三支柱分析框架 + SDF 最小示例 |
| 1.2 发展历程与版本分化 | 断代重构在还什么债 | 版本演化对照与选型决策要点 |
| 1.3 核心哲学与设计原则 | 使用者能依赖什么承诺 | 分层契约图 + 工程判断清单 |
章内概念关系
三条支柱各自展开成后面三章；把它们缝合在一起的进程与时钟机制留在第 2 章。1.3 节的契约思想会在每一章的"对账清单"里反复兑现。
先决条件
读过教程导读即可，本章不需要写代码。1.1 节末尾的 SDF 片段建议亲手保存为世界文件跑一次，但不跑也不影响理解。
往下走到哪
第 2 章钻进一帧仿真的内部：物理、渲染、传感器、用户脚本四个执行流如何在一个仿真时钟下对齐——那是全书最"操作系统味"的一章，也是排障时回报最高的知识投资。
给 2026 年新项目的一页选型速断
本章结论可以压成三行可执行的决策：第一，新立项一律选 gz-sim Harmonic 或更新 LTS，Classic 已于 2025 年 1 月终止维护，再投入的每一行 Classic 配置都是未来的迁移欠款；第二，资料进门先验指纹——教程命令以 gz 开头、插件名为 gz-sim-*-system 才收入书签，Classic 写法的答案宁可弃读，混用两个时代的配置是初学期最贵的时间黑洞；第三，从第一天起只用消息接口与 SDF 这两层契约边界内的能力，不链接任何 Gazebo 内部 API——1.3 节那个重写两个月的反面案例，值得抄进团队规范。存量项目则按 ROS 发行版的支撑周期倒排迁移窗口，用 1.2 节的三行指纹扫描脚本先量化工作量，再决定"整体迁移"还是"新功能新架构、旧世界冻结"。这三行决策之外只补一条总原则：一切选型判断都以 1.1 节的账本框架为尺——版本与架构的选择，本质是选择把未来的账差记在哪一页上。