从 Django 到 Next.js - 我为什么迁移, 又保留了什么

从 Django 到 Next.js - 我为什么迁移, 又保留了什么

"能跑就别动" 是独立开发者的生存法则. Django 还在跑, Next.js 是新项目的选择, 两者并存
技术栈迁移是独立开发者最容易掉进去的坑之一. 这篇聊的就是我从 Django 全栈逐步转向 Next.js 的过程: 为什么迁, 怎么迁, 以及为什么没有彻底迁完.

背景: Django 时代

StellarView 是我最早的项目, 一个用 Django 搭建的管理后台. Django Admin 开箱即用, 不需要写前端就能有完整的管理界面. 对于一个 "只有自己用" 的后台, Django 是最高效的选择.

转折点: 面向用户的产品

StellarMail 需要漂亮的前端, 实时更新, Stripe/Supabase 集成, Vercel 一键部署. 这些让 Django 的局限性暴露出来:
  • 前端体验: Django 模板引擎做复杂交互很痛苦
  • 前后端分离: Django REST Framework + React = 两套框架各做一半
  • 生态趋势: 2024 年独立开发者生态已完全倒向 React/Next.js + Supabase
  • 部署: Vercel 一键部署 vs Django 的 Gunicorn + Nginx
Django vs Next.js 14 对比
Django vs Next.js 14 对比

迁移策略: 新建而不是重写

StellarView (Django) 还在跑, 我没有重写它的计划:
  1. 机会成本: 重写 2-3 周, 不创造新价值
  1. "能跑就别动": 稳定运行, 没有 bug, 没有重写的理由
  1. 渐进替代: 新需求用新技术栈, 旧系统自然退役
策略: 新项目 → Next.js 14 + Supabase + Vercel. 旧项目 → 保持 Django.

Django 保留的价值

  • Admin 后台无可替代: 管理数据 10 分钟搞定, Next.js 可能需要 2 天
  • Python 生态: 数据分析, ML, 爬虫, 脚本自动化
  • ORM 成熟度: migration 系统, QuerySet API 比 Prisma/Drizzle 成熟

决策框架

  • 有面向用户的前端? → Next.js + Supabase + Vercel
  • 只是内部工具? → Django Admin
  • 核心逻辑是 Python? → Python 项目, 需要 Web 再加 Django
  • 需要多快上线? → 原型用 Next.js, 内部工具用 Django

给犹豫者的建议

  1. 不要重写正在运行的项目
  1. 新项目用新技术栈试水
  1. 迁移的唯一正确理由是 "新栈能让我更快交付价值"
  1. 两个栈并存是完全正常的
  1. 技术栈是手段, 不是目的