sanks的博客

很多系统早期图省事，会把对象存储桶设成 public，前端直接拿 URL 预览图片和视频。开发快，但文件一旦变成「证据」，问题就来了：谁访问过、能不能撤回、链接被转发怎么办？

更稳的做法是：证据桶保持私有，前端每次预览或下载都通过业务 API 换取短期预签名 URL，同时记访问审计。

下文用脱敏后的巡检/应急实践，整理这一访问模型。

设备在线看起来简单：连着就在线，断了就离线。但在无人机、机库、传感器这类平台里，若让浏览器直连 Broker，或靠前端长连接判断在线，安全和一致性都难扛。

更稳妥的做法是：设备经 MQTT 上报心跳，后端消费后写 Redis TTL，前端仍用普通 HTTP 查设备列表里的在线状态。

下文是一套脱敏后的在线设计，不暴露真实 MQTT 账号、Topic 和设备编号。

早期系统常把附件 URL 直接写进业务表。时间一长就会碰到：链路域名变更、临时签名过期、鉴权与审计无法统一。更稳的模型是：库里只存对象键（object key）与元数据，读取时再签发短期访问，并逐步演进成「证据中心」。

巡检场景里，模型打出「框和标签」只是起点；业务要的是 可分派、可抑制、可追溯的告警。与其把视觉服务直接耦合进业务库表，不如做成「检测事件 → 消息总线 → 告警服务」的闭环。

当系统同时有三维前端、实时推送、领域业务、AI 推理时，「一个后端打天下」会很快失控。用 单体仓库 + 多服务边界 是一种折中：代码在一起好协作，运行时仍按职责拆开。下文给一种可参考的分工，不绑定具体产品名。

不少平台会同时存在「业务用户」和「系统管理员」。把两套人马塞进同一个登录域，看起来省事，实际会在权限模型、审计与发布节奏上互相拖累。更稳妥的做法是：业务走企业级 OIDC，管理端走独立身份与 RBAC。

实时系统一忙就想「多开几个副本」。但 Web 推送和设备接入不是同一种扩展模型：Socket.IO 可以靠适配器水平扩展，MQTT 订阅端却常常必须是单活跃消费者。分不清边界，轻则消息重复，重则状态错乱。

巡检分析、报告生成这类任务，既要边生成边展示，又要失败可重试、结果可审计。若把每个流式 token 都写进工作流历史，体积与重放成本都会爆炸。更干净的切法是：工作流管可靠结果，SSE 管实时观感。

AI 对话、告警推送、长任务进度，这类场景常用 SSE。链路一旦变成「浏览器 → Nginx → Gateway → BFF → 业务服务」，任一层默认缓冲都会把「流式」攒成「最后一次性吐出」。下面记一遍怎么把 SSE 真的流起来。

巡检或应急三维控制台里，「飞机在不在动」往往比静态模型更抓人。本文基于一类 Vue + Cesium + 实时通道 的实践，梳理如何把设备遥测稳定画成「活的」飞行实体。厂商协议字段、内网地址等已脱敏，只保留可复用的设计思路。