把一个项目叫做 Apollo-11，并不代表我要去复刻某段特定历史事件。这串编号在我这里代表一种工程气质：大量子系统必须紧密协作，推进、测量、制导、显示一环扣一环，任何一处失配都可能导致整体失控。我需要一个能够反复验证着陆过程、定量评估不同控制策略的仿真平台，于是就有了这个名叫 Apollo-11 的软着陆仿真项目。
这个项目的核心不是做一个好看的动画，而是做一套从零手写的动力学仿真系统。它包含推进模型、姿态控制、制导逻辑、遥测显示和完整的调试工具链。这篇文章里记录的，是我从系统设计、算法选型到落地调试的真实过程，包括踩进去的坑和最终采用的方案。如果你正在写物理仿真、实时控制、交互式飞行程序，或者对“把一个想法从零做成一套闭环系统”这件事好奇，这篇文章应该能给你一些参考。
1. 项目定位与设计取舍
1.1 项目到底是什么
Apollo-11 是一套平面纵剖面上的软着陆仿真系统。所谓“软着陆”，是指飞行器在接近目标点时，垂直速度要收敛到接近零、水平位移要归零、姿态要保持稳定，整个过程内推进剂有剩余。这套系统把飞行器简化成二维平面上的质点，对它施加重力、发动机推力，通过数值积分推演状态变化，再用制导律生成推力指令，最终完成从减速下降到定点悬停的完整过程。
我做过几个不同方向的尝试。最早的版本是直接用现成物理引擎搭场景，几行代码就能让一个方块受重力掉下来，但问题很快就暴露了：物理引擎的积分步长和碰撞处理会把真实的推力和质量变化抹平，燃料消耗、比冲、姿态限制这些关键因素根本没有办法精确建模。如果我想验证一套制导算法在不同初始条件下的表现，就必须自己掌握底层的每一个数学环节。
所以 Apollo-11 的定位不是游戏，而是一个研究工具。它允许我随时改动重力场、推重比、目标点位置、初始速度，然后通过遥测曲线观察每一次仿真之间的细微差异。这种可控性是选它的首要原因。
1.2 解决的痛点是什么
市面上能看到的着陆演示程序非常多，但大多数存在两个问题。第一是物理上不真实：推力是“施加一个向上的力”，燃料是“一个不断减少的数字”，两者之间没有通过比冲和质量流率建立强耦合。第二是过程不可复现：随机扰动、可变的时间步长、不够明确的初值条件，导致同一套算法跑两次结果都不一样，根本无法做对比实验。
Apollo-11 要解决的就是这两点。我把所有状态量都显式建模：飞行器的位置、速度、质量、姿态角、燃料质量，全部放进同一个状态向量。发动机推力由质量流率和比冲决定，质量流率又直接影响燃料质量的减少，燃料减少又反过来影响飞行器的加速度。这样形成的闭环，才是真实推进系统的核心逻辑。
这个模型跑起来之后，我最大的感受是“一切都相互关联”这句话变成了可以亲眼观察的现象。推重比低一点，垂直速度曲线拖到什么时候才开始反转；目标点偏移 50 米，水平制导需要多久能把速度消到零。这些问题的答案不再依赖直觉，而是直接打印在遥测数据里。
1.3 为什么把范围缩小到最终下降段
完整的飞行流程包括入轨、变轨、巡航、下降、悬停、着陆，每一步都有复杂的约束。如果一开始就想要覆盖全流程，系统复杂度和调试难度会成倍增长。我把范围收敛到最终下降段，也就是飞行器从几百米高度开始减速，一直到触地速度满足安全阈值这一阶段。
选择这个范围的逻辑很简单：最终下降段包含了整个任务里最密集的闭环控制环节。你要同时处理垂直速度、水平速度、姿态、推力、燃料五个维度的约束，而且留给你修正错误的时间窗口极短。这一阶段跑通了，制导算法和仿真框架就有了基础能力，将来扩展上面几个阶段只是加模块的问题，不必重构核心。
更实际的一点是，最终下降段的验证指标非常清晰。我可以用“触地时垂直速度小于 0.5 米每秒、水平速度小于 0.2 米每秒、燃料剩余量大于起飞时的 5%”这样的硬指标来判定一次仿真是否成功。有硬指标，自动化测试才能落地，后续才能用回归测试约束每一次修改。
2. 系统架构：模块划分与数据流
2.1 四大核心子系统怎么拆
Apollo-11 在实现上拆成了四个独立模块：动力学模块、制导模块、遥测模块、控制面板模块。它们的职责边界非常明确，运行时不共享内部状态，只通过标准结构体交换数据。
动力学模块负责“世界怎么响应飞行器”。它接收制导模块送来的推力指令（包括推力量级和推力方向角），结合当前飞行器质量与状态向量，计算出下一时刻的加速度、角加速度，并把状态推进到新时刻。这个模块里没有任何决策逻辑，它只服从物理定律。
制导模块负责“飞行器应该怎么办”。它接收当前状态和目标点状态，计算需要的加速度矢量，再把加速度需求转换成发动机推力和姿态指令。制导算法可以随时替换，比如从比例反馈换到多项式轨迹跟踪，只要接口不变，动力学模块完全不需要改。
遥测模块负责“记录下来发生了什么”。它按固定频率采集状态量，写入环形缓冲区和文件，供事后回放分析。控制面板模块负责可视化，把遥测数据渲染成仪表和数字曲线，同时接收操作员的输入，比如手动接管、设置目标点、调整初始条件。
模块拆得开的直接好处是能单独调试。我在做制导算法的时候，动力学模块可以用一组预先记录的数据来驱动，不用每次重新跑仿真。反过来验证动力学正确性时，制导模块可以被固定的推力指令替代，我可以确认单纯物理推演不会出错。这种并行推进的效率，对一个人的项目非常关键。
2.2 模块之间的数据链路
整个系统的运行循环非常固定：控制面板输入目标点和初始状态，初始化动力学状态向量；一个固定频率的控制器向动力学模块请求当前状态；制导模块在收到状态后生成推力指令；动力学模块推进状态并写回遥测缓冲区；遥测模块在每一次采样时把数据包发给控制面板渲染；控制面板刷新画面并继续请求新状态。
在实际编码中，我用了一个统一的仿真时钟。时钟每走一步，整个链路的模块各自执行一次，执行顺序固定为：状态采样、制导计算、推进执行、遥测记录。这样做的原因是保证可复现性——只要时钟步长固定，模块执行顺序固定，初值相同，两次运行的结果就完全一致。项目做到后期，这个“同一套输入必须产生同一套输出”的约束，成了我一直保留的底线。
数据结构上我定义了一个标准的状态结构体，包含横向位置、高度、横向速度、垂直速度、质量、姿态角、角速度、当前推力、当前方向角、时间戳。四个模块之间的沟通对象就是这组结构体，不额外传递隐藏参数。没有隐式耦合，边界才会清晰，遇到问题才能快速定位是哪一层出了问题。
2.3 为什么不用现成物理引擎
很多同类项目会选择直接调物理引擎的 API，用刚体加关节的方式模拟飞行器。对普通演示来说这完全可以，但 Apollo-11 的目标是研究制导与推进耦合关系，现成引擎反而不合适。
第一，物理引擎的时间步长不是完全可控的。大量模拟器为了性能会使用可变的内部步长或者向前插值，这会引入不确定的数值误差。我做的是控制算法研究，每次运行都要能复现结果，这种随机性不可接受。第二，物理引擎对“发动机推力”的建模是离散的冲量脉冲，不是连续的质量流率变化。真实发动机的推力是一个连续过程，随着燃料消耗，质量逐渐减少，加速度逐渐上升。这个耦合关系在物理引擎里很难精确还原。
第三，简单应用往往高估了物理引擎的“正确性”。物理引擎里的重力加速度通常被简化成常数，这对地面上的刚体足够用，但对一个需要跨越几百米高度、受质量变化影响明显的飞行器来说，常数重力模型误差偏大。我要能随时切换到球体重力场，要能自己定义重力随高度变化的函数，这些在自研框架里只是一行代码的事。
所以在 Apollo-11 里，整个动力学方程是我自己写差分解，然后用自己的积分器推演。这样能保证每一步的数学含义都清清楚楚，调起参来也不会有“不知道引擎内部在干什么”的无力感。
3. 核心算法实现：从动力学模型到制导落地
3.1 动力学模型怎么搭
Apollo-11 使用二维纵平面模型，状态向量由六个变量组成：水平位置 x、高度 y、水平速度 vx、垂直速度 vy、飞行器质量 m、推力方向角 theta。其中 theta 表示发动机推力方向与飞行器纵轴之间的夹角，实际控制时通过改变这个角度来产生水平加速度。
飞行器受力分析相对简单，两个力的来源：重力沿 y 轴向下，发动机推力沿 theta 方向分解成水平和垂直两个分量。重力加速度我用了随高度变化的表达式：a_g = mu / (R + y)^2，其中 mu 是中心天体的重力参数，R 是中心天体半径。在地表附近这个表达式退化为近似常数，但把它保留成通用形式之后，我可以随时把场景换成更大或更小的天体，而不用改动力学方程。
推进力的建模是关键点。发动机推力 F 与质量流率 mdot 和有效排气速度 Isp 之间满足 F = mdot * Isp。制导模块的输入是“希望得到的加速度指令”，也就是期望推力大小和方向。动力学模块拿到这个指令后，先算质量流率 mdot = F / Isp，再用 mdot 更新飞行器质量 m_new = m - mdot * dt，然后根据牛顿第二定律算加速度 a = F / m_current。注意这里 m_current 是推进过程中实时变化的质量，不是初始质量，更不是干质量。这一步如果算错，整个燃料预算就会失真。
核心仿真循环的伪代码如下：
# 以固定时间步长 dt 循环 for step in range(steps): x, y, vx, vy, m, theta = state # 重力加速度随高度变化 ag = mu / (R + y) ** 2 # 根据制导指令得到推力大小 F 和方向角 theta F = guidance.compute_thrust(state) theta = guidance.compute_angle(state) # 质量流率 = 推力 / 排气速度 mdot = F / Isp m_next = m - mdot * dt # 加速度 ax_thrust = (F / m_next) * sin(theta) ay_thrust = (F / m_next) * cos(theta) ay_total = ay_thrust - ag # 积分更新（简化写，完整实现用 RK4） vx_next = vx + ax_thrust * dt vy_next = vy + ay_total * dt x_next = x + vx_next * dt y_next = y + vy_next * dt state = (x_next, y_next, vx_next, vy_next, m_next, theta)这里看到的关键细节是：推力加速度的分母用的是一段积分结束后的质量 m_next，这相当于隐式地考虑了推进过程中质量的连续变化。虽然对单步影响很小，但在几十秒的下降过程里累积差别会非常大，尤其是初始推进剂占全重比例高的时候。
3.2 数值积分器选型与对比
仿真精度很大程度取决于积分器怎么选。最简单的显式欧拉法，也就是 x_next = x + v * dt，看起来直观，但长期累积下去误差明显，尤其是在几十秒的下降过程中会有明显的能量漂移。我用一个固定动作做过误差测试：让飞行器从 300 米高度无推力自由下落 30 秒，显式欧拉法的落地高度会出现肉眼可见的偏差，而同样的参数用四阶龙格库塔法，误差几乎可以忽略。
我最终选择的是经典四阶龙格库塔法 RK4。它的原理可以理解成：在每个积分步长内部，取四个不同的斜率采样点，加权平均作为这一整步的导数，然后更新状态。虽然计算量比欧拉法大一些，但换来的是高得多的稳定性和精度。对于飞行器仿真这种动力学微分方程不算刚体的场景，RK4 是精度和计算量的最佳平衡点。
这是两种积分器在同样 120 赫兹、30 秒仿真条件下的对比：
| 积分器 | 位置误差占比 | 能量漂移 | 计算成本 |
|---|---|---|---|
| 显式欧拉 | 2.3% | 明显 | 最低 |
| 四阶龙格库塔 | 0.05% | 极低 | 高约 3 倍 |
仿真时钟频率选择了 120 赫兹。这个频率比我预期的要高，原因是制导模块需要高频修正飞行器轨迹，尤其是着陆段最后几秒，一个控制周期里飞行器高度变换很快，频率太低会让制导指令滞后，导致落地速度超限。实测下来 60 赫兹也能跑，但控制余量明显变小。为了留出充足的安全边际，最终定在 120 赫兹。
3.3 制导算法怎么一步步落地
制导模块是 Apollo-11 里最花心思的部分。它的任务是把“飞到目标点，并让落地时垂直速度小于安全值”这个宏观目标，拆解成每一帧具体的推力指令。
我第一个版本的制导算法是最直接的 PID 反馈：高度越高垂直方向推力越小，横向误差越大横向推力越大。这个方案跑起来确实能落到目标点附近，但有两个问题：垂直方向容易出现震荡，甚至在靠近地面时出现反复推拉；燃料消耗也偏大，触地时经常只剩不到 2% 的燃料，可以说非常惊险。
后来我改成“两阶段控制策略”。第一阶段是减速下降：不管横向误差，先保证垂直速度按计划的速率下降。制导律设定一条期望的垂直速度曲线，这条曲线的高度越高允许的精确速度下滑越大，高度越低垂直速度越接近零。控制算法根据当前高度在这条曲线上查目标速度，再用比例控制去追踪。第二阶段是横向收敛：当飞行器下降到设定高度阈值以下时，制导模块开始把注意力分配到横向速度和横向位置上。
横向控制的核心不是直接对位置做比例反馈，而是对“横向速度”做速率控制。我的做法是计算飞行器到目标点的水平距离，用这个距离除以剩余下降时间，得到期望横向速度，再与当前横向速度做差，输出横向加速度指令。这样收到的效果是横向速度会平滑收敛到零，同时横向位置也会同步收敛到目标点，不会出现直接比例反馈那种“越靠近目标抖动越厉害”的情况。
一个非常关键的细节是推力方向角的限幅。真实飞行器的姿态角不可能瞬间变化，所以制导模块输出的推力方向角必须经过限幅处理，让角度变化率不超过一个每秒上限。比如我设置了每秒最多变化 8 度，这模拟了姿控系统的物理响应。加上这个约束之后，制导指令虽然理论上更“钝”了，但实际飞行轨迹反而更稳定、更贴近真实。
3.4 遥测与显示模块怎么做
遥测模块的价值在调试过程中被发挥得淋漓尽致。系统每 0.5 秒记录一次完整状态，推进剂质量、高度、速度、推力大小、方向角、剩余误差全部写进日志文件。调试时我很少直接看飞行轨迹，而是盯着遥测数据的曲线图，看哪个变量在哪个阶段出现异常跳动。
可视化界面用的是极简风格：左侧是一个数值面板，显示当前高度、垂直速度、水平速度、姿态角、推力百分比、剩余燃料。右侧是一个横向位置加高度曲线，标记目标点位置和实际轨迹。当中有一个垂直速度-高度相位图，这是我最依赖的调试工具之一。相位图能直观显示制导曲线是否被追踪正常，一旦出现偏差，我马上能看到某个高度上垂直速度是否提前收敛或者收敛太晚。
实际编码里，渲染循环和仿真循环完全分离。仿真循环以固定频率更新状态，渲染循环按显示器刷新率绘制。中间用双缓冲结构传递最新遥测数据包。这样做的好处是，即使监控界面因为系统负载卡顿，仿真本身完全不受影响，逻辑和表现之间的边界非常干净。
4. 调试阶段的常见问题与排查实录
4.1 仿真刚开始就出现明显漂移
第一次跑完整仿真时，我遇到一个诡异的现象：飞行器在没有任何推力的情况下，高度在缓慢增加。我知道肯定是重力项出了问题，但检查了一遍公式没有看出问题。最后定位到原因是初始状态里把高度变量和位置变量填反了，飞行的初始高度被写成了几百米，但重力模型里的半径 R 计算时用的却是状态里的高度字段，导致算出来的重力小于真实值。
这个问题的教训非常直接：物理仿真的初始化代码必须单独测试，不能带着错误的初值去调算法。后来我在所有状态量上加了状态合理性校验，启动仿真前检查位置非负、速度有限、质量大于干质量、推力角度在预设范围。只要有一项异常，直接拒绝启动，并在日志里标红。这个前置校验帮我挡掉了后续很多明显由参数错误引起的问题。
还有一个容易被忽略的坑是单位不一致。我一度在某个模块里用千米算高度，在另一个模块里用米算，结果制导模块算出来的目标高度偏大三倍。飞行器先是直奔目标点上方，然后俯冲回来，折腾了大半天我才发现单位没统一。后来我规定所有内部模块一律使用国际单位制，并在通信结构体里加入字段注释，从源头消灭单位混乱。
4.2 落地瞬间燃料所剩无几的问题
第一次完整跑通制导闭环，飞行器确实软着陆了，但触地时的燃料剩余量只有 4%，这让我非常不安。变量留给一点扰动就很可能变成耗尽燃料的情况。研究之后发现原因是垂直速度控制曲线设计得过于保守，全程都在用比较低的下降速度飞行，导致需要靠发动机支撑重力的时间被拉长。
解决办法是从能量角度重新设计垂直速度曲线。着陆过程垂直方向的能量变化等于初始高度对应的重力势能，最终要全部被发动机“吃掉”。如果过早把速度压到很低，虽然安全，但整个下降时间变长、燃料消耗变多。正确做法是让飞行器在较高高度时保持一个有合理边界的下降速度，只在关键高度附近才快速收速度。我把峰值下降速度从原来的 5 米每秒提高到 14 米每秒，触地前的减速距离设定为约 60 米，这个调整直接让剩余燃料从 4% 提升到了 25%。
这个调参过程让我理解了软着陆控制里“时间-燃料-安全”三个指标是互相制约的。追求最短下降时间会牺牲安全性，追求最稳落地会牺牲燃料预算，制导算法要做的是在这三个目标之间找到可接受的平衡点，而不是让任何一个指标极端化。
4.3 落地前姿态抖动与振荡
制导逻辑跑顺之后，我开始观察推力方向角的曲线，发现一个问题：飞行器越接近地面，推力方向角的抖动量越明显。原因其实不复杂，横向误差减小到一定程度之后，比例控制项产生的修正指令就变得很小，但仍然在不停正负切换，于是推力方向角也跟着来回摆动。
这个问题在仿真里看起来只是曲线变毛糙，但实际系统里会让发动机反复偏摆，既损坏机构又浪费燃料。我的处理方案是在制导输出层加入“死区”逻辑，当横向误差小于 0.5 米、横向速度小于 0.1 米每秒时，直接把横向加速度指令置零，把全部推力集中在垂直制导上。再加了一个方向角变化限幅，本来就有的每秒 8 度限制，当检测到方向角指令变化频率过高时，我会进一步平滑输出，做了一阶低通滤波。
把这两项加进去之后，推力方向角曲线变得非常干净。调试阶段的收益也很直观：不再需要靠肉眼反复看抖动曲线猜测问题原因，姿态通道的毛刺几乎完全消失。
4.4 显示画面与仿真不同步
还有一个问题发生在可视化界面上。仿真运行的很快，几十秒钟的任务不到一秒就跑完了，控制面板的刷新跟不上，画面就像是卡住了一样，只能看到最终结果。后来我发现这是因为我没有对仿真频率做减速处理。
解决方法是把仿真时间与真实时间解耦：仿真时钟继续按固定频率推进，但在每次推进后主动休眠一段时间，让渲染线程来得及更新画面。我实现了一个简单的实时比例控制，默认 1:1 回放率，可以改成 4 倍速、0.5 倍速回放。这个功能对调试帮助很大，尤其是做制导算法改动时，慢动作回放能让我精确看到飞行器在哪个位置开始进入横向收敛阶段。
调试时我还有个固定习惯：先看遥测日志，再看曲线，最后才看动画。因为动画画面用来建立直观感受很好，但真正的判断必须基于量化数据。遥测日志里每一个时间步都有完整状态，我能精确知道某个参数在第几秒发生变化、变化幅度是多少。动画只是一个映射层，把数据映射成人眼好理解的形式。
5. 测试校验与参数调优方法
5.1 几个必测的标定用例
制导和动力学模型改完之后，验证是必须做的事。我设计了一组标定用例，每次大改之后都会跑一遍全量回归，确保没有引入新问题。
第一个用例是自由落体。关闭发动机，让飞行器从指定高度坠落，检测垂直速度是否符合能量守恒。这个用例简单但有效，能验证重力模型、积分器、状态更新逻辑是否正确。
第二个用例是稳定悬停。初始状态设定在目标点正上方，垂直速度为零，横向速度为零，制导模块应该输出刚好抵消重力的推力指令。如果输出推力偏大或偏小，说明制导模块的垂直通道标定有问题。
第三个用例是横向平移。设定目标点在当前点正右方 100 米处，制导模块应该同时产生横向加速、反向加速减速、再悬停到目标点上方。这个用例专门验证横向控制逻辑是否会导致超调或欠调。
每个用例跑通之后，我会把结果存成基准文件。后续的算法改动如果导致某个用例的结果与基准偏差超过阈值，脚本就会自动报错提醒，防止在调参时不小心退化某一块能力而不自知。
5.2 离线回放技术怎么帮忙排查问题
调试过程中我养成了一个习惯：每次跑仿真都会把遥测数据完整保存下来，然后在另一套回放工具里重新渲染。回放和在线显示的区别在于，回放工具可以在某一个时间点暂停、放大、查看具体状态值，也可以拖动进度条快速跳跃。
这个功应对那些偶发性的异常特别有用。有一次我观察到飞行器在某个高度区间垂直速度曲线出现了不正常的凹陷，但整个任务又成功完成了，不仔细看根本发现不了。在线跑的时候画面一闪而过，我根本来不及捕捉到问题。改成离线回放之后，我反复暂停观察那个区间，发现是制导曲线查表函数在某个边界点上插值跳变导致的。
离线和在线分离的设计也让测试效率明显提升。我可以在后台批量跑一百组初始条件，把各自的遥测数据全部存下来，然后去研究那些失败案例的回放，而不是让仿真程序在跑的时候我还得守在屏幕前面看。
5.3 参数调整的具体思路记录
Apollo-11 里的可调参数不少：垂直速度曲线的峰值、横向收敛开始的高度阈值、推力方向角限幅、死区范围、PID 增益。这些参数之间互相牵制，改一个往往会影响另外几个表现。我采用的做法是每次只改一个参数，锁定其他参数不变，跑完对比初步曲线和实际曲线之后再决定下一个怎么动。
比如调整垂直速度曲线时，我画了一张表记录不同峰值速度下滑至落地后的燃料剩余和触地速度垂直速度。峰值 8 米每秒、12 米每秒、14 米每秒、16 米每秒各跑一次，然后把结果画成曲线对比。最后定型在 14 米每秒，因为它是“触地速度达标”和“燃料剩余充足”的交点，继续往上提虽然燃料省得更多，但触地前需要非常短的减速距离，对控制器的时间响应要求会超出这套基础算法的能力范围。
另外也做了一个更谨慎的决策：制导模块里暴露出来的控制周期默认值是跟随仿真时钟的 120 赫兹，但我在接口里保留了控制周期缩放因子，方便将来做控制器降频测试。因为真实系统的控制器不一定能和仿真器一样高频运行，会有传感器采样、通信、计算等限制，提前测试降频对算法效果的影响，能在早期就发现控制频率余量不足的问题。
6. 后续扩展与个人体会
Apollo-11 目前还是二维纵平面模型，下一步更自然的扩展方向是升级到三维空间。三维会引入偏航、俯仰、滚转三个姿态通道，控制律从二维的平面转换成三维向量，难度会上一个台阶，但整个框架结构不需要改。制导模块输出的推力和姿态指令接口保持不变，动力学模块升级内部计算即可，遥测模块只需要增加新的状态字段。
另外一个很值得做的方向是把传感器建模加进去。目前仿真用的是全知视角：飞行器直接读取真实状态，没有任何噪声和延迟。真实系统里的传感器有测量误差、更新延迟、丢包概率，如果把这些因素加入模型，制导算法就会面对更接近现实条件的输入，也能提前发现控制器对测量噪声的敏感程度。
我在完成 Apollo-11 之后最大的收获，并不是某个具体的算法或代码，而是对“闭环系统”这个词的亲身体验。每一个模块单独拿出来都算不上多难，难的是让它们组合在一起稳定运转。自由落体测试通过不代表制导模块能正常工作，制导模块能跑出平滑指令不代表在有限燃料约束下能完成软着陆目标。只有把每一个环节都标定到可预期、可重复、可回归的程度，才能拿这个系统去支撑更复杂的研究工作。
如果你也想做一个类似的仿真项目，我的建议是从最简单的情形开始：先用显式欧拉法跑自由落体，再换成 RK4 感受误差差异，然后把 PID 加上去观察它振荡、超调、发散，最后再一点点把约束条件加严。这个过程本身比“直接得到一个能用的系统”更有价值，它让你知道系统的每一个边界在哪里，也知道边界为什么会在那里。
