这个问题从哪里来
客户想“顺便”在做普通航拍的时候出一个正射图，以为只是换个拍照方式的事。等到算重叠率、控点、空三精度的时候，才发现两者的技术栈几乎不交叉。
当时真正难的地方
- 航线与重叠率：正射要求高重叠，普通航拍通常不要求。
- 地面控制点：正射的精度上限由像控点质量决定，而普通航拍几乎不布控。
- 空三：正射要跑空三解算，普通航拍只做抽帧或存档。
- 成果精度：正射有明确的地面分辨率与平面精度指标，普通航拍只看画面是否可用。
| 任务 | 目标 | 最容易忽略的前提 |
|---|---|---|
| 普通航拍 | 看得清 | 拍摄角度和素材完整性 |
| 正射任务 | 可量测 | 重叠率、控点、坐标系 |
正射任务是在生产一个可测的地理产品，普通航拍只是拍一段能看的影像。生产产品就要谈精度、谈坐标系、谈质检。
从 HTML 原型到真接口，走的是先假后真的路
接手一个正射成果模块时，我们没等后端接口，而是走了一条“先假后真”的路径：
HTML 原型 → 页面与交互拆解 → 接口/数据库文档 → Mock 数据 → 真实接口对接 → 问题修复与交互优化
过程中的几个教训很具体：
- 进度体系会改：一开始是简单的阶段，后来改成 0/25/40/60/75/100 六级。如果前端用
progress去推导环节名称，进度一变就要全局返工。正确做法是把环节信息交给出接口的数据表去驱动，前端只展示，不推导。 - 响应格式别默认统一：这个接口返回
status/desc，另一个模块返回code/msg。以实际响应为准，统一用response.status === 0判断 success，别按猜的格式写。 - 初始化时序的坑：Vue
<script setup>里const有暂时性死区，watch用{ immediate: true }时回调立刻执行，如果回调用了后声明的函数就会报Cannot access ... before initialization。依赖函数要声明在 watch 之前，或拆成独立 watch。 - 刷新别破坏交互状态：刷新列表后要保留用户已展开的卡片，用参数区分“首次加载”和“刷新”，而不是无条件重置 UI。
先假后真的意义，是让页面、流程、字段先达成共识，再等后端。但“假”的数据结构必须按接口文档来搭，否则切真的时候又得返工一遍。
可复用经验
- 接正射需求先问三件事：用途、精度、坐标系。
- 把重叠率、GSD、控点密度写进任务书，作为验收依据。
- 普通航拍顺手要正射，要明确这只是“参考影像”能否接受，否则要按正射另算工时。
留给下次
想整理一张“正射 vs 普通航拍”的最小差距清单，和同事一起把报价前的澄清问题固定下来。