1. 项目概述与架构选型1.1 这系统到底要解决什么问题先说说我做这个遥感影像共享系统的背景。前段时间单位里攒了一大批历史遥感影像数据从早期的航空影像到近年来的卫星数据零零散散散落在各台机器的硬盘里。每次有人要用数据都要找负责的老同事问某某地区、某某时间段的数据在哪个盘里拷来拷去版本还经常对不上搞得大家都很痛苦。我当时就想能不能做个简单的共享平台把影像资料集中管理起来。用户可以通过网页浏览缩略图、查元数据信息需要的话直接在线下载原始文件。平台不需要做复杂的遥感算法核心就三个功能传上去管理、看得到预览、拿得到下载。明确这一点很重要因为很多人一开始就把这类项目做大了又是切片服务又是处理管线的结果两三个月都交付不了。先把共享需求做扎实后续再考虑扩展。技术选型上我最终定了 Python Vue 这套组合。后端在 Django 和 Flask 之间斟酌了很久最后保留了两套方案作为可选项。前端用 Vue 3 Element Plus地图预览用 OpenLayers开发环境用 PyCharm 全家桶基本可以覆盖从数据库设计到前端调试的全部工作。1.2 Django 还是 Flask我的取舍思路这个系统我明明可以用一套框架做完为什么要同时保留两种后端的可能说实话这取决于项目的实际形态。Django 适合的场景是项目需要快速上线后台管理界面要开箱即用用户体系、权限认证不想从头造轮子。Django Admin 能直接生成数据管理页面配合自带 ORM开发效率确实高。我做第一版原型时用 Django 只花了一周时间就把基础的数据管理、用户登录、文件上传跑通了这效率是 Flask 比不了的。但 Flask 适合的场景是系统后续要嵌入其他平台或者需要高度定制接口行为。Flask 非常轻请求处理逻辑完全由自己掌控对微服务化改造更友好。如果团队后续想把影像处理单独拆成服务Flask 的代码结构更容易拆解。最终我给两者的定位是这样的如果团队主要写 Python、需要快速出成果选 Django 版本如果更在意接口灵活性和模块自治选 Flask 版本。两者在数据库表和前端部分完全可以共用真正不同的只是路由层和 ORM 层。文章里我会把两套实现都写清楚任选其一即可。2. 系统核心模块与数据库设计2.1 功能模块拆解别一上来就写代码任何系统第一步都是想清楚模块边界。遥感影像共享系统我最开始设计的模块图里只有三个大块后来细化成了六个功能区域第一块是影像数据管理。包括影像上传、元数据录入、文件物理存储、元数据修改与删除。这一块是整个系统的地基如果影像入库的时候元数据就录错了后面检索和浏览都会出问题。第二块是检索与浏览。用户按空间范围、时间范围、传感器类型、云量等条件检索影像结果以列表或者地图标注的形式展示要支持缩略图的快速预览。第三块是权限与用户管理。分成管理员、数据上传者、普通浏览者三级角色。管理员能管理所有数据和用户上传者只能管理自己上传的数据浏览者只能看和下载。第四块是下载管理。包括原始文件的下载、下载权限控制、下载记录留痕。有些数据涉密或者有版权要求下载权限必须细分。第五块是地图预览。集成 OpenLayers把影像的空间范围叠加到底图上。用户点某个矢量范围就能看到影像轮廓并弹出元数据卡片。第六块是日志与统计。记录上传、下载、登录等操作后台统计最热门的影像资源和下载量排名。模块拆完了数据库表的设计才有依据。这里说一下老博主们都懂得一个道理编码之前设计好表结构后面能省一半的返工量。2.2 核心数据表设计直接放出可用的 DDL数据表我主要设计了五张核心表其实遥感影像系统的数据库并不需要特别复杂关键是字段要覆盖遥感数据的基本元数据标准。第一张是用户表user字段包括用户名、密码哈希、邮箱、角色、状态、创建时间。密码一定不要存明文用 Django 自带的make_password方式或者 Flask 里用werkzeug.security.generate_password_hash都是成熟方案。第二张是影像表image最重要的元数据字段包括title影像名称sensor_type传感器类型如 Sentinel-2、Landsat-8 或者无人机相机acquisition_date采集时间cloud_cover云量百分比bbox外包矩形坐标用 PostGIS 的geometry类型更好resolution空间分辨率band_count波段数量file_path原始文件存储路径thumbnail_path缩略图路径file_size文件大小uploader_id上传者外键download_count下载次数统计status数据状态待审核、已发布、已下线第三张是标签表tag和第四张是影像标签关联表image_tag因为一张影像可能存在城市水体灾前灾后等多个标签而一个标签也会对应多个影像所以必须做成多对多的关联关系。第五张是下载记录表download_log用来做留痕审计。每次下载都要记录谁在什么时候下载了哪个影像这既是为了安全审计也能用来做下载频次的热度统计。贴一下影像表在两种框架下的建表差异。Django 的模型类写法如下# Django 版本 models.py from django.db import models from django.contrib.auth.models import User class Image(models.Model): title models.CharField(max_length200, verbose_name影像名称) sensor_type models.CharField(max_length100, verbose_name传感器类型) acquisition_date models.DateField(verbose_name采集日期) cloud_cover models.FloatField(default0, verbose_name云量百分比) resolution models.FloatField(verbose_name空间分辨率(米)) band_count models.IntegerField(default1, verbose_name波段数) file_path models.FileField(upload_toimages/, verbose_name原始文件) thumbnail_path models.CharField(max_length300, blankTrue, verbose_name缩略图路径) file_size models.BigIntegerField(default0, verbose_name文件大小) uploader models.ForeignKey(User, on_deletemodels.SET_NULL, nullTrue) download_count models.IntegerField(default0) status models.CharField(max_length20, defaultpublished) created_at models.DateTimeField(auto_now_addTrue) def __str__(self): return self.titleFlask SQLAlchemy 的写法则长这样# Flask 版本 models.py from flask_sqlalchemy import SQLAlchemy from datetime import datetime db SQLAlchemy() class Image(db.Model): __tablename__ image id db.Column(db.Integer, primary_keyTrue) title db.Column(db.String(200), nullableFalse) sensor_type db.Column(db.String(100)) acquisition_date db.Column(db.Date) cloud_cover db.Column(db.Float, default0) resolution db.Column(db.Float) band_count db.Column(db.Integer, default1) file_path db.Column(db.String(300)) thumbnail_path db.Column(db.String(300)) file_size db.Column(db.BigInteger, default0) uploader_id db.Column(db.Integer, db.ForeignKey(user.id)) download_count db.Column(db.Integer, default0) status db.Column(db.String(20), defaultpublished) created_at db.Column(db.DateTime, defaultdatetime.now)空间范围字段我这里单独说一下。如果要做精确的空间查询比如找出与某个多边形相交的所有影像最理想的方案是用 PostGIS 数据库把 bbox 存储成geometry(Polygon, 4326)类型。但如果项目部署环境不允许装 PostGIS退而求其次的做法是直接存四个浮点数min_lon, min_lat, max_lon, max_lat空间查询时用范围重叠的条件判断。大部分共享系统的查询场景其实四个浮点数已经够用了性能也不差。2.3 文件存储策略磁盘目录结构怎么规划这一节看似简单其实坑最多。遥感影像通常都很大一个 GeoTIFF 动辄几百 MB 到几个 GB如果直接用数据库存二进制文件数据库会直接被撑爆。正确做法是文件存磁盘数据库只存路径。我的目录规划是存储根目录下按年份分一层再按月分一层文件名保留原始文件名并追加一段哈希值防止重名。/storage/remote_sensing/ ├── 2023/ │ ├── 01/ │ │ ├── a3f9_sentinel2_20230115_b3.tif │ │ └── ... │ ├── 02/ │ └── ... └── 2024/ ├── ...这样做的好处是第一按时间归档符合影像数据的自然组织习惯查某年某月的数据直接进目录翻就行第二追加哈希值可以避免不同用户上传同名文件互相覆盖。具体实现时我写了一个生成存储路径的工具函数import os import hashlib from datetime import datetime def generate_storage_path(original_filename, upload_timeNone): 生成存储路径根目录/年/月/哈希_原始文件名 upload_time upload_time or datetime.now() year upload_time.strftime(%Y) month upload_time.strftime(%m) hash_suffix hashlib.md5( f{original_filename}{upload_time.timestamp()}.encode() ).hexdigest()[:8] safe_name os.path.basename(original_filename).replace( , _) return os.path.join(storage, year, month, f{hash_suffix}_{safe_name})上传时还需要注意一个问题文件上传服务往往有大小限制。Nginx 默认上传大小是 1MBDjango 和 Flask 也有自己的上传限制必须把这几层的限制都调大。Nginx 的client_max_body_size我直接设成了10g后端代码里也要做相应的分块上传处理。分块上传的好处是大文件传输中途断了不用从头开始而且服务器内存不会被一次性吃满。关于缩略图我强烈建议上传成功后立刻用 Pillow 或者 GDAL 生成一张 JPEG 缩略图存到独立目录。缩略图不仅能大幅加快列表页的加载速度也能减少服务器带宽压力。有个技巧如果影像特别大Pillow 直接打开原图重新采样可能会非常慢这时候可以用 GDAL 的gdal_translate -outsize 512 512 -of JPEG命令行工具来生成效率要高很多。3. 后端 API 实现与技术要点3.1 Django 方案类视图 DRF 的快速落地如果用 Django 版本我的经验是直接用 Django REST FrameworkDRF来做接口层不要手写 JSONResponse。DRF 的序列化器、分页、权限控制都封装得很好能省大量重复劳动。登录认证我推荐用 JWT 方案。Django 项目装djangorestframework-simplejwt配置起来非常快。注册好应用后在settings.py里加入配置REST_FRAMEWORK { DEFAULT_AUTHENTICATION_CLASSES: ( rest_framework_simplejwt.authentication.JWTAuthentication, ), DEFAULT_PERMISSION_CLASSES: ( rest_framework.permissions.IsAuthenticated, ), DEFAULT_PAGINATION_CLASS: ( rest_framework.pagination.PageNumberPagination ), PAGE_SIZE: 20, }影像上传的 API 用 DRF 的ModelViewSet稍加定制就能搞定。代码如下from rest_framework import viewsets, permissions, status from rest_framework.response import Response from .models import Image from .serializers import ImageSerializer from .utils import generate_storage_path, generate_thumbnail class ImageViewSet(viewsets.ModelViewSet): queryset Image.objects.all() serializer_class ImageSerializer permission_classes [permissions.IsAuthenticated] def perform_create(self, serializer): image_file self.request.FILES.get(file) storage_path generate_storage_path(image_file.name) # 实际保存文件并生成缩略图 saved_path self.save_file_to_storage(image_file, storage_path) thumb_path generate_thumbnail(saved_path) serializer.save( uploaderself.request.user, file_pathsaved_path, thumbnail_paththumb_path, file_sizeimage_file.size )这里要强调一下权限控制的小细节。默认情况下普通用户只能看和自己上传相关的数据操作管理员才有删除权限。我在get_queryset里做了过滤同时自定义了一个DjangoModelPermissions子类来控制动作级别的权限。很多新手容易忽略这一点结果普通用户也能调用 DELETE 接口这是线上事故隐患。3.2 Flask 方案蓝图 SQLAlchemy 的轻量组织Flask 版本的实现思路大致相同只是代码更显式。我用蓝图把路由拆分成了auth、image、download三个模块。登录认证仍然用 JWTFlask 下推荐 PyJWT 库加一个装饰器做视图保护from functools import wraps from flask import request, jsonify import jwt def token_required(f): wraps(f) def decorated(*args, **kwargs): token request.headers.get(Authorization, ).replace(Bearer , ) if not token: return jsonify({msg: 缺少认证令牌}), 401 try: payload jwt.decode(token, app.config[SECRET_KEY], algorithms[HS256]) request.user_id payload[user_id] except jwt.ExpiredSignatureError: return jsonify({msg: 令牌已过期}), 401 except jwt.InvalidTokenError: return jsonify({msg: 无效令牌}), 401 return f(*args, **kwargs) return decorated文件上传接口在 Flask 里用request.files.get(file)拿到文件对象配合werkzeug.utils.secure_filename做文件名安全过滤。这里有个坑secure_filename会把中文文件名直接过滤成空的所以我在生成存储路径时使用的是原始文件名加哈希的方式不用secure_filename处理中文。Flask 的下载接口可以用send_file实现加上conditionalTrue参数以支持断点续传这在下载大文件时非常关键。用户下载到一半断网了有了断点续传就不需要从头再来。3.3 检索接口的设计多条件组合查询影像检索是这个系统使用频率最高的接口性能直接决定用户体验。我设计的检索接口支持以下参数keyword模糊匹配影像名称start_date/end_date限定采集时间范围sensor按传感器类型筛选min_resolution/max_resolution分辨率范围bbox空间范围过滤Django 版本用 Q 对象组合查询条件Flask 版本则直接拼接 SQLAlchemy 的filter条件。必须注意的一点是如果查询条件很多不能把全部逻辑堆在一个视图函数里。我建议封装成独立的查询服务类例如ImageQueryService负责把前端传来的参数字典转换成 ORM 查询对象。分页这块我也踩过坑遥感影像列表页每条数据都是几百 KB 的 JSON不前提是要把大字段裁剪掉。序列化器返回时我只回传 id、标题、采集时间、云量、分辨率、缩略图 URL、外包矩形这些字段原始文件的完整路径绝对不往列表接口里放。文件路径属于服务器内部信息前端只需要通过专门的下载接口去拿文件这也是安全防护的基本要求。另外列表接口一定要给缩略图 URL 加上 CDN 或者单独静态文件路径不要让每次请求都动态走 Django/Flask 的视图去读缩略图文件否则并发一高后端响应就崩了。正确做法是缩略图直接放在 Nginx 可以静态服务的目录下URL 直接用/static/thumbs/xxx.jpg的形式。4. Vue 前端实现与地图集成4.1 项目初始化与页面结构规划Vue 3 Vite 是我目前比较推荐的前端组合。相比 Vue 2 WebpackVite 冷启动速度快很多本地调试体验特别好。项目创建可以直接用命令npm create vitelatest remote-sensing-web -- --template vue目录结构上我习惯把路由、状态管理、API 请求单独分层src/ ├── api/ │ ├── auth.js │ ├── image.js │ └── download.js ├── router/ │ └── index.js ├── stores/ │ ├── user.js │ └── image.js ├── views/ │ ├── LoginView.vue │ ├── ImageListView.vue │ ├── ImageUploadView.vue │ └── ImageDetailView.vue └── components/ ├── MapPreview.vue └── ImageCard.vue页面规划上登录页单独做登录后的主框架包含左侧菜单栏、顶部用户信息栏、内容区三个部分。列表页是最核心的上半部是筛选条件栏中间是缩略图网格右下角悬浮一个地图小窗用于显示全选影像的空间分布。4.2 OpenLayers 地图集成坐标体系别搞错遥感影像的空间位置展示必须用到地图组件。OpenLayers 在 Web 端加载矢量数据和栅格瓦片的能力非常成熟比 Leaflet 更适合遥感场景因为它在坐标系投影上更灵活。集成时最容易踩的坑就是坐标系。后端存的坐标一般是 WGS84 经纬度EPSG:4326但 OpenLayers 默认的显示投影是 Web MercatorEPSG:3857如果用 4326 的坐标直接画到地图上要素位置会偏移到海里。正确的做法是在创建图层时设置数据投影让 OpenLayers 自动转换import Feature from ol/Feature; import Point from ol/geom/Point; import { fromLonLat } from ol/proj; // 后端返回的经纬度转换为地图坐标 const mapPoint fromLonLat([longitude, latitude]); const feature new Feature({ geometry: new Point(mapPoint) });对于影像外包矩形的展示后端传过来的是[min_lon, min_lat, max_lon, max_lat]前端构造多边形坐标时要先转成四个角的坐标数组const coords [ fromLonLat([minLon, minLat]), fromLonLat([maxLon, minLat]), fromLonLat([maxLon, maxLat]), fromLonLat([minLon, maxLat]), fromLonLat([minLon, minLat]), ];图层交互方面点击地图上的影像矩形弹出一个 popup显示影像名称、时间、分辨率并提供查看详情按钮跳转到详情页。这个交互体验非常实用用户在地图上选好区域一眼就能看出哪些地方的影像覆盖比较密集。地图底图我用的是一份免费的全球影像底图服务。这里提醒一点如果系统部署在内网环境外部底图服务访问不了要准备 WMTS 服务的离线瓦片方案。很多人前期忽略了网络环境限制上线了才傻眼。4.3 前端鉴权与请求封装前端需要处理 JWT 令牌的存储和自动续期问题。我的做法是登录成功后把access_token和refresh_token都存到 localStorage在 axios 请求拦截器里统一加上Authorization: Bearer access_token头。响应拦截器里判断 401 状态码自动用 refresh_token 去换取新的 access_token。刷新令牌的时机是个细节问题不能等 401 了才刷新因为并发请求可能同时十几个同时触发刷新逻辑会产生大量重复请求。我的解决方法是设置一个isRefreshing标志位第一个触发的请求去刷新其他请求先挂起排队等刷新完成后重新执行原请求。API 请求封装示例import axios from axios; import { useUserStore } from /stores/user; const service axios.create({ baseURL: import.meta.env.VITE_API_BASE_URL, timeout: 30000, }); service.interceptors.request.use((config) { const userStore useUserStore(); if (userStore.accessToken) { config.headers.Authorization Bearer ${userStore.accessToken}; } return config; }); let isRefreshing false; let pendingQueue []; service.interceptors.response.use( (response) response.data, async (error) { const userStore useUserStore(); const originalRequest error.config; if (error.response?.status 401 !originalRequest._retry) { if (isRefreshing) { return new Promise((resolve, reject) { pendingQueue.push({ resolve, reject }); }).then(() service(originalRequest)); } originalRequest._retry true; isRefreshing true; try { const newToken await userStore.refreshToken(); pendingQueue.forEach((item) item.resolve()); pendingQueue []; return service(originalRequest); } catch (refreshError) { pendingQueue.forEach((item) item.reject(refreshError)); pendingQueue []; userStore.logout(); window.location.href /login; } finally { isRefreshing false; } } return Promise.reject(error); } ); export default service;这里顺便提醒一句JWT 虽然方便但安全性完全依赖密钥管理和存储策略。不要把 JWT 密钥硬编码在代码里提交到代码仓库线上环境密钥必须通过环境变量注入定期轮换。4.4 上传页面的高并发优化上传遥感影像的文件体积大请求时间跨度长前端需要注意两个细节。第一上传按钮必须设置 loading 状态和禁止重复提交否则用户等得不耐烦连点几下会产生多个重复文件后端的哈希命名虽然能避免冲突但存储冗余是实打实的。第二给用户展示上传进度条用 axios 的onUploadProgress回调来实现const onUpload async (file) { const formData new FormData(); formData.append(file, file); formData.append(title, form.title); formData.append(sensor_type, form.sensorType); formData.append(acquisition_date, form.acquisitionDate); await uploadImage(formData, (percent) { progress.value percent; }); };大文件上传建议还是做分片尤其在网络质量不稳定的环境里。每片大小设成 5MB 或者 10MB后端提供一个合并接口。但考虑到遥感影像的使用场景大多在专网或者内网网络质量有保障如果前期为了快速上线整文件上传也能接受分片可以作为 v2 版本的优化项。5. 实际操作全流程复现5.1 环境准备PyCharm 配置要点开发环境我是全程用 PyCharm 的。第一版做 Django 项目时我直接用 PyCharm 专业版的 Django 项目模板创建项目好处是工具自动帮你配置好 manage.py 的运行配置、虚拟环境和 Django 控制台开箱即用。具体环境版本我列个表供参考组件推荐版本说明Python3.103.11 更好3.8 以下别碰了Django4.2 LTS长期支持版本稳定性优先Flask2.3配 Flask-SQLAlchemy 3.xVue3.4Composition API 为主Vite5.x构建速度快OpenLayers9.x地图组件PostGIS3.4可选用于空间查询PyCharm2023.3支持 Vue 插件PyCharm 配置时有一个关键操作要确保 Python 解释器指向的是虚拟环境而不是系统的全局 Python。在设置里Project - Python Interpreter选择New VirtualenvPython 版本选 3.10。后期装依赖都通过pip install装到当前虚拟环境里避免污染系统 Python。前后端联调时我会在 PyCharm 里同时打开前端项目和后端项目。前端项目需要在Run Configuration里增加一个 npm dev 运行项然后开启 Vue 开发服务器默认 5173 端口。后端的 API 服务默认跑在 8000 端口。由于前后端端口不同需要在 Vite 的配置里设置代理把/api开头的请求转发到后端 8000 端口规避跨域问题// vite.config.js export default defineConfig({ server: { port: 5173, proxy: { /api: { target: http://localhost:8000, changeOrigin: true, }, }, }, });5.2 数据库初始化与空间数据扩展数据库我推荐直接用 PostgreSQL PostGIS。安装完 PostGIS 扩展后在数据库中执行一句创建扩展的 SQLCREATE EXTENSION IF NOT EXISTS postgis;Django 项目要使用 PostGIS 的 GeometryField需要安装django.contrib.gis并在settings.py里把数据库引擎改成django.contrib.gis.db.backends.postgis。Flask 项目则通过geoalchemy2库支持 Geometry 字段类型。表结构准备好了以后Python 侧只需要正常执行数据库迁移命令。以 Django 为例python manage.py makemigrations python manage.py migrate如果你是第一次用 PostGIS可能还需要手动建一个数据库并设置用户权限。我一般习惯用命令行建库createdb -U postgres remote_sensing_db psql -U postgres -d remote_sensing_db -c CREATE EXTENSION postgis;5.3 核心接口的实测数据与表现系统开发完成后我导入了一批测试数据做压力测试。测试环境是普通的 4 核 8G 的云服务器数据库是 PostgreSQL后端用的 Django。我导入了 1000 条带有 bbox 坐标的影像记录模拟了列表检索接口的并发请求。实测结果单次列表请求的平均响应时间为 120ms 左右其中数据库查询占了 60ms序列化占了 40ms网络传输占了 20ms。在 50 个并发用户的压力测试下接口吞吐量约为每秒 300 个请求CPU 占用率在 70% 左右表现还算可以。如果数据量增长到十万级需要在 bbox 字段上建空间索引并把列表接口从同步查询改成分页游标模式。5.4 Python 后端实现细节补充Django 项目里影像列表查询服务我推荐用select_related优化外键查询避免每个影像都要单独查询一次用户表。处理云量和分辨率的数字范围过滤时要注意前端传参的边界值用gte和lte这类操作符加一到一个闭区间。在返回给前端的数据结构里统一用一个response_wrapper函数处理。这个函数保证每一项响应都包含固定的状态码、消息和数据三部分前端遇到任何异常情况都能统一处理。def success(dataNone, messageok): return {status: success, code: 200, data: data, message: message} def fail(message, code400): return {status: error, code: code, data: None, message: message}5.5 部署上线前要检查的安全项这里整理几个部署前必查清单。第一DEBUG必须设为 False。Django 的 DEBUGTrue 一旦打开如果页面报错就会显示完整堆栈、服务器配置甚至数据库密码线上绝对不能这么干。第二允许访问的主机列表要在INSTALLED_APPS里配置白名单规则生产环境设置成*会有 DNS 重绑定风险。第三禁止在日志里打印查询语句中包含的敏感信息。Django ORM 的 query 日志在低版本中可能会把用户传入的参数带出来需要做脱敏处理。第四批量下载接口必须限制单次导出量。我封装了一个后台异步任务用户提交下载任务后去队列里排队最大单次任务不超过 500 张影像防止下载请求直接把服务器 IO 打满。6. 常见问题与排查技巧实录6.1 上传大文件时 502 报错遇到最多的问题是上传几百 MB 的影像文件时请求执行到一半 Nginx 返回 502。排查发现是 Nginx 的代理超时时间太短请求超过 60 秒就主动掐断了。解决方法是调大 Nginx 的超时配置client_max_body_size 10g; proxy_read_timeout 600s; proxy_send_timeout 600s; proxy_connect_timeout 60s;但这里要补充一个设计问题仅仅调大超时是不够的。如果影像文件有好几个 GB上传请求长时间占用一个后端 worker其他请求就会被阻塞。解决办法如前所述上分块上传或者把上传接口独立部署或者采用异步上传任务的方式前端先发出上传请求后端把任务投递到队列worker 后台慢慢接收文件流前端轮询任务状态。6.2 前端地图显示空白或者底图错位多数原因是坐标系匹配问题。底图用了 Web Mercator 瓦片而图层数据是 WGS84 坐标系没有转换。排查步骤是先用浏览器开发者工具看一下网络面板确认瓦片请求 URL 的 tile 坐标是否正常再在浏览器控制台里调用 OpenLayers 的getCoordinateFromPixel接口看鼠标点击位置对应的经纬度是否符合预期最后检查图层配置里的projection属性和数据features的坐标是否是统一状态。另外一个常见问题是底图公司壁瓦片服务有严格的防盗链设置必须设置crossOrigin: anonymous否则在 Canvas 上绘制合成结果时会报跨域异常。若影像存在涉密要求有必要用自建的 COS 或 Git 格式的瓦片服务替代。6.3 缩略图不显示一般有三个原因一是缩略图生成失败检查后端日志能发现 Pillow 或者 GDAL 的异常二是静态文件路径配置问题Django 里STATIC_URL和STATIC_ROOT没对应上三是前端拼接 URL 的时候用了中文命名的文件结果 URL 没有做 encodeURIComponent 编码。我建议缩略图的 URL 统一由后端生成一个相对路径返回前端永远不要去拼路径。后端可以额外附带一个 CDN 前缀的字段便于后期迁移到云存储环境。6.4 登录状态频繁丢失JWT 的生命周期需要精细配置。ACCESS_TOKEN_LIFETIME我设置为 2 小时REFRESH_TOKEN_LIFETIME设置为 7 天。如果有用户在系统中长时间操作前端需要在令牌过期前主动刷新一次而不是等过期后再刷新。实际操作中我用一个定时器在 access token 还剩 10 分钟过期时触发刷新。需要注意定时器的清理问题Vue 组件卸载时必须clearInterval否则切换页面时会积累多个刷新定时器产生冗余请求。6.5 数据库连接数被占满这个问题在并发下载时特别容易出现。Django 和 Flask 的数据库连接池默认配置在低并发下没毛病但每个下载任务如果长时间占用一个数据库连接连接数会很快耗尽。解决办法是把数据库最大连接数调大需考虑服务器的连接资源同时在 ORM 层引入连接回收机制。以 Django 为例可以在配置中设置CONN_MAX_AGE参数控制连接复用的生命周期。对于更重的场景建议把下载记录和文件列表的查询拆到只读从库主库只承担写入操作。6.6 大目录下文件上传变慢的问题这个问题发生在我导入了约一万个文件之后。操作系统对单目录的文件数有限制超过一定数量后目录索引操作会显著变慢。我之前已经采取了按年月分层的存储方案所以单目录文件数不会爆炸。但如果后期文件量极其大建议再深一层按影像获取的地区编码比如瓦片拓扑号或者国标行政区划码继续拆分目录分区策略越早设计越好迁移存储结构是最痛苦的事。7. 项目的后续扩展方向7.1 影像在线处理服务共享系统做完后我强烈建议下一步加入在线处理能力。比如影像裁剪、波段组合、影像格式转换。把这些操作做成后台任务通过消息队列调度。用户可以提交一个处理任务设定参数后任务异步执行执行完成后前端通知用户预览结果并下载。这样系统就从一个单纯的文件网盘升级成了影像工作台。处理能力不需要很强基础的 gdal_translate、gdalwarp 命令就能覆盖大部分需求。7.2 基于时序的影像对比遥感数据非常看重时序性。比如同一地区不同年份的影像做对比就能很直观地展示城市扩张、水体变化等。可以在系统里增加时间轴视图用户选定一个空间范围系统拉取该范围内所有时间的影像按时间顺序排列缩略图点击播放按钮就可以连续播放。实现不复杂只需要在地图组件上做定时切换 ImageLayer 的 source。7.3 对接标准 OGC 服务如果希望系统能够与专业遥感软件互相操作可以暴露 WMS/WMTS 标准接口。GeoServer 是现成的方案也可以直接用 Python 的mapnik或者rasterio库实现简单的 WMS 服务。做这个扩展的好处是用户可以通过 QGIS、ArcGIS 等桌面软件直接加载系统里的影像图层。我个人在实际操作中的体会是遥感影像共享系统的难点不在技术框架本身而在于对数据全生命周期的理解。许多刚入门的开发者花了很多时间折腾各种组件反而忽略了最基础的文件存储管理、元数据规范性和权限控制。做这类系统最重要的原则就是稳住底座再谈功能。先把数据传进来不会丢、查得到、看得了、能安全地下载出去这四条生命线做好了基本上系统就成功了一大半。最后再分享一个经验开发过程中一定要准备一批小尺寸的测试影像几百 KB 到几 MB 就好不要一开始就用 1 个 GB 的卫星影像来调试。小文件能加快开发迭代速度等所有流程跑通了再上真实数据调试体验差别非常大。这个细节看着不起眼实际帮我省了好多时间。