简介一份基于Django框架的股票市值管理系统源码面向Web开发学习者和金融数据爱好者帮助解决多市场证券账户的集中跟踪与市值记录问题。系统覆盖港股、美股交易场景包含用户账户、证券、交易记录、分红记录、新股信息等核心数据模型并体现模型、视图、模板、地址路由、表单、认证、中间件以及数据库配置等完整开发链路项目遵循Django分层设计思想从数据模型定义、业务逻辑封装到页面渲染均有清晰分工适合边读代码边对照学习。包内共2030个文件以SVG图标、SCSS样式、JavaScript脚本、HTML模板和Python文件为主另有CSS、LESS、字体及工程配置文件整体约8.95MB目录结构清晰方便按模块检索学习其中SVG文件占比高便于直接复用图标资源。已有218人浏览学习。源码同时包含前后端静态资源、页面模板与核心逻辑配置适合作为仿真实战项目帮助理解账户持仓展示、历史交易管理、分红新股记录等功能从数据表到页面呈现的落地方式也可在此基础上扩展实时行情或权限控制等进阶能力。1. Django 股票市值管理系统源码比 CRUD 多走一步的完整业务闭环「Django 股票市值管理系统」不是让你抓行情、算涨跌的量化脚本而是一套能在浏览器里完整跑起来的 Web 工程项目用户登录、股票标的登记、持仓管理、买卖交易流水、市值仪表盘图表全部串在同一条业务链上。它真正解决的是 Django 学习者最常见的断层——模型写完了不知道视图怎么接、模板怎么渲染、聚合统计该放在哪一层也适合需要交付「有业务深度」毕业设计或内部演示后台的人。我的建议是不要只把它当成品跑通而是照着这套代码把「市值怎么算、数据怎么更新、页面怎么呈现」这个循环完整走一遍下面每一章都按这个链路来拆。2. 拆解项目骨架模型、视图、路由如何组成市值管理系统解压 ZIP 后的第一件事不是急着runserver而是先读一遍目录结构。一个 Django 工程通常由一个 project 和若干 app 组成这套源码把「股票标的、持仓」与「交易流水」拆成两个业务域职责边界很清晰谁能买卖、什么标的、当前持有多少由持仓侧负责每一笔成交记录、买卖方向、成交价格由交易侧负责。2.1 功能模块划分把「股票」和「交易」拆成两个业务域我拆过的几个管理类项目里最常见的失败案例是「把所有模型写进同一个 models.py」表面看省事一旦业务增长视图和表单也跟着膨胀。这套源码的做法更合理新建两个 app一个是stocks一个是transactions在settings.py的INSTALLED_APPS里注册后Django 才会为它们建表并提供 admin 入口。# settings.py 中的注册片段示例 INSTALLED_APPS [ django.contrib.admin, django.contrib.auth, django.contrib.contenttypes, django.contrib.sessions, django.contrib.messages, django.contrib.staticfiles, stocks, # 标的地与持仓 transactions, # 交易流水 ]这段配置的作用是告诉 Django「这两个 app 是当前工程的一部分」。注册之后python manage.py migrate才会扫描stocks和transactions下的models.py把它们翻译成数据库表。参数上不需要额外改动只要保证 app 目录名和你INSTALLED_APPS里写的字符串一致否则启动时会报ModuleNotFoundError。另一个容易忽略的文件是urls.py。project 级路由负责把请求分发到各 appapp 内部自己维护更细的路由避免项目越来越大后出现「路由文件里几百行挤成一坨」的情况。下面这种include写法是 Django 项目的常见组织方式# project/urls.py示例 from django.contrib import admin from django.urls import path, include urlpatterns [ path(admin/, admin.site.urls), path(, include(stocks.urls)), path(transactions/, include(transactions.urls)), ]include的作用是把stocks.urls里定义的所有路由挂到根路径把transactions.urls挂到transactions/前缀下。这样处理的好处是后续新增页面时只需在对应 app 的urls.py里追加记录不用频繁改动 project 级路由。如果你在源码里看到某个 app 的urls.py里用了app_name stocks意味着模板里可以用{% url stocks:position_list %}这种带命名空间的写法比硬编码 URL 更抗改版。2.2 核心数据模型持仓表、标的表与交易流水表业务核心就三张表。第一张是标的表记录股票代码和名称第二张是持仓表记录某用户持有某标的的数量、成本价、当前价第三张是交易流水表记录每一次买卖的方向、价格、数量和成交时间。把「当前价」放进持仓表而不是标的表是这套源码一个很务实的设计决定——同一只股票在不同用户手里成本不同但市价是一样的把市价放到持仓表里虽然会冗余却方便按用户维度直接汇总不用关联查询。# stocks/models.py示例结构 from django.db import models from django.contrib.auth.models import User class Stock(models.Model): code models.CharField(max_length20, uniqueTrue, verbose_name股票代码) name models.CharField(max_length50, verbose_name股票名称) exchange models.CharField(max_length10, blankTrue, verbose_name交易所) class Meta: ordering [code] def __str__(self): return f{self.code} {self.name} class Position(models.Model): user models.ForeignKey(User, on_deletemodels.CASCADE, verbose_name所属用户) stock models.ForeignKey(Stock, on_deletemodels.CASCADE, verbose_name股票) quantity models.IntegerField(default0, verbose_name持仓数量) cost_price models.DecimalField(max_digits10, decimal_places2, verbose_name成本价) current_price models.DecimalField(max_digits10, decimal_places2, verbose_name当前价) class Meta: unique_together (user, stock) def __str__(self): return f{self.user.username} - {self.stock.code}这里有几个字段参数要仔细看。uniqueTrue保证同一股票代码不会重复录入on_deletemodels.CASCADE表示用户或标的一旦被删除关联的持仓记录也一起清理避免产生悬空引用DecimalField是财务计算的关键——它存的是定点数不会像FloatField那样出现「0.1 0.2 0.30000000000000004」的浮点误差。unique_together则从数据库层防止同一个用户对同一只股票出现两条持仓这个约束比在视图里做 if 判断可靠得多。交易流水表的设计倾向于「只追加、不修改」每一笔买卖都是一条独立记录通过direction字段区分买入还是卖出。计算持仓时要么以这张流水表为准做汇总要么以持仓表冗余的数量为准正规做法是流水表作为唯一事实来源持仓表只是它的物化视图。2.3 视图与路由登录、列表页与仪表盘怎么串联这套源码的视图风格更接近 Django 传统的函数式视图FBV核心逻辑用login_required装饰器把未登录用户挡在门外然后依次执行「查数据、算聚合、渲染模板」三个步骤。函数式视图的好处是直白初学者能从request到response一眼看完整条链路。# stocks/views.py示例 from django.shortcuts import render from django.contrib.auth.decorators import login_required from .models import Position login_required def position_list(request): positions Position.objects.filter(userrequest.user) total_value sum(p.quantity * p.current_price for p in positions) ctx { positions: positions, total_value: total_value, } return render(request, stocks/position_list.html, ctx)filter(userrequest.user)是权限控制的关键。只有当前登录用户能看到自己的持仓不会出现「A 登录却看到 B 的股票」这种事故。sum(p.quantity * p.current_price ...)在数据量小的时候完全够用如果以后持仓记录上千条就要把这段移到数据库聚合里用annotate或 SQL 的SUM把计算压力从 Python 下推到数据库。对应的路由文件长这样# stocks/urls.py示例 from django.urls import path from . import views app_name stocks urlpatterns [ path(, views.position_list, nameposition_list), path(dashboard/, views.dashboard, namedashboard), ]路由里三个信息缺一不可URL 表达式、视图函数、路由别名。name的作用在模板里体现最明显——写{% url stocks:position_list %}而不是硬编码/将来路径改了模板不用跟着动。我在实际项目里吃过硬编码 URL 的亏某次把列表页从根路径迁到/portfolio/模板里所有href/全部失效那之后每个路由我都强制带上name。3. 把项目跑起来从解压 ZIP 到浏览器出现仪表盘拿到源码包后最快验证「这项目到底能不能跑」的方法是本地跑通。Django 项目跑不起来的原因大多不在代码本身而在环境不一致Python 版本不对、依赖缺失、数据库没迁移。按下面顺序操作可以把变量降到最少。3.1 虚拟环境与依赖安装我一般会在项目根目录建独立虚拟环境避免把依赖装进全局 Python。依赖清单通常写在requirements.txt里内容大致是Django、django-crispy-forms、Pillow这类。装依赖前先确认 Python 版本Django 3.2 以上版本对 Python 3.8 以上的支持更稳定。cd 股票市值管理系统 python -m venv venv source venv/bin/activate # Windows 下使用 venv\Scripts\activate pip install -r requirements.txtpython -m venv venv创建名为venv的虚拟环境source venv/bin/activate把它激活后终端提示符前会多出(venv)字样。后面pip install安装的包都会装进这个环境跟系统 Python 隔离。如果requirements.txt里锁定了具体版本号就不要轻易升级到最新版Django 生态里「跑的时候一切正常一升级开始报兼容性错误」是高频翻车场景。装完依赖后可以先跑一下诊断命令确认 Django 能识别这个工程python manage.py checkcheck是 Django 自带的环境自检命令不依赖数据库就能跑。它用来检查配置项有没有写错、模型定义有没有语法问题。看到System check identified no issues再往下走如果这里报错通常是INSTALLED_APPS里写了不存在的 app或者settings.py里某个配置项类型不对按报错提示修掉即可。3.2 配置 settings 与数据库迁移大多数 Django 入门项目默认使用 SQLite这套源码如果没额外配置也是这个默认值。SQLite 的好处是零部署、单文件、适合学习复现缺点是并发写入能力弱、生产环境基本不考虑。你可以在settings.py里看到DATABASES配置默认长这样# settings.py示例 DATABASES { default: { ENGINE: django.db.backends.sqlite3, NAME: BASE_DIR / db.sqlite3, } }BASE_DIR / db.sqlite3的意思是数据库文件会生成在项目根目录。如果源码自带了db.sqlite3文件你可以先直接运行试试但更建议删掉它重新迁移保证数据表结构与当前代码一致。很多「源码头 demo 能跑我复制到别处就报错」的怪问题都是因为数据库里残留了旧版本的模型结构。数据库迁移分两步python manage.py makemigrations python manage.py migratemakemigrations对比模型定义与数据库现状生成迁移文件migrate把这些迁移文件真正应用到数据库。第一次跑时Django 会创建auth、sessions等内置 app 所需的表然后创建stocks和transactions的表。如果makemigrations后提示「No changes detected」说明代码里的模型和数据库已经是同步状态直接migrate即可。3.3 创建管理员账号与启动服务访问管理后台前需要先建一个超级用户。这一步会被很多人跳过直到运行runserver后点击admin/页面才发现登录不进去。python manage.py createsuperuser python manage.py runservercreatesuperuser会依次询问用户名、邮箱、密码邮箱可以为空密码要满足 Django 的安全策略太短会直接拒绝。创建成功后启动开发服务器默认监听127.0.0.1:8000。浏览器打开http://127.0.0.1:8000能看到项目的首页或登录页打开http://127.0.0.1:8000/admin用刚才的账号登录就能看到 Stock 和 Position 的管理入口。如果源码包里有初始演示数据一般会以 fixture 的形式放在fixtures目录下。导入它们的命令是python manage.py loaddata initial_data.jsonloaddata读取fixtures目录下的 JSON 或 YAML 文件把预置的演示数据写进数据库。这一步能让你不用手动敲几十条持仓记录直接就着样例数据测试仪表盘效果。导入要放在migrate之后因为表结构不存在时数据也进不去如果导入报Fixture loading failed先检查文件路径是否正确、文件里引用的字段是否和当前模型一致。4. 市值与盈亏计算核心业务逻辑的复现过程当页面和数据通道都跑通后重点就落到这台系统的「业务核心」上持仓市值到底怎么算、盈亏由哪些字段决定、行情数据从哪里来。很多仿写的管理系统只做了录入和展示真正算钱的逻辑却经不起追问这一章把计算口径拆开讲透。4.1 市值与盈亏计算口径用 Decimal 而不是 Float计算口径其实很朴素持仓市值等于持仓数量乘以当前价格持仓成本等于持仓数量乘以成本价格浮动盈亏用市值减去成本。但「朴素」不代表「容易写对」最容易出错的是数值类型选错。# stocks/utils.py示例 from decimal import Decimal def calc_market_value(quantity, current_price): return Decimal(quantity) * Decimal(current_price) def calc_profit(position): market_value calc_market_value(position.quantity, position.current_price) cost_value Decimal(position.quantity) * Decimal(position.cost_price) return market_value - cost_valueDecimal(quantity) * Decimal(current_price)这一步是关键。如果你直接拿position.quantity * position.current_price当字段类型是DecimalField时 Django 返回的也是Decimal看起来没问题但如果当前价在代码里是从外部 API 拿来的float运算结果就会混入浮点误差。Decimal(0.1)和float(0.1)的二进制表示不同前者是精确的十进制定点表示后者是近似值。做财务计算时我要求所有金额运算都走Decimal且小数位数用quantize显式指定避免汇总后出现多位小数。另一个口径问题是「盈亏要不要区分已实现和未实现」。这套系统里如果只有持仓表和流水表最简单的方式是只展示浮动盈亏如果有完整的卖出流水可以在汇总时把「卖出金额减买入成本」算成已实现盈亏。两种计算结果展示在同一张仪表盘上才是完整的投资视角。看源码时留意它用的是哪种口径以及是否把佣金、印花税计入成本——很多管理系统默认不算只能叫「毛盈亏」。4.2 行情数据更新手动录入、批量导入与接口扩展这套源码的行情更新机制大概率是「管理后台手动维护」也就是在 Django Admin 或自定义表单里修改Position.current_price。这种方案对教学质量系统和本地复现完全够用但如果你希望每天自动更新需要自己接数据源。# stocks/views.py示例更新单个持仓价格 def update_position_price(request, pk): position Position.objects.get(pkpk, userrequest.user) new_price request.POST.get(current_price) if new_price: position.current_price new_price position.save(update_fields[current_price]) return redirect(stocks:position_list)save(update_fields[current_price])是值得记住的性能习惯只更新指定字段避免把整行数据重新写入。逻辑上先通过get(pkpk, userrequest.user)做了双重过滤确保用户只能改自己的持仓价格。表单提交后立刻重定向到列表页符合 Post-Redirect-Get 模式防止刷新页面时重复提交。批量导入场景则常见于从行情软件导出 Excel 或 CSV。Django 管理后台对 CSV 导入没有原生支持最省事的做法是用csv模块写一个小脚本或者安装django-import-export接入 Admin。脚本导入时建议用update_or_create它按查询条件找记录找到就更新找不到就创建天然适合「每日收盘价刷新」这种幂等操作。# manage.py shell 中运行的导入片段示例 import csv from decimal import Decimal from stocks.models import Stock, Position with open(prices.csv, encodingutf-8) as f: for row in csv.DictReader(f): Stock.objects.update_or_create( coderow[code], defaults{name: row[name]} )update_or_create的第一个参数是查询条件codedefaults里是待写入的非查询字段。这样重复执行同一份 CSV 不会产生重复数据只会把名称等字段覆盖为新值。字段名要和 CSV 列名完全一致否则row[code]会抛KeyError这也是 CSV 导入最常见的低级错误。4.3 仪表盘图表把 QuerySet 转成图表数据仪表盘页面是整个项目的「门面」通常展示三样东西总市值、总浮动盈亏、持仓分布饼图。饼图数据不能直接喂给图表库需要把持仓按股票代码聚合转成{name, value}结构。# stocks/views.py示例仪表盘数据聚合 from django.db.models import Sum, F from django.db.models.functions import Round def dashboard(request): positions Position.objects.filter(userrequest.user).annotate( market_valueRound(F(quantity) * F(current_price), 2) ) distribution list(positions.values(stock__name, market_value)) for item in distribution: item[value] item.pop(market_value) item[name] item[stock__name] total_value sum(item[value] for item in distribution) return render(request, stocks/dashboard.html, { distribution: distribution, total_value: total_value, })F(quantity) * F(current_price)把计算下推到数据库执行Round保留两位小数这比把所有持仓加载到 Python 内存里再算更合理。values(stock__name, market_value)返回字典列表通过pop和重命名把字段对齐成 ECharts 饼图需要的name/value格式。前端模板里用| safe过滤器把列表序列化成 JSON 输出给图表库即可。!-- templates/stocks/dashboard.html示例片段 -- script const chartData {{ distribution|safe }}; /script模板过滤器safe的目的是告诉 Django「这段内容已可信不需要 HTML 转义」。但要注意如果数据里包含用户可输入的字符串直接safe会有 XSS 风险。这里的数据来源是股票名称和数值风险可控线上系统更稳妥的做法是用json_script过滤器Django 会把它包进script typeapplication/json里再解码天然避开注入问题。5. 复现项目时最容易翻车的五个位置迁移、静态文件与密码处理任何源码包拿过来前 30 分钟最容易踩的坑几乎集中在环境、数据、静态资源这三类。我把复现这个 Django 项目时的高频问题按「现象 → 原因 → 解决」整理成清单每一条都是真实拆项目时会撞上的。5.1 迁移时报错「no such table」或「relation does not exist」现象执行python manage.py runserver后访问页面抛OperationalError: no such table: stocks_position或者migrate时报django.db.utils.ProgrammingError: table already exists。原因最常见的是源码包自带了旧版db.sqlite3数据库里的表结构来自开发时的旧模型新代码里改了字段名或新增了表迁移逻辑对不上。其次是没有先makemigrations就直接migratemodels.py的改动还没有生成迁移文件。解决如果不需要保留原库直接删掉db.sqlite3再执行一遍makemigrations migrate。如果需要保留数据则要逐条检查迁移记录python manage.py showmigrations找到未应用的迁移用python manage.py migrate app_name 迁移编号往前挪一格再重新migrate。实在对不齐时migrate --fake只标记不执行但这是一剂后悔药用了之后手动造表会很累我一般只在确定表结构已经存在时才用。5.2 页面能打开但所有 CSS 和 JS 都不加载现象浏览器里整个页面是裸 HTML没有样式、图片裂开、控制台刷一堆 404路径指向/static/。原因settings.py里STATIC_URL配了但缺少STATICFILES_DIRS指向静态文件目录或者模板顶部根本没有加载{% load static %}。Django 开发服务器在DEBUGTrue时才会自动托管静态文件DEBUGFalse时它不会处理/static/请求。解决确认目录结构后补上配置# settings.py示例 STATIC_URL /static/ STATICFILES_DIRS [BASE_DIR / static]同时在模板文件最上方加入{% load static %}引用路径写成{% static css/style.css %}而不是硬编码/static/css/style.css。这样写的好处是部署时会自动加上静态文件指纹避免浏览器缓存旧版本。如果前端还用了图片和图表库的本地文件检查是否都放进了同一目录按项目名或按 app 分目录都行关键是路径要一致。5.3 中文数据显示成乱码现象Admin 后台里中文字段正常但runserver控制台或模板页面上出现æ··ä¹±形式的乱码或者反向CSV 导入中文股票名称后数据库里变成问号。原因两种场景原因不同。控制台乱码是终端编码问题Windows 下常见于默认 GBK 编码与 Django 输出的 UTF-8 不匹配数据库问号则是因为创建库时字符集没有指定为utf8mb4或者 CSV 文件本身不是 UTF-8 编码。解决先把 CSV 文件另存为 UTF-8 编码记事本另存时选 UTF-8导入脚本里open(prices.csv, encodingutf-8)显式指定编码。如果连接的是 MySQL在建库时执行SET NAMES utf8mb4;并在DATABASES配置的OPTIONS里传入charset: utf8mb4。Windows 终端乱码可以在运行命令前执行chcp 65001切换到 UTF-8 代码页或者用 IDE 内置终端代替系统自带终端。5.4 密码以明文形式出现在数据库里现象打开sqlite3或 MySQL 查看用户表发现password字段存的是明文和注册表单里输入的一模一样。原因源码里的注册视图没有使用 Django 自带的User管理逻辑而是直接把表单里password字段的值写入auth_user表。可能是开发者为演示方便自建了用户注册但跳过了set_password加密步骤。解决把注册视图改为通过User.objects.create_user(username..., password...)创建用户这个方法会调用哈希算法库里只存不可逆的密文。如果数据已经写进去了需要清空或重置密码# manage.py shell 中执行示例 from django.contrib.auth.models import User user User.objects.get(username你的用户名) user.set_password(new_password) user.save()set_password的作用是生成加盐哈希并写回password字段save()提交到数据库。处理后旧的明文记录被覆盖登录时 Django 会用同样的哈希算法校验。顺带检查一下settings.py里是否设置了PASSWORD_HASHERS如果源码里写死了不安全的旧算法建议删掉或改用默认配置。5.5 本地访问被ALLOWED_HOSTS拦截现象访问http://127.0.0.1:8000时页面提示Bad Request (400)信息里写DisallowedHost。原因ALLOWED_HOSTS在settings.py里被配置成了固定域名列表而你用的是 IP 或localhost访问。解决在settings.py里把本机地址加进去ALLOWED_HOSTS [127.0.0.1, localhost]ALLOWED_HOSTS是 Django 的 Host 头校验机制防止恶意请求伪造域名。本地开发时这两个足够runserver默认监听的地址就是127.0.0.1,所以一般不是它拦。如果你用runserver 0.0.0.0:8000让局域网同事访问还要加上本机局域网 IP否则同事访问时会看到同样的 400 错误。6. 再进一步把市值管理系统改成自用投资仪表盘的做法前几章把源码跑通后下一步就是按自己的习惯改造。这里分享三个我实际用过的小技巧改动量不大但对使用体验提升非常明显。6.1 在 Admin 里加列表筛选替代手写管理页Django Admin 自带的list_display、search_fields和list_filter就能省掉一半自建页面的功夫。以持仓表为例# stocks/admin.py示例 from django.contrib import admin from .models import Position admin.register(Position) class PositionAdmin(admin.ModelAdmin): list_display (user, stock, quantity, cost_price, current_price) search_fields (stock__code, stock__name) list_filter (user,)search_fields里写stock__code是跨表查询语法搜索框输入股票代码或名称就能过滤list_filter按用户分组筛选适合切换多个账号的持仓对比。6.2 用定时任务每天刷新收盘价手动改价格偶尔一两次还行长期用必须自动化。django-crontab或APScheduler都可以我更推荐简单的系统 crontab 配合 Django management command。在 app 下新建management/commands/refresh_prices.py封装一个从公开数据源拉取收盘价的函数然后配置每天 16 点执行。# crontab 示例每天 16:10 刷新 10 16 * * 1-5 cd /path/to/project venv/bin/python manage.py refresh_prices定时任务最重要的排错点是时区和节假日如果数据源在非交易日返回的是旧数据要把「交易日判断」写进命令里否则周五执行的命令会在周六也跑一遍产生重复写入。6.3 导出 CSV 报表给「自己看」做个出口在 Admin 的actions里加一个「导出选中持仓」的 action选中几行就能下载对应 CSV比自己拼print方便得多import csv from django.http import HttpResponse def export_csv(self, request, queryset): response HttpResponse(content_typetext/csv; charsetutf-8) response[Content-Disposition] attachment; filenamepositions.csv writer csv.writer(response) writer.writerow([用户, 代码, 名称, 数量, 成本价, 当前价]) for obj in queryset: writer.writerow([obj.user.username, obj.stock.code, obj.stock.name, obj.quantity, obj.cost_price, obj.current_price]) return response我有一次在自用系统里改 Dashboard 统计口径直接改视图里的聚合逻辑结果把另一处依赖current_price的表单页也带崩了排查到最后发现是两处各自维护了一份「最新价」数据不一致。从那以后我每次给这种管理项目加功能前都会强制自己先把数据的「单一事实来源」找出来确认所有页面读的是同一张表或同一个接口才敢下手改代码——这次拆这套 Django 股票市值管理源码也是这样先理清数据和计算链路再谈改造。希望帮到你。本文还有配套的精品资源点击获取