TECHNOLOGY
支撑长期运行的技术体系
技术选型服从业务约束,而不是反过来。这一页说明我们在多端、业务平台、设备接入、智能计算与可维护性五个层面上通常怎么选、为什么这样选,以及哪些决定会影响项目三年后的维护成本。
01
多端体验
Flutter / Web / Electron / 小程序,统一交互与状态
多端不是把同一套界面复制到每个平台,而是共享账户、状态与业务规则。移动端与小程序承担日常入口,桌面端承担现场作业与设备协同,Web 管理端承担运营配置。
- Flutter
- React / Vue
- Electron
- 小程序
- 企业办公应用入口
02
业务平台
API 与领域服务、组织权限与流程、消息 / 报表 / 运营
服务端以领域模型为中心划分模块,接口按业务边界组织。组织、角色、权限与流程是多数企业系统的公共底座,我们把它做成可复用的基础能力,而不是每个项目重写一遍。
- NestJS
- REST / WebSocket
- MySQL
- Redis
- 消息队列
- 对象存储
03
设备与实时
RFID / BLE / UWB / 视频采集、实时消息链路
设备接入的难点在协议差异、时钟同步与现场环境。我们做过有源与无源 RFID、BLE IMU 设备、UWB 定位与多路视频采集,统一由一个设备接入层做协议适配、心跳与数据去重。
- RFID(2.4G / UHF)
- BLE / IMU
- UWB
- FFmpeg / PyAV
- WebSocket
04
智能计算
视觉与姿态算法、大模型工作流、规则引擎与结构化报告
算法侧遵循两条原则:结果要能复核,模型要能替换。视觉计算产出关键点与指标并保留原始数据;大模型输出经结构化约束后进入审核流程,模型升级只改配置不动业务代码。
- PyTorch
- ONNXRuntime
- OpenCV / RTMPose
- FastAPI / Pydantic
- 多模型网关
05
长期可维护
模块化架构、数据治理、接口安全、测试回归、部署监控、备份恢复
系统能不能跑三年,取决于架构留了多少余地。我们按模块独立升级的原则组织代码,接口有契约与版本,关键链路有回归测试,部署有监控与备份恢复演练,交付时一并移交文档。
- 模块化架构
- 接口契约与版本
- 回归测试
- 部署监控
- 备份恢复
选型原则
- 先定边界,再选框架。技术栈的价值在于支撑业务边界,边界不清时换框架只是把问题推后。
- 能替换的才叫能力。模型、直播、存储这类外部依赖都用统一适配层隔离,供应商变化时不影响业务代码。
- 数据要能回溯。算法结果与原始数据同时保留,出现争议时可以复现当时的情况。
- 交付即可接手。文档、部署脚本与备份方案随交付一并移交,不制造只能由原作者维护的系统。
相关页面
下一步
如果场景与上面描述接近,可以先发一封邮件说明目标、现有系统与时间预期,我们会给出初步判断与需要补充的信息清单。