企业官网建设流程全解析

前阵子帮技术中心搭了一套遥感影像共享系统，用到的是典型的 Python 后端加 Vue 前端的组合，开发环境用 pycharm。标题里同时出现 django 和 flask 是因为方案评审阶段两个框架都做过原型，最终采取了 django 为主、flask 用于影像处理微服务的混合架构。这套系统解决的核心问题很简单：让几十个人不必再把七八个T的 GeoTIFF 拿硬盘互相拷，而是打开网页就能按时间、按区域、按传感器检索影像，在线预览，然后按权限下载。如果你正打算做类似的东西——不管是遥感影像、地图数据还是其他大文件素材管理系统，这篇内容应该能帮你少走不少弯路。

1. 做一个遥感影像共享系统，真正要解决的是什么

1.1 一个真实场景：部门内部的数据分发有多痛

我记得项目启动会上的需求描述特别朴素领导带了三句话：第一句是影像都在移动硬盘和NAS里乱放，第二句是每次找数据都要问一圈谁那边有某某区域的影像，第三句是下载分发全靠网盘人工审核。

这三句话翻译成系统需求就是检索、预审、受控下载。遥感影像和普通文档的共享完全不一样，普通文档几百K，微信传一下就行，但一景哨兵2影像通常几百MB，一景高分影像动辄几个GB。如果连看都没法预览，用户必须把整景下载下来再打开看，带宽、磁盘、时间全是浪费。

所以这个系统的第一性原理是：先让用户"看得见"，再让用户"拿得到"。能不能缩略展示，能不能叠加到地图上，能不能按云量和时间筛掉没用的数据，直接决定这个系统是真好用还是另一个电子网盘。

1.2 技术挑战拆解：大数据、多格式、浏览器门槛

遥感影像领域有几个天然门槛，做系统前必须想清楚：

• 数据格式不友好。主导格式是 GeoTIFF，带空间参考信息，浏览器原生不支持打开，连图片预览都需要后端处理。
• 数据体积没有上限。入库动辄按TB算，上传、存储、IO都是问题。
• 数据间有关联关系。同一区域不同时间、同一时间不同波段、同一景影像的不同分辨率版本，这些关系如果不在系统里建模，用户就只能在文件名里碰运气。
• 空间检索是刚需。用户通常问的是"2024年5月到8月、经纬度118到119度的无云影像"，普通文件管理系统的关键字搜索根本顶不住。

这些门槛决定了技术选型必须解决三件事：空间数据建模、大文件处理、在线可视化。好消息是Python生态里这三块都有相当成熟的方案。

1.3 把"共享"拆成四个核心能力

我一般不给客户讲抽象的功能列表，而是把"共享"拆成四个动词：传进来、找得到、看得见、发出去。

"传进来"是指有可控的入库流程，不是扔到共享文件夹就完，系统要自动提取元数据生成预览。"找得到"是指支持时间范围、空间范围、传感器、云量这些专业维度的组合检索。"看得见"是指不必下载原图就能看到缩略图、看金字塔切片、做简单对比。"发出去"是指可以生成受控的下载链接，链接可以设置有效期，也可以按权限组批量授权。

四个能力对应四个技术模块，后面内容我都按这个主线来写。

2. 选型并不复杂：django、flask、Vue、pycharm各自的位置

2.1 为什么这类系统绕不开Python

遥感数据处理领域Python早就一统天下了，rasterio、GDAL、numpy、geopandas 这些库没有替代品。如果你用Java或Go做后端，遇到影像预处理还得想办法调外部程序，开发效率大打折扣。选Python后端的核心收益是语言层面的统一，入库、元数据抽取、缩略图生成、切片、API输出可以用同一套代码链完成，不用维护两套技术栈。

2.2 django与flask的取舍逻辑

标题同时出现django和flask，对很多人来说是纠结，但我的经验里它们其实分工很清晰：

• django适合做业务系统主体。它内置ORM、Admin后台、认证授权、迁移工具，做这种典型的"元数据管理+用户权限+后台维护"系统，开发效率极高。特别是RBAC权限模型，django自带的用户组和权限机制稍微扩展就能覆盖绝大部分共享场景。
• flask适合做独立的影像处理服务。影像入库时的重处理逻辑、波段运算、裁剪、格式转换，这些任务和Web业务耦合度低，用flask写一个小服务部署在内部，职责单一，想重启就重启，不影响主业务。

我在这个项目里的最终架构是django承载主站和API，flask单独处理切片生成和格式转换，两个服务之间通过HTTP调用。如果你面对的是一套纯内部系统、人少、影像规模不大，也可以直接用flask全包，少一层服务部署成本。选型建议直接看表格：

2.3 Vue负责的界面层和地图可视化

Vue在这个系统里做两件事：一是影像列表、检索表单、权限管理这些常规交互，二是配合前端GIS库做在线预览。

影像预览的交互不能用传统图片组件硬撑。地图级别的查看需要缩放、拖动、图层叠加，这块主流方案是OpenLayers、MapLibre GL或Leaflet，它们和Vue配合都很好。我这次用的是MapLibre，因为矢量切片和栅格切片都支持，且国产影像数据源叠加rgb波段效果不错。

Vue还需要解决"本地预览和地图预览两套逻辑"的问题。检索结果列表用分页表格，具体影像打开后用地图组件，中间通过路由传参和store共享状态。这种结构用Vue搞起来非常自然，换React也行，但Vue的模板和响应式特性在这个场景下代码量更少。

2.4 pycharm的定位：不是必须，但效率提升明显

pycharm在这个项目里主要不是写代码，而是调试。django的runserver、flask的app.run、前端构建好的静态文件服务，都能在pycharm里直接配置成Run Configuration，打断点看变量。特别是Django的ORM查询，pycharm的Database面板可以直接看PostgreSQL表结构和索引，排查关联查询结果非常直观。

有一点我要说明：pycharm社区版完全够用，不需要纠结什么专业版之类的激活问题。社区版支持Python代码补全、调试、版本控制，对django和flask项目足以胜任。

3. 系统怎么搭：从影像文件到浏览器像素的链路

3.1 总体架构：前后端分离，一个API层管所有

前端是Vue3 SPA，打包后的静态文件由Nginx直接托管。后端是django提供一组RESTful API，用django-rest-framework实现，影像入库后产生的缩略图、切片由flask处理服务生成，存到共享存储目录，前端通过固定的URL规则访问。

这里有一个容易掉的坑是静态文件与媒体文件的混淆。Vue打包出的js/css是静态文件，由Nginx直接返回；而影像本身、缩略图、切片这些是媒体文件，必须走独立的存储路径和处理逻辑，不能塞进django的static目录。项目里我把两者分开配置，影像数据放到专门的数据盘，而不是和代码放一起。

3.2 数据存储设计：文件不入库，元数据必须入库

影像文件本身绝不进数据库。我的做法是原文件存储在本地数据盘（有条件就挂对象存储，整个系统逻辑不用改），数据库只记录路径和元数据。缩略图和金字塔切片同理，生成后落盘，API返回URL路径，前端直接访问。

很多人刚开始会疑惑，那我数据库里到底存什么？其实核心是元数据表。GeoTIFF头部自带的空间参考信息、拍摄时间、卫星传感器、经纬度范围、分辨率、云量，这些才是共享系统检索和展示需要的数据。把它们抽取进PostgreSQL，配合PostGIS扩展做空间查询，是系统能否好用的大前提。

3.3 模型设计的关键字段

我设计的核心模型是影像信息表，字段设计直接参考常规遥感元数据标准，这里给出一个精简可用的版本：

from django.contrib.gis.db import models as gis_models from django.db import models class SatelliteImage(models.Model): name = models.CharField(max_length=255, verbose_name="影像名称") sensor = models.CharField(max_length=100, verbose_name="传感器") capture_time = models.DateTimeField(verbose_name="拍摄时间", db_index=True) cloud_cover = models.FloatField(null=True, blank=True, verbose_name="云量百分比") resolution = models.FloatField(verbose_name="分辨率(米)") origin_path = models.CharField(max_length=500, verbose_name="原始文件路径") thumbnail_url = models.CharField(max_length=500, blank=True, verbose_name="缩略图URL") tileset_dir = models.CharField(max_length=500, blank=True, verbose_name="切片目录") extent = gis_models.PolygonField(srid=4326, verbose_name="空间范围", db_index=True) uploader = models.ForeignKey( "auth.User", on_delete=models.SET_NULL, null=True, verbose_name="上传人" ) created_at = models.DateTimeField(auto_now_add=True, verbose_name="入库时间")

注意我用了django.contrib.gis里的PolygonField，这是PostGIS空间字段，配合它才能做真正的空间范围查询和空间索引。如果纯用字符串存坐标范围，查"某个经纬度范围内的影像"就会变成噩梦。

3.4 元数据抽取：用代码读tiff的头信息

影像上传落盘后，后端要做的第一件事是抽出元数据。rasterio是这一环节最顺手的工具：

import rasterio from datetime import datetime def extract_metadata(tiff_path): with rasterio.open(tiff_path) as src: bounds = src.bounds crs = src.crs extent_geom = { "type": "Polygon", "coordinates": [[ [bounds.left, bounds.bottom], [bounds.right, bounds.bottom], [bounds.right, bounds.top], [bounds.left, bounds.top], [bounds.left, bounds.bottom], ]] } data = { "width": src.width, "height": src.height, "crs": str(crs), "resolution": abs(src.res[0]), "bands": [src.indexes], } # 拍摄时间一般从文件名约定或tif标签里取，不同供应商格式不同 return extent_geom, data

这里处理顺序有讲究：先拿到空间范围写进数据库，再生成缩略图，最后才处理切片。因为检索依赖的是空间范围，用户上传完第一秒就能在列表里看到定位框，而切片属于查看细节，可以异步慢慢生成。

4. 核心模块实战：上传、预览、检索、共享、推送

4.1 影像上传与异步入库

上传接口我设计成两步：前端先把文件POST到接口，后端存到临时目录，立刻返回一个任务ID；随后后端异步处理元数据抽取、缩略图生成，最后写入卫星影像表。

why异步？一景影像可能要几GB，同步处理会让用户干等好几分钟，体验太差。这一步用Celery，也可以用更轻量的rq，核心是任务队列和状态记录。

上传接口的Django视图大致是这样一个思路：

class UploadSessionCreate(APIView): def post(self, request): upload_file = request.FILES.get("file") if not upload_file: return Response({"error": "缺少文件"}, status=400) # 校验文件头，确认是tiff，防止伪装文件 header = upload_file.read(8) if header not in (b"II*\x00", b"MM\x00*"): return Response({"error": "不是有效的TIFF文件"}, status=400) # 保存到临时目录，派发异步任务 task_id = enqueue_ingest_task(upload_file) return Response({"task_id": task_id})

注意我绕过了django的FileField，直接手动管理上传文件。原因是FileField默认存MEDIA_ROOT，而实际项目要按日期、传感器分目录散列存储，手动控制路径更灵活。校验文件头那段代码千万别省，影像系统很容易被上传伪装成tiff的恶意文件，检查头部字节是最基础的有效性校验。

4.2 在线预览：缩略图、切片地图、m3u8视频流

在线预览我分成两档：基础档是缩略图，适合列表里快速浏览；进阶档是金字塔切片，适合完整查看大图。

缩略图用rasterio直接缩采样生成：

import rasterio import numpy as np from PIL import Image def make_thumbnail(tiff_path, out_path, target_size=(1024, 1024)): with rasterio.open(tiff_path) as src: # 只读前三个波段，设为RGB预览 data = src.read([1, 2, 3], out_shape=(3, target_size[1], target_size[0])) data = np.transpose(data, (1, 2, 0)) # 做简单归一化，避免纯黑或过曝 data = (data - data.min()) / (data.max() - data.min()) * 255 img = Image.fromarray(data.astype(np.uint8)) img.save(out_path, quality=85)

如果影像文件本身带有金字塔或者包含概览，也可以用二级抽样方式生成，速度更快。

金字塔切片的逻辑则是预先做成标准Web Mercator切片目录。这里可以直接用flask写一个切片生成服务，拆成256x256的png，按z/x/y坐标存放，前端的MapLibre直接加载为栅格图层：

import maplibregl from "maplibre-gl"; const map = new maplibregl.Map({ container: "map", style: { version: 8, sources: { imagery: { type: "raster", tiles: [ `/api/images/${imageId}/tiles/{z}/{x}/{y}.png`, ], tileSize: 256, }, }, layers: [ { id: "imagery-layer", type: "raster", source: "imagery" }, ], }, });

热搜词里反复出现Vue播放m3u8的情况，在影像系统里也有对应场景，有些供应商会把动态变化影像处理成视频流，或者在用户浏览长时序影像时把若干景图像序列转成m3u8视频流播放。实际在前端播放m3u8不需要借助Vue插件，直接用hls.js这个库就能独立处理，Vue只需要在mounted里初始化播放器即可。后面踩坑部分我还会再聊。

4.3 空间检索：时间、区域、传感器组合查询

检索接口是这个系统用得最频繁的接口，我用django的PostGIS能力直接做空间过滤。

实现一个组合检索接口，前端传四个可选参数：开始时间、结束时间、传感器类型、区域bounding box。django这边用queryset链式拼接，重点是空间范围使用了标准bbox过滤：

from django.contrib.gis.geos import Polygon from django.db.models import Q class ImageSearchView(APIView): def get(self, request): qs = SatelliteImage.objects.all() start = request.query_params.get("start") end = request.query_params.get("end") sensor = request.query_params.get("sensor") minx = request.query_params.get("minx") miny = request.query_params.get("miny") maxx = request.query_params.get("maxx") maxy = request.query_params.get("maxy") if start: qs = qs.filter(capture_time__gte=start) if end: qs = qs.filter(capture_time__lte=end) if sensor: qs = qs.filter(sensor=sensor) if minx and miny and maxx and maxy: bbox = Polygon.from_bbox((float(minx), float(miny), float(maxx), float(maxy))) qs = qs.filter(extent__intersects=bbox) # 返回摘要信息，避免把切片等信息量全塞进列表 serializer = ImageListSerializer(qs[:200], many=True) return Response(serializer.data)

注意两点：一是extent字段必须建立GIST索引，PostGIS的intersects查询如果没有空间索引，表数据一多就挂，实测几十万条数据全表扫描会到秒级以上，加索引后降到毫秒级。二是列表接口千万别返回所有字段，切片目录、文件路径这些字段动辄几百字符，会极大拖慢响应，我单独写了一个精简的ListSerializer。

4.4 共享与权限：登录、角色、可过期分享链接

共享系统的"共享"落到代码上就是三件事：谁能看、谁能下、链接多久有效。

登录和角色直接建立在django认证体系上。默认用户没有检索权限，需要管理员在后台分配角色。角色我用简单RBAC模型，分了三个角色：游客、高级用户、管理员。游客只能预览缩略图和水印图，高级用户允许下载原图，管理员负责入库和用户管理。

分享链接是另一个核心功能。管理员或授权用户可以选择一批影像，生成带token和有效期的分享链接：

import secrets from datetime import timedelta from django.utils import timezone from django.db import models class ShareLink(models.Model): token = models.CharField(max_length=64, unique=True) images = models.ManyToManyField(SatelliteImage) created_by = models.ForeignKey("auth.User", on_delete=models.CASCADE) expire_at = models.DateTimeField() max_downloads = models.IntegerField(default=10) @classmethod def create_share(cls, user, image_ids, hours=48, max_downloads=10): expire_at = timezone.now() + timedelta(hours=hours) return cls.objects.create( token=secrets.token_urlsafe(32), created_by=user, expire_at=expire_at, max_downloads=max_downloads, )

下载接口里校验token之后，用StreamingHttpResponse流式返回文件，避免大文件一次性读进内存。这是大文件下载包里最容易忽略的性能问题。

4.5 处理进度的实时推送：django websocket怎么用

热搜词里"django websocket实现后台有数据前端推送"被搜了很多次，可见这是很多人卡住的地方。django原来只支持HTTP，websocket需要通道层，我用的是django-channels。

使用场景很清晰：影像上传后元数据抽取要好几分钟，前端要实时显示进度。做法是建立WebSocket连接，任务处理过程中给那个连接所在的group发送状态消息。

# consumers.py import json from channels.generic.websocket import WebsocketConsumer from asgiref.sync import async_to_sync class TaskConsumer(WebsocketConsumer): def connect(self): self.task_id = self.scope["url_route"]["kwargs"]["task_id"] self.accept() # 加入任务组，后端任务执行时可以定向推送 async_to_sync(self.channel_layer.group_add)(self.task_id, self.channel_name) def receive(self, text_data=None, bytes_data=None): pass def task_progress(self, event): self.send(text_data=json.dumps({ "status": event["status"], "progress": event["progress"], "message": event["message"], }))

视图里推送进度：

from asgiref.sync import async_to_sync from channels.layers import get_channel_layer def push_progress(task_id, status, progress, message=""): channel_layer = get_channel_layer() async_to_sync(channel_layer.group_send)(task_id, { "type": "task_progress", "status": status, "progress": progress, "message": message, })

django-channels配置好ASGI应用和Redis channel layer后，这套逻辑就通了。很多教程讲Channel Layer绕来绕去，实际就是给任务建一个虚拟房间，任务往房间喊话，连接着的浏览器全部能听见。

5. pycharm开发这类系统的实用配置和踩坑记录

5.1 环境配置：虚拟解释器与远程调试

pycharm开发django项目，首先要保证解释器正确。这个项目我建了独立的虚拟环境，所有依赖比如django、djangorestframework、channels、rasterio都装在里面。pycharm里配置Project Interpreter指向虚拟环境的python，django项目的Run Configuration选Django server类型，它会自动读取项目里的配置。

调试关键是断点能不能打进去。django在pycharm里打断点默认就是好用的，但flask微服务需要手动在启动脚本里加app.run(debug=True)。我踩过的一个坑是在pycharm里直接运行flask的Debug模式时，代码改了不会自动reload，需要额外勾选Run with Python Console，原因主要是flask的reloader在多线程下的兼容性，不过这只是我的环境和版本组合下的情况，不一定要照搬。

如果影像存储在远程服务器上，本地开发需要访问远程数据，我建议给pycharm配一个远程解释器而不是把数据全部拉回本地。远程解释器模式下代码在本地编辑，执行在远程，数据访问路径不用改，效率高很多。

5.2 踩坑一：django的static文件死活显示不了

热词里"vscode写img标签在django的static文件中显示不了"是一个反复被问的问题。这类问题的排查链路基本是固定的：

第一步看STATIC_URL配置。默认值是/static/，模板里写的引用路径必须以它开头，我写的是{% static 'images/logo.png' %}。第二步看STATICFILES_DIRS有没有包含模板引用的那个目录。第三步看开发模式下django有没有真正把static目录暴露出去，runserver在DEBUG=True时自动处理，但如果DEBUG=False，开发模式下就不会提供static服务，页面全是404。

这个坑的本质是django在开发模式和生产模式对static的处理完全不一样，不少人直接改了DEBUG=False部署到Nginx，前端CSS全没了却发现后面没有Nginx提供静态文件，于是表现为"显示不了"。解决也很简单：开发时DEBUG保持True，生产时让Nginx接管static，django完全不碰它。

5.3 踩坑二：Vue播放m3u8，免安装但要注意CORS

Vue播放m3u8的需求在热词里出现了多种变体，我在影像视频流的分享模块也用到过。直接用<video>标签加src指向m3u8在Chrome和Firefox上大概率播放不了，因为这些浏览器原生不支持HLS协议。替代方案是引入hls.js：

import Hls from "hls.js"; function playM3u8(videoEl, url) { if (Hls.isSupported()) { const hls = new Hls(); hls.loadSource(url); hls.attachMedia(videoEl); } else if (videoEl.canPlayType("application/vnd.apple.mpegurl")) { videoEl.src = url; // Safari 原生支持 } }

实际部署时最隐蔽的问题是CORS。m3u8文件本身和分片的.ts文件如果不在同一个服务域下，或者服务器没给跨域头，浏览器会拉取失败。解决方法是让Nginx给媒体目录统一加上add_header Access-Control-Allow-Origin *，或者把前端和媒体服务放到同一域下。我后来把所有影像切片和m3u8都放到一个媒体子域名，省了一堆麻烦。

5.4 踩坑三：flask"绑定网页元素"其实是理解偏差

热词里"flask如何绑定到网页元素"这个词一看就知道是前端基础还没理顺的提问。flask是后端框架，不可能直接"绑定"网页上的div或input。实际能做到的交互只有两种：表单提交和Ajax调用。

处理这个问题我推荐直接写一个极简示例给提问的人看：

<button onclick="loadData()">加载数据</button>

async function loadData() { const resp = await fetch("/api/ping"); const data = await resp.json(); document.getElementById("result").innerText = data.message; }

flask对应的视图：

@app.route("/api/ping") def ping(): return {"message": "pong"}

页面能不能显示"pong"，核心在于JS有没有被执行，而不是flask有没有"绑定"那个元素。把这个例子跑通之后再看Vue的v-model和事件绑定，整个数据流就自然了。

6. 部署上线：我在类似项目里验证过的做法

6.1 常规部署组合

最终部署方案是：一台Nginx做入口，转发API请求到Gunicorn起的django进程，也负责Vue打包后的静态页面；flask处理服务独立跑在8100端口，只对内网开放，由django的服务端逻辑调用；PostgreSQL用到了PostGIS扩展，Redis用于channel层和Celery任务队列。

Gunicorn启动那个命令看起来很简单，但这几个参数很关键：

gunicorn config.wsgi:application \ --bind 127.0.0.1:8001 \ --workers 4 \ --timeout 120

workers数量按CPU核数的2到4倍取，timeout设大是因为影像检索某些复杂查询可能超过默认30秒。这里我贴的是常规配置，实际workers数要结合服务器内存调整，如果一台2核4G的机器跑4个worker加上celery，内存容易吃紧，反正部署完盯几天监控再收窄参数。

6.2 大文件下载与并发

下载接口是大文件场景最容易出问题的地方，我的处理是下载接口必须满足三个要求：

• 断点续传。前端用axios下载时可能断掉，后端需要支持Range头，这个用django的响应对Range的支持通常自己处理，我在项目里封装了一个FileResponse加上Last-Modified头，简易支持断点。
• 并发控制。分享链接设置了max_downloads，但并发下载同一文件时也需要限制。我用Redis的Lua脚本做原子计数，超过上限直接返回403。
• 过载保护。下载接口如果无限速，几十个人同时拉数据时Nginx和带宽都会被打满，实际项目里我限了每IP每秒1MB，虽然少了点但保住了核心业务。

6.3 一个简单的验收测试

系统上线前我做了一个简单的承受力验证，拿1000景不同来源的模拟影像入库，记录三个关键指标：

这个测试结果不算极限数据，但作为一套内部共享系统的验收已经够用。如果你要做更大规模的影像库，建议事先在存储和切片上做负载测试，别等到上线后再调。

6.4 可以继续扩展的方向

系统上线后有几个方向值得延伸，都来自我实际看到的需求：

一是遥感影像的在线波段运算。用户有时想看NDVI，不可能把原始影像下载下来再算，前端传参数给flask服务做运算，返回单波段结果叠加在地图上，这个需求用户提的频率很高。

二是元数据自动采集的联动。接入新的卫星数据源时，不需要手工逐景填写元数据，定时任务扫描指定的目录自动抽取入库，用celery的beat机制就能实现。

三是分享链接的审计。记录谁在什么时间下载了哪些影像，配合用户的导入导出审计，这类数据治理需求在遥感影像共享场景里越来越常遇到。

最后分享一个我做这个项目最大的体会：遥感影像共享系统的难点从来不是写接口，而是把遥感数据的专业性和Web系统的通用性缝合到一起。文件存储路径、空间索引、异步任务队列、前端地图交互，这些组件单独拿出来都不算难，但串起来以后每一层都会踩一些不属于自己领域的坑。如果你正在做类似系统，建议先把空间范围和检索这条主链路跑通，再补权限和可视化，不要一上来就铺太多功能。我最初那版demo就是急于做完所有模块，结果上线前大部分时间都耗在调bug上，其实真正决定系统价值的还是"用户能不能快速找到自己想要的影像"这一件事。