Django骑行路线规划与分享平台：从数据模型到地图交互的实战解析

骑行是我坚持了好几年的一件事，一开始也就是周末沿着江边骑一圈，后来自行车换成了公路车，就开始琢磨路线这种事——哪段路适合爬坡、哪条绿道能避开红绿灯、哪里有补给点。一个人骑没问题，但想把这些经验沉淀下来，分享给同城车友，就需要一个能记录、展示、分享路线的系统。“Python_django的骑行路线规划与分享平台设计与实现”这个题目，本质上就是做这样一件事：用Python写后端逻辑，用Django搭Web框架，把骑行路线的规划、保存、展示和社区分享串成一个完整可运行的项目。这篇文章不是课程讲义，也不是纯代码仓库说明，我会把从需求拆解、技术选型、数据库设计到实际代码落地的过程都过一遍，那些踩过的坑、改过的方案也会一并写出来，给正在做类似Django实战项目的朋友当一份参考。

1. 项目整体设计与功能拆解

1.1 用户真正的需求：记路线和晒路线

骑行路线平台听起来就是“放一张地图，画一条线”，但真正动手做需求拆解的时候，你会发现用户完全分成两类。第一类是通勤和周末休闲骑行的车友，他们要的是“现成路线”，打开平台就能看到别人验证过的好路线，比如哪条路车少、哪条路风景好、全程多少公里。第二类是喜欢自己探路的骑友，他们需要的是“记录和规划”：自己在地图上打点画线，看总里程和累计爬升，把满意的路线保存下来，再分享给别人参考。

这两类需求决定了一个平台的核心链路必须同时具备两个能力：一是路线的展示和检索能力，二是路线的创建和保存能力。如果只做一个展示页面，那后台手动录入数据就够了，根本不需要做成多用户平台；如果只做规划工具，那用本地软件反而更方便。真正把这两者打通，才是“分享平台”四个字的价值所在。

我做MVP功能拆分时没有一上来就搞复杂的社交系统，基础版本就围绕五个模块推进：用户注册登录、路线列表与搜索、路线详情与地图展示、路线创建与保存、评论与收藏。把这些模块的内在关系列出来，大概是这样的：

P0是页面能不能跑通的基础，P1是平台有没有社区感的关键。新手容易犯的毛病是一开始就想做“完整版”，评论要做成楼中楼、收藏要做成专辑、搜索要做成全文检索，结果做了两周连核心的路线发布都没跑通。我的经验是先砍到不能再砍，把最小闭环跑出来，再谈迭代。

1.2 为什么用Django而不是Flask或Express

很多人会在技术选型上纠结，觉得Flask更轻、Express更快、Django太重。我的观点很直接：如果你做的是一个“平台”，不是一个小接口演示，Django的综合效率最高。

三个理由。第一，Django自带ORM，可以把路线、用户、评论这些实体直接映射成数据库表，不需要手动拼SQL，Django的QuerySet在后期做筛选和分页也非常顺手。第二，Django内置了完整的用户认证体系，注册、登录、会话、CSRF防护都是现成的，省掉了最容易出安全问题的部分。第三，Django自带Admin后台，开发阶段我直接用它维护测试数据，非常节省时间，后期就算给运营加个审核功能也够用。

有人说Django模板渲染不如前后端分离灵活，但骑行路线分享这种偏内容展示的项目，用Django Template配合Leaflet地图组件，已经能把页面效果做得很流畅。我看到很多人在项目一开始就引入Django REST Framework加Vue前后端分离，这本身没错，但如果是单人开发且要快速迭代，前后端分离会让工作量翻倍。我的建议是：先用Django模板方案跑通核心流程，等真的有APP或小程序需求了，再把后端改造为DRF，数据模型完全不用推翻重来。

2. 技术选型与核心原理

2.1 路线数据怎么存：不要存图片，存轨迹点

这是整个项目最核心的问题。很多同学初次做骑行平台，第一反应是把一张地图截图存到数据库，路线详情页就显示这张图。这个方案唯一的好处是简单，但坏处太多：图片不能缩放、不能点击查看具体坐标、不能动态计算里程和爬升、也做不了路线搜索。正确做法是保存轨迹点数据，也就是一系列经纬度坐标，前端拿到这些坐标再画到地图上。

我推荐的存储格式是GeoJSON，或者干脆用JSON数组。下面这个结构就够用了：

json复制{
  "name": "滨江绿道30km",
  "points": [
    {"lat": 30.1234, "lng": 120.5678, "elevation": 5},
    {"lat": 30.1256, "lng": 120.5701, "elevation": 7}
  ]
}

Django的JSONField可以直接把这个结构存进数据库，既能保留完整轨迹，又可以在后端用Python函数计算总里程、累计爬升、最高海拔这些指标。前端拿到坐标数组，用Leaflet的polyline接口一次性画出来，用户能缩放也能点击查看路线上某一点的位置。

这里还要考虑一个扩展场景：很多骑友的手表或手机App支持导出GPX文件。如果平台以后要支持GPX导入，后端解析GPX其实就是把其中的<trkpt>标签里的lat和lon属性读出来，转成上面的JSON结构。所以基础数据格式定义得越简单，后面扩展越省事。

2.2 路线规划算法：Dijkstra在这里不适用

第一次听到“骑行路线规划”这几个字，很多人的第一反应是：要上最短路径算法，Dijkstra、A*、图搜索什么的。真做了之后你会发现，骑行路线平台的“规划”和导航软件的“路径规划”完全是两回事。

导航软件是在路网图上找路径，需要完整的道路拓扑数据，还要考虑速度、交通信号灯、单行道这些因素。个人项目要自己建一套路网数据，成本高到不现实。更实际的做法是：让用户在地图上手动打点，平台负责计算这条自定义路线的各项指标。

所以这个项目真正用到的算法并不复杂，主要是三个：

第一个是两点间距离，用Haversine公式计算球面距离。直接拿平面坐标算距离，在高纬度地区误差会很大，骑行路线动辄几十公里，不能用估算的方式糊弄。

python复制import math

def haversine(lat1, lng1, lat2, lng2):
    R = 6371.0
    p1 = math.radians(lat1)
    p2 = math.radians(lat2)
    dp = math.radians(lat2 - lat1)
    dl = math.radians(lng2 - lng1)
    a = math.sin(dp / 2) ** 2 + math.cos(p1) * math.cos(p2) * math.sin(dl / 2) ** 2
    return R * 2 * math.atan2(math.sqrt(a), math.sqrt(1 - a))

第二个是总里程，遍历坐标点数组，把相邻两个点的距离累加起来。第三个是累计爬升，只累计海拔变化为正的部分。这个“累计爬升”对骑行体验非常关键，一条路线看着只有30公里，如果爬升有800米，难度直接上一个档次。

计算部分我单独放到utils.py里，不掺进视图函数，方便单元测试和复用。这也是我后来重构时体会最深的一点：把纯函数和Django视图解耦，代码会干净很多。

3. 核心模块落地与实操细节

3.1 环境搭建：虚拟环境、Django版本和App结构

开始写代码之前先把环境理顺。我强烈建议每个项目单独建一个虚拟环境，不要图省事把包全部装进全局Python环境，不然两个项目依赖打架的时候你会非常崩溃。

code复制
mkdir cycling_platform
cd cycling_platform
python -m venv venv
source venv/bin/activate   # Windows用户用 venv\Scripts\activate
pip install django
django-admin startproject cycling_platform .
python manage.py startapp routes

这里顺便说一个很多人问过的问题：Django虚拟环境怎么删除？其实非常简单，虚拟环境就是一个独立目录，不需要了直接删掉venv文件夹就行，Django本身不会往系统其他地方写东西。如果你在命令行敲django-admin还有反应，那是因为全局环境里也装了Django，需要pip uninstall django才能彻底清掉，和当前项目的venv没有关系。

Django版本我建议用4.2 LTS或者更新的5.x稳定版，创建app的命令都是python manage.py startapp。如果你用的是VSCode写代码，记得在左下角选择Python解释器时指向项目里的venv，否则明明pip list里能看到Django，运行起来却提示ModuleNotFoundError，这种问题最容易让人怀疑人生。

项目创建完以后，根目录结构大概是这样的：

code复制
cycling_platform/
├── manage.py
├── cycling_platform/
│   ├── settings.py
│   ├── urls.py
│   └── wsgi.py
└── routes/
    ├── admin.py
    ├── models.py
    ├── urls.py
    ├── views.py
    └── migrations/

routes这个app承担路线相关的所有功能，后续评论、收藏也放里面，因为它们的核心关联对象都是Route。如果项目规模进一步扩大，可以再拆出一个users app和一个interaction app，但MVP阶段放一个app里最顺手。

3.2 数据模型设计：Route是绝对主角

数据模型是整个项目的基石。我在设计阶段画了三个模型：User、Route、Comment。User直接用Django自带的auth.User，不做多余扩展。Route保存路线主体信息，Comment负责评论。

python复制from django.db import models
from django.contrib.auth.models import User

class Route(models.Model):
    author = models.ForeignKey(User, on_delete=models.CASCADE, related_name='routes')
    title = models.CharField('路线名称', max_length=100)
    description = models.TextField('路线描述', blank=True)
    start_point = models.CharField('起点', max_length=200)
    end_point = models.CharField('终点', max_length=200)
    route_json = models.JSONField('轨迹坐标')
    distance_km = models.FloatField('里程(km)', default=0)
    elevation_gain = models.IntegerField('累计爬升(m)', default=0)
    difficulty = models.CharField('难度', max_length=10, choices=(
        ('easy', '休闲'), ('medium', '中等'), ('hard', '困难')
    ), default='easy')
    created_at = models.DateTimeField(auto_now_add=True)
    favorites = models.ManyToManyField(User, blank=True, related_name='favorite_routes')

    def __str__(self):
        return self.title

class Comment(models.Model):
    route = models.ForeignKey(Route, on_delete=models.CASCADE, related_name='comments')
    user = models.ForeignKey(User, on_delete=models.CASCADE)
    content = models.TextField('评论内容')
    created_at = models.DateTimeField(auto_now_add=True)

这里有几个关键设计点。第一，route_json用JSONField保存坐标数组，灵活，不用为每个坐标建一张表。第二，distance_km和elevation_gain不是每次查询时现算，而是在创建路线时就算好存进数据库。列表页不需要读取大JSON字段，直接查这两个数值字段，渲染速度会快很多。第三，起点终点作为普通字符串字段保存，方便列表页直接展示，不需要每次从坐标点里猜。

创建完模型后执行：

code复制
python manage.py makemigrations routes
python manage.py migrate

然后在admin.py里注册模型，开发阶段可以在后台直接录入测试路线：

python复制from django.contrib import admin
from .models import Route, Comment

admin.site.register(Route)
admin.site.register(Comment)

注册后启动python manage.py runserver，访问/admin/就能看到后台入口。我的习惯是先手动造两三条路线数据，把列表页和详情页调通了，再去做用户创建的交互，这样前后端联调时不会抓瞎。

3.3 URL路由配置：根路由和App路由分开

项目根目录的urls.py里，把routes应用的链接挂进来：

python复制from django.contrib import admin
from django.urls import path, include

urlpatterns = [
    path('admin/', admin.site.urls),
    path('', include('routes.urls')),
]

然后在routes/urls.py里定义页面路由：

python复制from django.urls import path
from . import views

urlpatterns = [
    path('', views.route_list, name='route_list'),
    path('route/<int:pk>/', views.route_detail, name='route_detail'),
    path('route/create/', views.route_create, name='route_create'),
]

这样整个项目的URL结构非常清晰：首页是路线列表，详情页展示单条路线和评论，创建页负责新路线的编辑。很多Django新手会在这个环节纠结，为什么有了include还要在子应用里再写一个urls.py。其实这是Django推荐的组织方式，把routes相关的路由收敛在一个文件里，以后加搜索、加筛选、加后台管理入口，都不会把根路由文件堆成一大坨。

3.4 视图函数和表单处理：先写朴素版

视图层我用普通函数视图就够用，不需要一上来就上DRF。列表页就是一个查询加分页：

python复制from django.shortcuts import render
from django.core.paginator import Paginator
from .models import Route

def route_list(request):
    qs = Route.objects.select_related('author').all().order_by('-created_at')
    paginator = Paginator(qs, 10)
    page_number = request.GET.get('page')
    page_obj = paginator.get_page(page_number)
    return render(request, 'routes/list.html', {'page_obj': page_obj})

创建路线的视图要注意数据校验。前端把用户画的轨迹点通过POST表单传到后端时，后端必须先检查数据是否为空、点数是否足够，再计算里程和爬升，最后保存：

python复制import json
from django.shortcuts import render, redirect, get_object_or_404
from django.contrib.auth.decorators import login_required
from .models import Route
from .utils import haversine, calculate_distance, calculate_elevation_gain

@login_required
def route_create(request):
    if request.method == 'POST':
        title = request.POST.get('title')
        points_raw = request.POST.get('points')
        if not points_raw:
            return render(request, 'routes/create.html', {'error': '请先在地图上绘制路线'})
        points = json.loads(points_raw)
        if len(points) < 2:
            return render(request, 'routes/create.html', {'error': '轨迹点太少，请重新绘制路线'})
        distance = calculate_distance(points)
        elevation = calculate_elevation_gain(points)
        route = Route.objects.create(
            author=request.user,
            title=title,
            description=request.POST.get('description', ''),
            start_point=request.POST.get('start_point', ''),
            end_point=request.POST.get('end_point', ''),
            route_json=points,
            distance_km=round(distance, 2),
            elevation_gain=elevation,
        )
        return redirect('route_detail', pk=route.pk)
    return render(request, 'routes/create.html')

这里有一个我踩过的坑：前端传来的points_raw有时候是标准JSON数组，有时候因为框架序列化转了一道，变成了带转义符的字符串，后端解析就会失败。所以前后端必须约定好数据结构，我统一用[{lat: 30.1, lng: 120.2}, ...]这种最简单格式，不做嵌套，不传多余字段。

4. 关键功能实现与地图交互

4.1 用Leaflet在详情页展示路线轨迹

地图组件我选的是Leaflet加OpenStreetMap。选Leaflet主要因为轻量、免费、不需要申请AppKey，对个人项目非常友好。

详情页模板里的核心代码大致是这样：

html复制{% extends 'base.html' %}
{% block content %}
<div id="map" style="height: 500px; width: 100%;"></div>
{{ route.route_json|json_script:"route-data" }}
<script>
var route = JSON.parse(document.getElementById('route-data').textContent);
var map = L.map('map').setView([route[0].lat, route[0].lng], 13);
L.tileLayer('https://{s}.tile.openstreetmap.org/{z}/{x}/{y}.png', {
    attribution: '© OpenStreetMap contributors'
}).addTo(map);
var latlngs = route.map(function(p) { return [p.lat, p.lng]; });
L.polyline(latlngs, {color: '#3498db', weight: 4}).addTo(map);
</script>
{% endblock %}

这里有个细节必须提醒。很多人刚开始写模板时直接写{{ route.route_json|safe }}，把JSON字符串原样输出到<script>标签里。但我强烈建议用json_script模板标签，它会把JSON渲染成<script type="application/json">标签，浏览器不会当脚本执行，也不容易被XSS攻击，更加安全。前端通过JSON.parse读取，很干净。

另一个细节是初始化地图的视角。如果路线第一个点正好在偏远郊区，地图显示范围会很偏。更好的做法是先算出所有坐标点的中心点，再设置视野范围。Leaflet提供了L.polyline之后可以调用 map.fitBounds(line.getBounds())，这样不管路线在哪，地图都能自动缩放到完整展示全路线，体验好很多。

4.2 创建路线页：打点、撤销、自动计算

路线创建页面是用户交互最重的地方。我用了Leaflet的可点击事件，让用户在地图上打点画线：

js复制var points = [];
map.on('click', function(e) {
    var lat = e.latlng.lat;
    var lng = e.latlng.lng;
    points.push({lat: lat, lng: lng});
    redrawLine();
    document.getElementById('points-input').value = JSON.stringify(points);
});

function redrawLine() {
    L.polyline(points.map(function(p) { return [p.lat, p.lng]; }), {color: 'red'}).addTo(map);
}

这里有两个体验细节必须处理。第一个是“撤销上一个点”，用户点错了要能回退，我在页面里加了一个撤销按钮，原理就是points.pop()，然后重画整条轨迹。第二个是“清空重画”，对应points = []。没有这两个功能，用户画错一条路线只能刷新页面重来，贡献一条路线可能要花十几分钟，他们很快就会流失。

画线过程中，我会在页面上实时显示当前点数和预估里程，用前端的Haversine函数算一遍，给用户即时反馈。但最终入库时一定以后端计算为准，前端计算只是给用户预览，不能信任。

创建页的完整数据结构是一个隐藏input：

html复制<input type="hidden" id="points-input" name="points">

提交表单时，points-input里已经写好了完整的坐标JSON，后端直接解析即可。

4.3 评论、收藏和作者联动

评论功能我用了一个简单的POST表单，提交成功后回到详情页。模板里要放CSRF token，否则Django会直接拒绝请求：

html复制<form method="post" action="{% url 'add_comment' route.pk %}">
    {% csrf_token %}
    <textarea name="content" required></textarea>
    <button type="submit">发表评论</button>
</form>

收藏功能用的ManyToManyField，收藏按钮实际上就是切换视图：

python复制@login_required
def toggle_favorite(request, pk):
    route = get_object_or_404(Route, pk=pk)
    if request.user in route.favorites.all():
        route.favorites.remove(request.user)
    else:
        route.favorites.add(request.user)
    return redirect('route_detail', pk=pk)

这个方案简单实用。收藏数量可以直接用route.favorites.count()，个人主页展示“我发布的路线”和“我收藏过的路线”，本质上就是两个查询加一个模板页面，没有额外复杂度。

列表页也可以显示每一条路线的收藏数和评论数。这里要顺手用annotate做聚合查询，避免在模板里循环count()造成N+1查询。

4.4 图片和视频上传的扩展思路

很多骑行分享平台希望用户能上传骑行照片甚至视频，给路线做封面或者游记展示。Django的图片上传并不复杂，关键在于配置。

首先在settings.py里设置：

python复制MEDIA_URL = '/media/'
MEDIA_ROOT = BASE_DIR / 'media'

然后在根urls.py里手动加静态文件路由，开发环境才能访问上传后的文件：

python复制from django.conf import settings
from django.conf.urls.static import static

urlpatterns += static(settings.MEDIA_URL, document_root=settings.MEDIA_ROOT)

模型里的字段定义很简单：

python复制cover_image = models.ImageField(upload_to='route_covers/', blank=True, null=True)
route_video = models.FileField(upload_to='route_videos/', blank=True, null=True)

但要注意，默认情况下Django不会限制上传文件大小，本地开发没问题，部署到服务器后如果不对上传做限制，磁盘很容易被塞满。另外，大视频最好不要直接存服务器磁盘，生产环境应该传到对象存储，数据库里只保存URL。这个点我是部署之后才发现的，本地开发一时爽，上线磁盘紧张的时候非常被动。

5. 常见问题与排查技巧实录

5.1 环境类和虚拟环境问题

做这个项目时我遇到过不少环境问题。第一个是Python版本不一致，本地写代码用的3.10，部署到服务器发现是3.7，一些语法直接报错。比如我写过list[str]这种类型标注，Python 3.9以下根本不认，Django也会因此报解释器兼容性错误。所以项目一开始就把Python版本固定下来，最好在项目根目录放一个runtime.txt或README说明。

第二个是虚拟环境问题。很多人会在一个全局环境里装了一堆包，两个项目依赖冲突了，就开始硬调代码。我的建议是每个项目一套venv，并定期用pip freeze > requirements.txt导出依赖清单，换电脑或者部署时直接pip install -r requirements.txt就能复现环境。

如果你确实需要删除某个Django虚拟环境，直接删目录即可。这个操作不会影响全局Python，不影响系统其他项目。删除后如果发现命令行还能用django-admin，那多半是旧版本全局安装的Django，跟这个虚拟环境无关。这个问题很多人会误判，觉得虚拟环境没删干净，其实不是。

5.2 静态文件加载不出来和模板404

页面引用了CSS、JS，但一直404，这是我见过最多的问题。开发环境里，Django默认用django.contrib.staticfiles处理静态文件，但前提是静态文件目录的配置是准确的。

如果你想把Leaflet的JS下载到本地项目里，需要先建一个static目录，然后在settings.py里配置：

python复制STATIC_URL = '/static/'
STATICFILES_DIRS = [BASE_DIR / 'static']

模板里用{% load static %}，再通过{% static 'leaflet/leaflet.js' %}引用。

另一个常见问题是加载了Leaflet的CSS但地图还是显示不出来，通常是因为没有引leaflet.css或者容器div高度为0。Leaflet地图容器必须有一个明确的高度，不然地图就只是个空白页面。CSS里给#map设置height: 500px是最稳妥的做法。

5.3 地图加载慢、拖动卡顿

地图页面加载慢，先查坐标点数量。我在测试时上传过一条一百多公里长的路线，坐标点有3000多个，Leaflet直接卡成幻灯片。优化方案有两个。

第一步，后端抽稀。遍历所有坐标点，把相邻距离小于3米的点删掉，保留关键转折点，数据量能减少一半以上。第二步，前端给L.polyline设置smoothFactor: 2.5，这是Leaflet的简化渲染参数，会让曲线在渲染时主动做抽稀合并，肉眼几乎看不出差别，但拖动地图时的流畅度提升非常明显。

如果你还要用ECharts画海拔曲线图，同样要做抽稀，不然折线图上面全是点，交互起来会非常卡。

5.4 查询性能：N+1问题

列表页显示每条路线的作者，如果模板里写{{ route.author.username }}，每循环一次就会查一次用户表。100条路线就是101次查询，页面响应时间会明显变长。

解决办法是select_related('author')，提前用SQL的JOIN把作者查出来：

python复制qs = Route.objects.select_related('author').all().order_by('-created_at')

同理，如果列表页要显示评论数或收藏数，可以用annotate加聚合字段，而不是每次都去count()。这在数据量小的时候看不出来，但平台只要积累到几千条路线，性能差距就会非常明显。骑行分享平台是内容型项目，查询频率远高于写入频率，列表页的每个字段访问都要想着“这会不会多查一次数据库”。

6. 部署上线前要注意的几件事

6.1 从DEBUG模式切到生产模式

开发结束之后部署到服务器，第一件事就是关DEBUG。如果开着DEBUG上线，用户一旦触发异常，页面会直接暴露项目目录结构、数据库配置等敏感信息，安全风险非常大。同时要配置ALLOWED_HOSTS，只允许你的域名访问：

python复制DEBUG = False
ALLOWED_HOSTS = ['your-domain.com', 'www.your-domain.com']

然后执行python manage.py collectstatic，把散落在各处的静态文件收集到一个目录，生产环境由Nginx统一处理静态资源，Django只负责动态请求。

我在部署时用过两种方案。一种是在Linux服务器上直接装Python、用gunicorn跑Django、再用Nginx做反向代理；另一种是用宝塔面板的Python项目管理器部署。宝塔方式对新手更友好，界面化建站点、配Python环境，省去了不少手敲命令的时间，但底层原理依然是gunicorn加Nginx。如果网站出问题，还是要会看日志。我的建议是至少手敲一遍gunicorn启动命令，能跑通再考虑用面板。

code复制
gunicorn cycling_platform.wsgi:application --bind 0.0.0.0:8000

6.2 数据安全与权限的检查清单

上线前一定要检查三类问题。第一，用户上传的轨迹点是否合法，纬度范围是-90到90，经度范围是-180到180，后端必须做校验，否则线路图会指向奇怪的地方，甚至会显示异常里程。第二，评论内容要对XSS做防护，Django模板默认会转义，但如果你在页面里用了|safe过滤器，一定要确认字段内容能不能完全信任。第三，上传图片和视频要限制文件类型和大小，前端校验只是体验问题，后端校验才是安全底线。

另外，服务器的时区一定要调好。Django默认TIME_ZONE = 'UTC'，如果你不做设置，用户创建路线的时间会比本地时间晚8个小时，看起来就像在“倒时差开发”。正确做法是项目设置里改成TIME_ZONE = 'Asia/Shanghai'，同时保持USE_TZ = True，数据库里存UTC时间，展示时自动转成本地时间，逻辑最清晰。

6.3 后续功能可以怎么扩展

这个平台做完基础版本之后，我列了三个后续方向。第一，接入移动端轨迹文件导入，用户直接上传手表的GPX文件，解析轨迹并自动生成路线，这个功能对经常骑长途的车友吸引力非常大。第二，增加地图模式搜索，把搜索结果直接聚合展示在地图上，用户拖动地图时按视野范围刷新结果，比传统列表更直观。第三，把评论扩展成图文混排，让用户可以在路线页面晒照片、说体验，慢慢把平台从“路线库”做成“小圈子”。

这些方向都不需要推翻现有结构，都是在Route模型和现有URL路由上做增量，数据模型设计阶段留出的余量这时候就体现出来了。

做骑行路线平台这个项目，对我最大的启发是：技术栈并不需要多复杂，Django配Leaflet已经能覆盖绝大部分需求，关键是数据模型和前后端接口约定要早点定下来。如果你也在做类似的项目，我建议先画清楚用户故事，把一条完整链路走通——创建路线、保存路线、地图展示、评论收藏——再来补边角功能。真正做好“路线分享”这件事，不是堆功能，而是让用户花最少的时间看懂一条线路到底能不能骑、怎么骑。最后再分享一个小技巧：把坐标抽稀放在数据处理层而不是前端，前端代码量能省很多，性能问题也能在根源上解决，这个改动虽然小，但体验提升非常明显。