企业官网建设流程全解析

我花了差不多三周时间，把第二版智能仿真无人机项目从零重写了一遍。标题里写着“Java编程进阶”，其实这个项目就是为这个目标服务的——我用纯Java实现了无人机飞行仿真、多线程调度、PID控制、自动返航这些看起来很“硬核”的东西，但所有代码都是自己能控制的，没有依赖任何仿真框架。第一版项目是去年写的，那时候代码全堆在一个类里，加了风力模型之后直接崩得没法看。2.0版本我把架构整个拆了一遍，换上了更清晰的状态机和数据链路，才终于让这个项目成了一个能持续加功能的底座。

这篇内容适合两类人。第一类是学完Java基础、知道多线程和集合语法但不知道往哪用的同学，你可以通过这个项目把synchronized、BlockingQueue、ScheduledExecutorService、并发集合这些知识点串起来；第二类是工作中偶尔要写模拟器、仿真工具或测试平台的Java工程师，我踩过的坑和架构方案可以直接抄。

我要事先说明一点：这个项目的重点不是“专业级空气动力学仿真”，而是“用Java的进阶特性把仿真逻辑组织得可扩展、可测试、可观察”。如果你追求CFD级别的精度，建议去用专业的流体仿真工具；如果你想找一条Java进阶的实战路线，这篇正好。

1. 项目来龙去脉：为什么第二版坚持用Java写仿真

1.1 第一版项目为什么“写砸了”

第一版无人机仿真，我拍脑袋就开工了。一个Main类，里面放了无人机的所有字段、物理更新逻辑、控制逻辑，甚至打印日志的代码也放在同一个循环里。当时想法很简单：跑起来能出轨迹就行。

结果风力模型一加就出问题。因为所有状态都堆在一起，加一个变量就得改十几个方法，改完后又担心影响别的地方。更要命的是，我把“仿真时间推进”和“UI刷新”放在了同一个线程里，窗口稍微卡顿一下，整个飞机的轨迹就跳变一次。到了后期想调PID参数，每次改完跑几百秒，日志乱成一团，根本分不清哪个环节出了问题。

第一版最后能运行，但几乎无法维护。那会儿我意识到：不是项目难，是我压根没给项目留“生长空间”。

1.2 第二版定下的三条硬性原则

重写之前我先给自己定了三条规矩，后面所有设计都围绕这三条展开：

• 模型与控制器分离。无人机物理模型只管“输入控制指令、根据环境输出下一时刻状态”，控制器只负责“根据目标点计算出控制指令”，两边通过接口交互，谁都不依赖谁。
• 仿真时钟独立推进。物理计算、控制计算、日志记录分别跑在不同线程，所有线程只在固定时间步长上同步，谁也不许阻塞谁。
• 每一步数据都可回放。仿真过程中把每一帧的指令、状态、环境参数全部记录下来，出问题时可以离线复现，不用靠肉眼盯屏幕。

这三条原则看起来朴素，做到之后整个项目立刻变得清爽了。2.0版本的“智能”，其实就体现在：仿真环境能加干扰、无人机会自己返航、出问题能通过日志精准定位到某一帧。

1.3 别人都用Gazebo，为什么我偏要用Java

做无人机仿真，大家第一反应肯定是Gazebo配PX4或者AirSim。我也考虑过，甚至装好过环境。但冷静下来我发现：如果只是为了看一个无人机在模拟世界里飞，那我学的只是“怎么调用别人写好的接口”，而不是“怎么用Java写出一套复杂的调度系统”。

用纯Java自带的好处也很实际：

• 不依赖ROS那套进程通信，单机一个JVM就能跑；
• 所有JUC包里的工具都能直接用上，比如并发队列、定时调度器；
• 调试方便，IDE里直接打断点，不用跨进程看日志。

当然代价也有：Java的GC停顿和一贯的“不够实时”被人诟病。但我们要区分场景——仿真器关心的是“逻辑结果是否可复现”，而不是“物理时间是否精确到毫秒”。只要固定步长做得好，普通PC上跑出稳定的仿真节奏完全没问题。

2. 飞行仿真核心：模型抽象与状态机设计

2.1 先统一坐标系和物理量，避免各写各的

做仿真第一件事，不是写类，而是定“世界规则”。我选了无人机领域常用的NED坐标系（北东地，North-East-Down），简单说就是：北方向是X正轴，东方向是Y正轴，向下是Z正轴。这个坐标系的好处是跟真实飞控里的习惯一致，以后想接硬件不用改坐标换算。

所有物理量必须带单位注释，我用这三个基础量：

• 距离：米（m）
• 时间：秒（s）
• 角度：弧度（rad）

然后把状态定义成一个不可变对象DroneState，字段包括位置、速度、姿态角、角速度、电量。为什么用不可变？因为在多线程环境下，把状态快照发给日志线程、控制线程时，谁都不需要担心别的线程突然改掉自己手里的数据。

public final class DroneState { private final Vector3D position; private final Vector3D velocity; private final Vector3D attitudeRad; // roll, pitch, yaw private final Vector3D angularVelocity; private final double batteryPercent; // 构造函数全参数 + getter // 不提供任何setter }

2.2 用状态机管理飞行阶段，比if-else好用一百倍

无人机不是“一直在飞”这么简单。它有上电、起飞、巡航、悬停、返航、降落、紧急保护等多种阶段，每个阶段允许做的动作都不一样。第一版我用了一堆boolean标志位来记录“是不是在返航”“是不是电量低”，最后逻辑互相打架。

第二版我老老实实引入了状态机。核心枚举：

public enum FlightPhase { POWER_ON, // 上电自检 TAKEOFF, // 垂直起飞 HOVER, // 悬停等待 CRUISE, // 巡航飞行 RTL, // 自动返航 LANDING, // 降落 EMERGENCY // 紧急保护 }

状态机内部维护一张转移表，比如：

• 收到“起飞”指令：POWER_ON -> TAKEOFF
• 到达目标高度：TAKEOFF -> HOVER
• 电量低于阈值：CRUISE -> RTL
• 返航到家且高度足够低：RTL -> LANDING
• 信号丢失或检测到碰撞：任何状态 -> EMERGENCY

这样写的好处是，飞行逻辑变成了一张表格，新增状态和事件时只需要在表里加一行，不用满世界找if-else。状态转移的代码大概是这样的：

public class FlightStateMachine { private FlightPhase currentPhase; public void handleEvent(FlightEvent event) { FlightPhase next = transitionTable[currentPhase.ordinal()][event.ordinal()]; if (next != null) { currentPhase = next; } } }

2.3 飞行动力学模型的简化与实现

讲道理，真实无人机六自由度模型包含螺旋桨空气动力学、陀螺效应、电机响应延时等一大堆东西，一个人短时间写不出来。所以雷达要讲清楚：2.0版本用的是“质点加阻力”模型。

也就是把无人机当成一个质点，受力包括：

• 四个旋翼提供的总升力T
• 重力m * g
• 与速度方向相反的空气阻力-k * v

加速度公式写出来就是：

a = (T * upVector / m) + gVector - (k / m) * v

在数值积分上，我用的是半隐式欧拉法。普通的显式欧拉法是先用当前位置算加速度，再同时更新速度和位置；半隐式欧拉是先更新速度，再用新速度更新位置。别小看这一点差别，后者的稳定性好很多，特别是加了弹簧连杆模型或者PID之后，不容易出现能量发散。

public class DroneModelImpl implements DroneModel { @Override public DroneState update(DroneState state, ControlCommand cmd, Environment env, double dt) { Vector3D thrustVector = cmd.getThrustDir().scale(cmd.getThrottle() * maxThrust); Vector3D accel = thrustVector .add(env.getGravity()) .add(velocity.scale(-dragCoeff / mass)); // 半隐式欧拉：先更速度，再更位置 Vector3D newVelocity = state.getVelocity().add(accel.scale(dt)); Vector3D newPosition = state.getPosition().add(newVelocity.scale(dt)); // 姿态变化和电量消耗略 return new DroneState(newPosition, newVelocity, ...); } }

环境参数也不应该是魔法值散落各处，所以我定义了一个Environment对象，包含重力向量、风场对象、大气密度系数等字段。控制器不关心环境内部怎么算，它只需要把环境对象传给模型层就行。

2.4 为什么固定时间步长这么重要

仿真最容易踩的坑就是“每帧推进多少时间”没定死。第一版我用的是“渲染帧间隔当作仿真步长”，结果帧率一波动，无人机加速度的计算全部失真。

第二版我把仿真步长固定为10ms。也就是说，无论渲染线程快还是慢，物理世界每向前走一次，只推进0.01秒。如果某段时间CPU繁忙，物理线程宁可多等一会，也不能让无人机“跨大步”。这种做法的直接收益有两个：

• 可复现性：同样的初始条件、同样的控制指令，跑一百次结果应该完全一致；
• 数值稳定性：固定小步长能防止积分误差被放大。

倍速回放也依赖这套机制。想跑2x速度，只需让“仿真时钟”每推进2步才触发一次日志输出，或者把调度间隔缩短到5ms并在一次步进里执行两步更新。核心不能变：物理更新永远基于固定步长函数update(dt = 0.01)。

3. 多线程调度与实时数据链路

3.1 仿真中的时钟问题：墙上时钟与仿真时钟

写仿真项目，最容易忽视的就是时间到底以谁为准。

一开始我用System.currentTimeMillis()来驱动循环，循环里执行物理更新。结果会发现，Thread.sleep根本不精确，在Windows上误差可能达到10ms以上，跑几分钟仿真就比真实时间快或慢好几秒。

后来我改用System.nanoTime()来获得高精度时间戳，但真正解决问题的是把时间拆成两个概念：

• 仿真时钟：仿真世界内部的时间，以物理步长的整数倍向前走；
• 墙上时钟：现实世界经过的时间，用来控制仿真速度。

举个具体例子：如果目标是1x速度，仿真时钟每推进10ms，我们希望现实世界也差不多过去10ms。做法是每个循环里算一算“距离上次步进过去了多少真实纳秒”，如果还没到目标间隔，就让出CPU；如果超过了目标间隔，就补偿执行多次步进。

核心调度长这样：

long nextStepTime = System.nanoTime(); long stepIntervalNanos = TimeUnit.MILLISECONDS.toNanos(STEP_DT_MS); while (running) { long now = System.nanoTime(); if (now - nextStepTime >= 0) { physicsTick(); // 固定步长推进 nextStepTime += stepIntervalNanos; } else { Thread.yield(); // 时间没到，让出CPU } }

这种方式相当于一个简单的“自旋补偿调度器”，不会因为sleep精度差而漂移。

3.2 线程模型设计：三个角色各干各的

第二版里，我把整个仿真分成三个独立线程：

每个线程之间用队列解耦，这样任何一个环节卡顿，不会直接拖垮其他线程。控制器想发指令，不需要直接调用物理线程的方法，只需要往BlockingQueue<ControlCommand>里塞一个指令对象即可；物理线程每次步进时取出最新指令来用。

创建这三个线程的方式也很方便，用ScheduledExecutorService更省心。但要注意，scheduleAtFixedRate不会帮你补偿执行时间，所以我在里面还是保留了一个“固定步长检查”的机制，只要每次任务执行前的状态量没跟上仿真时间，就多补几个物理步进。

public class SimulationScheduler { private final ScheduledExecutorService executor = Executors.newScheduledThreadPool(3); public void start() { executor.scheduleAtFixedRate(this::controllerTick, 0, 5, TimeUnit.MILLISECONDS); executor.scheduleAtFixedRate(this::physicsTick, 0, 5, TimeUnit.MILLISECONDS); executor.scheduleAtFixedRate(this::recorderTick, 0, 20, TimeUnit.MILLISECONDS); } }

不要直接用Thread.sleep来循环，因为sleep本身就带有一定的底层误差，而且很难做动态倍速控制。

3.3 线程之间怎么共享数据才算安全

既然是项目进阶，就必须跟“共享可变状态”正面对抗一次。

我的策略是：控制指令用队列传递，物理状态用不可变快照发布。

控制指令是一份“生产者消费者”数据。ControllerThread是生产者，找到当前最新的目标状态后构造一个ControlCommand对象放进队列。PhysicsThread是消费者，每次步进时从队列里取出最新指令。这里存在覆盖旧指令的需求，所以我用LinkedBlockingQueue会保留旧值，实际可以改成每次只保留最新一个指令的AtomicReference<ControlCommand>，这样控制器发慢了不会堆积过期指令，物理线程又总能读到最新值。

public class CommandGate { private final AtomicReference<ControlCommand> latest = new AtomicReference<>(); public void publish(ControlCommand cmd) { latest.set(cmd); } public ControlCommand consume() { ControlCommand cmd = latest.get(); return cmd == null ? ControlCommand.zero() : cmd; } }

物理状态这块，因为物理线程每10ms就会更新一次位置、速度、姿态，日志线程和未来可能的UI线程都需要读到当前值。如果用一个普通的DroneState对象，就会出现“日志线程读到一半，物理线程把数据改掉”的问题。解决办法是发布新对象：物理线程在每次更新后创建一个新的DroneState对象，把它写入AtomicReference<DroneState>。读线程拿到的引用永远是一个不会再变的快照。

private final AtomicReference<DroneState> latestState = new AtomicReference<>(); void afterPhysicsUpdate(DroneState newState) { latestState.set(newState); }

这种做法的核心收益是：并发安全的代价只是多创建几个对象，对仿真项目来说完全可接受。GC停顿一般也不明显，因为对象都很小。

3.4 数据记录与回放：调试效率翻倍的秘密

第二版的调试为什么顺利，很大程度靠数据链路设计得好。

每个物理步进结束后，我会把一个RecordFrame对象放入日志队列，里面包括：

• 仿真时间戳（精确到第几帧）
• 当前控制指令（油门、期望姿态）
• 当前状态快照（位置、速度、姿态、电量）
• 环境数据（当时的风力向量）

DataRecorderThread每50ms批量把队列里的帧写入CSV文件。CSV的列设计成固定顺序，方便用Excel或者Python做后处理。

frame,time_ms,pos_x,pos_y,pos_z,vel_x,vel_y,vel_z,battery,wind_x,wind_y,wind_z,throttle,phase 1000,10000,1.02,0.33,10.00,0.01,0.02,-0.05,98.2,0.5,0.1,0.0,0.65,HOVER

有了这个CSV，所有“感觉哪里不对”的问题都能变成“查一下第几帧的数据”。比如返航时无人机绕圈，把位置列画出来立刻就能发现是风场补偿方向写反了；比如电量掉太快，就对比风场和油门的关系。没有这层数据回放能力，我敢说后面加自动返航算法时会反复崩溃而不知道根因。

4. 2.0的亮点升级：风场模型与自动返航

4.1 风场模型：让仿真不再“太干净”

第一版仿真世界非常“纯净”：没有风、没有传感器噪声，无人机永远直线到达目标点。这种世界对控制系统唯一的意义就是“证明你调参调好了”。

2.0我决定加入风场干扰。刚开始我用了简单的正弦风，效果是这样的：

wind_x = baseWind * Math.sin(0.5 * time)

跑了半小时后我发现不够刺激——正弦风太规律了，控制器很容易学出“节奏感”，提前在半周期处开始补偿。我换成叠加多频段的正弦波和随机扰动，勉强算一个能用的湍流风场实现：

public class TurbulentWindField { public Vector3D getWindAt(Vector3D position, double time) { double x = 2.0 * Math.sin(0.3 * time) + 0.8 * Math.sin(1.1 * time + 0.7) + 0.3 * noise(time); double y = 1.5 * Math.cos(0.4 * time) + 0.6 * Math.sin(0.9 * time + 1.3) + 0.2 * noise(time * 1.7); double z = 0.2 * Math.sin(0.7 * time + 2.1); return new Vector3D(x, y, z); } }

真正的Perlin噪声风场我也尝试过，但纯Java实现Perlin噪声需要额外写几百行，而且对无人机这种局部区域来说，多频段正弦叠加的效果已经足够考验控制器。所以我建议从“多频段正弦 + 随机扰动”起步，跑熟了再考虑平滑噪声。

4.2 自动返航（RTL）设计：不是简单地飞回原点

自动返航是2.0版本最核心的“智能”功能。真实无人机返航时不会直接从上一点斜飞回Home点，如果高度不够高，途中可能撞树、撞楼。

我选的返航策略分三段：

1. 爬升阶段：从当前高度爬升到安全返航高度（比如30米），此阶段水平位置基本不动；
2. 返航巡航阶段：保持返航高度，水平直线飞向Home点；
3. 降落阶段：到达Home点上方后，垂直下降到地面，并结合地面高度数据做软着陆。

控制器只需要关心“这阶段的目标点在哪”，剩下的交给底层的PID控制器。

public class RtlPlanner { public TargetPoint plan(DroneState state, HomePoint home, double safeAltitude) { if (state.getPosition().getZ() < safeAltitude - 0.5) { // 先爬升 return new TargetPoint(state.getPosition().getX(), state.getPosition().getY(), safeAltitude); } Vector3D delta = home.position().sub(state.getPosition()); if (delta.getZ() > 1.0) { // 水平到了，但高度还没到，继续下降 return new TargetPoint(home.x(), home.y(), 0.0); } // 正常返航巡航 return new TargetPoint(home.x(), home.y(), safeAltitude); } }

返航时最容易出bug的是“水平位置已经到家但高度还没降下来”的过渡阶段。处理原则就一条：先定水平，再定垂直，不要把两个方向的需求揉在一起。我第一版就是这里写反了，导致无人机绕着Home点画圈。

返航过程中还要做碰撞检测。2.0版本我用的是简化办法：只检查地面高度模型，用一张高分辨率的高度表来查当前位置的地面海拔，低于地表高度就触发紧急触底逻辑。真实世界的障碍物避让属于更高阶的话题，以后可以交给3D栅格地图。

4.3 失效保护：电量阈值与信号丢失

一台合格的智能无人机，必须在“自己还能控制局面”的时候接管控制权。

我实现了两个失效保护事件：

• 低电量：电量低于15%时，不论当前在哪个阶段，强制切换到RTL。如果电量低于5%，直接进入LANDING，不再返航，优先保住飞机。
• 信号丢失：设定一个“最近一次收到地面指令”的时间戳。如果超过2秒没有收到新指令，进入悬停状态；如果超过5秒，触发EMERGENCY并尝试缓慢下降。

这两类事件都通过状态机的“事件”入口进入，避免在控制器代码里到处写判断。具体实现是在handleEvent时注入事件类型：

if (state.getBatteryPercent() < 15) { stateMachine.handleEvent(FlightEvent.LOW_BATTERY); } else if (lastCommandAgoMs > 5000) { stateMachine.handleEvent(FlightEvent.SIGNAL_LOST); }

4.4 自动驾驶PID控制器：位置外环、速度内环

控制器我是用经典的串级PID来实现的。外层位置环输入“目标点”，输出期望速度；内层速度环输入“期望速度”，输出油门倾斜角度。

为什么不是一次PID直接输入目标点输出油门？因为无人机是一个惯性系统，位置与推力之间的关系隔着加速度和速度两层积分。串级PID能更快响应速度变化，而且更容易调整。

我来简化描述位置外环的逻辑：

期望速度 = (目标位置 - 当前位置) * Kp_pos + 期望速度前馈 * Kff

速度内环再把期望速度转换成姿态角：

期望横滚角 = (期望速度X - 当前速度X) * Kp_vel 期望俯仰角 = (期望速度Y - 当前速度Y) * Kp_vel

调参经验是：先调内环，再调外环。如果内环没调稳就去动外环，结果往往是无人机疯了一样振荡。我第一版就是不听劝，上来把位置环增益拉满，仿真里直接看到飞机螺旋上升。

5. 踩坑实录：从1.0到2.0排过的雷

5.1 并发原语选错：共享锁把仿真卡成了幻灯片

第一版里我把所有状态变量都放在一个对象里，然后用synchronized锁住整个更新方法。结果日志线程一读，物理线程就得等；物理线程一更新，控制器线程就卡住。三层线程互相排队，仿真速度从10ms一帧掉到200ms一帧。

后来我换成“不可变快照 + 原子引用发布”的方式。日志线程从头到尾读一个老对象根本不用锁，物理线程每次更新只是发布一个新对象。实测下来，线程之间的互相等待时间降到几乎为零。

这里我的心得是：多线程共享数据，首先要考虑“能不能不共享”，然后才是“怎么用锁保护共享”。

5.2 浮点累积误差导致无人机“越飞越偏”

有一天我跑了一个10分钟续航仿真，发现无人机在悬停模式下位置竟然慢慢漂出去了整整半米。这个表现在单一时间步长内完全看不出来，因为每步误差只有微米级，但累积几百秒之后就很明显了。

原因有两方面：

• double本身存在二进制浮点表示误差；
• 每次使用全局坐标计算位置，绝对坐标数值越来越大，有效精度逐渐流失。

解决办法是引入相对坐标原点概念。物理模型内部记录的不是世界绝对坐标，而是“相对Home点东向、北向的偏移量”。Home点作为double精度比较高的常量保存，而无人机自己的坐标始终保持在零点附近波动，这样一来，计算中的浮点数数量级不会积累到损坏精度的程度。

另一个补充手段是“定期校正”：每1000帧，把当前离线算出的真实坐标和仿真内部坐标做一次差，然后修正偏移。这个像GPS校正一样，把模型内部的漂移锁在地面站认为的合理范围内。

5.3 仿真速度忽快忽慢：调度器必须做补偿

我用ScheduledExecutorService的scheduleAtFixedRate跑一万次后，发现仿真速度不稳定。原因是scheduleAtFixedRate只保证“两次任务开始时间间隔尽量一致”，但任务本身的执行时间会被算进去。如果某一步物理计算耗时超过设定间隔，后面的任务就会全部往后挤，形成漂移。

处理方式在上面已经提过：物理线程里维护一个“nextStepTime”基准，每次执行时先算一算目前“落后”多少步，补齐之后再继续。这样即使偶尔单步计算变慢，后面的循环也会用多步连跳把时间追回来。

我画了个简单的对照实验：

这个差距在平时不致命，但要跑多机协同或者做最终效果演示，偏差累积就是大问题。

5.4 headless环境调试：没有界面怎么调仿真

在公司的云服务器上，没有显示器，没法看无人机飞行动画。最开始我很不适应，后来靠三件事解决了：

• CSV回放：把飞行的完整轨迹画出来，用Python脚本快速绘图；
• 关键帧日志：在状态机切换、PID输出超限、RTL触发的时刻打印一行带时间戳的日志，而不是每帧都打印；
• 断言守护：在代码里加入调试断言，比如“位置必须在500米范围内”“电量不能为负”，一旦不满足立刻输出完整上下文。

其中关键帧日志帮我抓住了很多问题。比如自动返航时，我打印了切换瞬间的状态，立刻发现是高度判断写反了，2分钟就修好，不用一遍遍对着屏幕看动画。

6. 后续可玩的方向：从仿真走向硬件在环

6.1 把控制接口抽象成消息协议，换掉队列就能连真机

2.0版本里，控制指令的传递是直接通过CommandGate这个类完成的。如果想从仿真走向硬件在环，只需要把CommandGate的桩代码换成真实通信链路即可。

我建议定义一个消息协议：

public class ControlMsg { private final double throttle; private final double rollCmd; private final double pitchCmd; private final double yawRateCmd; }

仿真环境里，CommandGate直接内部传递；接真实飞控时，用UDP Socket发送同样的字段。接收遥测也一样，定义一个TelemetryMsg，仿真里从DroneState构造，真实环境里从飞控的MAVLink包解码。这种“协议与传输解耦”的设计，让项目从纯仿真平滑过渡到半实物仿真。

6.2 值得继续扩展的三个方向

做完2.0版本后我梳理了一下，可玩的方向非常多：

• 强化学习环境：把模型层暴露成OpenAI Gym风格的环境接口，让智能体通过“观察、动作、奖励”跟仿真交互，既然状态机和数据链路都是现成的，接入并不难。
• 多机编队仿真：在模型层上面加一个编队协调器，用并发集合维护多架无人机的状态，然后做避撞逻辑。这个方向很锻炼分布式思维，也非常考验并发设计。
• 3D可视化：配合JavaFX或LWJGL写一个简易3D渲染器，把最新状态快照渲染出来。可视化和仿真线程依然可以通过“不可变快照”解耦。

6.3 给想练Java进阶的人一点实在建议

如果你也想用类似项目练手，我不建议上来就做无人机。可以先从“多线程任务调度器”开始，再到“简易股票行情模拟器”，最后再做这种物理仿真项目。因为无人机的物理模型、控制器、并发调度、状态机、数据链路，每一块单独拿出来都够你折腾好几天，组合在一起需要足够的耐心。

最重要的检验方式是：找一个具体场景，不断往里面加干扰。比如加入风场后看控制器是否还能把位置误差控制在半米内；加入传感器噪声后看返航是否还能精准降落。每加一层干扰，你都能发现自己设计里的薄弱环节，这比单纯抄一个完整项目有用得多。

做仿真和写业务系统的最大区别就是：业务系统出bug经常是匿名的，仿真项目出bug是肉眼可见的——无人机飞歪了，螺旋桨掉了，电池耗光了，你一眼就能看到设计缺陷在哪。这个即时反馈，恰恰是练习Java进阶能力最好的老师。