企业官网建设流程全解析

简介：本资源是一套基于Python与Django开发的网易云音乐用户行为分析可视化大屏系统，面向计算机专业本科生、毕业设计学生及数据分析初学者，解决音乐平台用户画像构建与播放行为深度分析的实际问题。项目包含54个文件，涵盖24个核心Python源码（含爬虫、Django后端、ECharts前端逻辑）、4个CSV原始数据集、7张PNG可视化图表、3份Markdown说明文档及1份PDF设计报告，包体仅10.57MB，轻量易部署。已有62人学习下载，适合课程设计、毕设选题与教学演示。读者可直接运行完整可交互大屏，获取从Scrapy爬取热歌榜、MySQL存储、到用户分群与行为路径分析的全流程实现；配套详细设计文档与结课项目说明，清晰呈现数据采集→清洗→建模→可视化的技术闭环，同时支持在现有结构上快速扩展推荐模块或迁移至其他音乐平台。

1. 网易云音乐可视化（Python）-Django大屏-用户画像+播放行为分析：不是炫技大屏，而是能跑通、能调参、能上线的轻量级数据产品闭环

你手头有一份「网易云音乐可视化（Python）-Django大屏-用户画像+播放行为分析.zip」——它不是某个开源项目仓库的镜像，也不是某次课程作业的压缩包，而是一套面向真实中小团队、无Hadoop/Spark基建、仅靠单机Python+Django+SQLite/MySQL就能落地的用户行为分析最小可行系统。它解决的不是“怎么画酷炫图表”，而是“如何从原始日志或模拟数据出发，完成清洗→建模→存储→服务→渲染的全链路闭环”。核心价值在于：用户画像标签可解释、播放行为路径可回溯、大屏指标可下钻、所有代码本地可调试、部署只需python manage.py runserver加一个Nginx反代。适合刚做完《Python数据分析与可视化实践》想进阶实战的工程师，也适合需要快速交付内部运营看板的产品经理。它不依赖Redis可视化客户端、不绑定onenet可视化平台、不强求ECharts数据可视化必须用Vue封装——所有前端图表用原生ECharts 5.x + Django模板直出，后端逻辑全部在views.py和models.py里，连requirements.txt都只列了8个必要包。下面，我们就从解压那一刻开始，把它真正跑起来、调明白、用得稳。

2. 从解压到首屏：用Django搭起可视化服务骨架，避开新手最常卡住的3个环境坑

2.1 解压即启动：确认项目结构与最小依赖清单

拿到.zip文件后，先别急着pip install -r requirements.txt。打开压缩包，你会看到典型Django项目结构：

netease-visual/ ├── manage.py ├── requirements.txt ├── netease_visual/ # 项目配置目录（含settings.py） │ ├── __init__.py │ ├── settings.py │ ├── urls.py │ └── wsgi.py ├── user_analysis/ # 核心App：用户画像+行为分析 │ ├── __init__.py │ ├── admin.py │ ├── apps.py │ ├── models.py │ ├── views.py │ └── migrations/ ├── static/ # 前端资源（CSS/JS/ECharts） │ └── js/ │ └── dashboard.js # ECharts初始化脚本 ├── templates/ # Django模板（含index.html大屏主页面） │ └── index.html └── data/ # 示例数据（CSV格式，非数据库dump） └── user_behavior.csv

提示：这个项目不带数据库dump文件（.sql），也不要求你提前装好PostgreSQL。它默认使用SQLite——这意味着你不需要额外配数据库服务，python manage.py migrate就能建表。但务必注意：data/目录下的CSV是模拟数据，不是网易云真实API导出，不可用于商业用途，仅作分析逻辑验证。

requirements.txt内容极简（实测共8行）：

Django==4.2.7 pandas==2.1.3 numpy==1.26.0 matplotlib==3.8.0 seaborn==0.12.2 openpyxl==3.1.2 PyMySQL==1.1.0 # 若切换MySQL时启用 django-extensions==3.3.9 # 仅用于`runscript`调试

为什么选这些版本？

• Django 4.2.7 是LTS长期支持版，兼容Python 3.8–3.11，避免Django 5.x中asgi.py变更带来的部署混乱；
• pandas 2.1.3 与numpy 1.26.0 组合稳定，避开pandas 2.2+对datetime64[ns]时区处理的breaking change；
• PyMySQL仅当你要切MySQL时才需安装（见2.3节），SQLite无需额外驱动。

2.2 本地启动：三步跑通Django服务，验证基础路由

第一步：创建虚拟环境并安装依赖

# 推荐使用venv（不用conda，避免包冲突） python -m venv venv_netease source venv_netease/bin/activate # Linux/Mac # venv_netease\Scripts\activate.bat # Windows pip install --upgrade pip pip install -r requirements.txt

第二步：执行迁移并创建超级用户

cd netease-visual python manage.py migrate python manage.py createsuperuser # 按提示输入用户名、邮箱、密码（记住！后面登录后台要用）

第三步：加载示例数据并启动服务

# 这一步关键：运行内置数据加载脚本（非Django默认命令） python manage.py runscript load_sample_data # 启动开发服务器 python manage.py runserver 8000

此时访问http://127.0.0.1:8000/应看到空白大屏（因尚未生成图表数据），访问http://127.0.0.1:8000/admin/可用刚才创建的账号登录，进入Django Admin后台——你会看到UserProfile、PlayRecord、BehaviorSession三个模型已注册，说明数据库表已建好，模型关联正确。

参数说明：runscript load_sample_data调用的是user_analysis/management/commands/load_sample_data.py，该脚本读取data/user_behavior.csv，用pandas.read_csv()解析后批量写入数据库。它自动处理时间字段转换（如play_time转为datetime）、去重（按user_id+song_id+play_time组合唯一）、并生成基础画像标签（如is_vip,active_level）。这是整个分析链路的数据入口锚点，后续所有统计都基于此。

2.3 切换MySQL：当数据量超5万条时，如何平滑替换SQLite

SQLite适合演示和小规模测试（<10万行），但真实场景中播放行为日志极易突破此限。切换MySQL只需4处修改，无需重写任何业务逻辑：

1. 修改netease_visual/settings.py中的DATABASES配置：

# 注释掉原来的SQLite配置 # DATABASES = { # 'default': { # 'ENGINE': 'django.db.backends.sqlite3', # 'NAME': BASE_DIR / 'db.sqlite3', # } # } # 替换为MySQL配置（确保MySQL服务已运行） DATABASES = { 'default': { 'ENGINE': 'django.db.backends.mysql', 'NAME': 'netease_visual_db', 'USER': 'your_mysql_user', 'PASSWORD': 'your_password', 'HOST': '127.0.0.1', 'PORT': '3306', 'OPTIONS': { 'charset': 'utf8mb4', 'init_command': "SET sql_mode='STRICT_TRANS_TABLES'", }, } }

2. 安装PyMySQL（Django MySQL驱动）：

pip install PyMySQL

3. 创建MySQL数据库（UTF8MB4编码）：

CREATE DATABASE netease_visual_db CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;

4. 重新迁移并加载数据：

python manage.py migrate python manage.py runscript load_sample_data

关键细节：'charset': 'utf8mb4'和'init_command'必须设置，否则中文标签（如“粤语歌偏好”）存入时会报错Incorrect string value；migrate命令会自动在MySQL中重建所有表，字段类型与SQLite完全一致（Django ORM层屏蔽了差异）。

3. 用户画像构建：从原始行为日志到可解释标签，用Pandas做特征工程而非黑匣子模型

3.1 标签体系设计：为什么只做5类基础标签，而不是100维Embedding

本项目用户画像不追求“AI感”，而是聚焦运营可理解、产品可干预、技术可追溯的5类标签：

为什么不用机器学习？
因为真实中小团队没有标注数据、没有AB测试闭环、没有实时特征管道。这5类标签全部基于确定性规则+统计阈值，例如genre_preference计算方式：

# 在load_sample_data.py中实际代码 genre_counts = df.groupby(['user_id', 'genre']).size().unstack(fill_value=0) # 对每个user_id取TOP3列名（即流派名） top3_genres = genre_counts.apply(lambda x: x.nlargest(3).index.tolist(), axis=1)

这种做法牺牲了“精度”，但换来100%可复现、可审计、可人工修正——运营人员发现某用户被标为“古风偏好”但实际听摇滚，可直接查PlayRecord表中该用户的song_id对应歌曲元数据，立刻定位是歌曲分类错误，而非模型不可解释。

3.2 特征计算：用Django ORM + Pandas混合编程，平衡性能与可读性

画像标签不是一次性计算，而是随新数据写入动态更新。项目采用双触发机制：

• 批量更新：每日凌晨2点执行python manage.py runscript update_user_profiles，全量重算所有用户标签；
• 实时更新：当新PlayRecord写入时，通过Django信号（post_save）触发update_user_profile_on_play()，仅更新该用户画像。

以active_level为例，其计算逻辑在user_analysis/models.py中定义为模型方法：

# user_analysis/models.py from django.db import models from django.utils import timezone from datetime import timedelta class UserProfile(models.Model): user_id = models.CharField(max_length=32, unique=True) # ... 其他字段 def calculate_active_level(self): """计算近30天活跃等级""" cutoff = timezone.now() - timedelta(days=30) login_days = self.playrecord_set.filter( play_time__gte=cutoff ).dates('play_time', 'day').count() # 注意：用dates()避免重复计数 if login_days >= 20: return 'high' elif login_days >= 10: return 'medium' else: return 'low'

而批量更新脚本update_user_profiles.py则用Pandas加速：

# user_analysis/management/commands/update_user_profiles.py import pandas as pd from django.core.management.base import BaseCommand from user_analysis.models import PlayRecord, UserProfile def update_batch(): # 直接SQL查询比ORM遍历快10倍（5万用户时从120s→12s） df = pd.read_sql(""" SELECT user_id, COUNT(DISTINCT DATE(play_time)) as login_days FROM user_analysis_playrecord WHERE play_time >= DATE_SUB(NOW(), INTERVAL 30 DAY) GROUP BY user_id """, con=connection) for _, row in df.iterrows(): profile, _ = UserProfile.objects.get_or_create(user_id=row['user_id']) profile.active_level = 'high' if row['login_days'] >= 20 else \ 'medium' if row['login_days'] >= 10 else 'low' profile.save()

参数说明：COUNT(DISTINCT DATE(play_time))是关键——它统计的是“登录天数”，而非“播放次数”，避免用户单日狂刷100首歌被误判为高活。DATE(play_time)在MySQL中提取日期部分，比Python端datetime.date()转换快得多。

3.3 标签验证：用Django Admin自定义列表页，让运营人员也能看懂画像

单纯在数据库里存active_level='high'毫无意义。项目在Admin中做了三层增强：

1. 字段展示优化：在admin.py中重写list_display：

@admin.register(UserProfile) class UserProfileAdmin(admin.ModelAdmin): list_display = ['user_id', 'active_level', 'genre_preference', 'device_type', 'last_updated'] list_filter = ['active_level', 'device_type', 'is_vip'] # 右侧筛选栏 search_fields = ['user_id', 'genre_preference'] # 顶部搜索框

2. 详情页嵌入行为图谱：在UserProfileAdmin.change_view中注入播放热力图：

def change_view(self, request, object_id, form_url='', extra_context=None): extra_context = extra_context or {} profile = self.get_object(request, object_id) # 查询该用户近7天播放时段分布（小时粒度） heatmap_data = PlayRecord.objects.filter( user_id=profile.user_id, play_time__gte=timezone.now() - timedelta(days=7) ).extra( select={'hour': 'HOUR(play_time)'} ).values('hour').annotate(count=Count('id')).order_by('hour') extra_context['heatmap_data'] = list(heatmap_data) return super().change_view(request, object_id, form_url, extra_context)

3. 模板中渲染热力图（templates/admin/user_analysis/userprofile/change_form.html）：

<!-- 使用原生HTML+CSS，不依赖第三方库 --> <div class="heatmap"> <h3>近7天播放时段热力图（小时）</h3> {% for h in heatmap_data %} <span style="background:#{{ h.count|floatformat:0|add:'00' }}; width:30px; display:inline-block; text-align:center;"> {{ h.hour }} </span> {% endfor %} </div>

效果：运营人员在Admin后台点开任意用户，不仅看到标签值，还能直观看到“该用户总在22–24点听歌”，从而判断listen_scene='深夜'标签是否合理。这才是可信任的用户画像。

4. 播放行为分析：从单点点击到路径挖掘，用SQL窗口函数替代复杂图算法

4.1 行为事件定义：为什么只追踪3类核心事件，而非埋点全量上报

项目将播放行为抽象为3个原子事件，全部来自PlayRecord模型：

为什么不做“点赞”、“分享”、“评论”？
因为网易云公开API不提供这些行为数据，而本项目定位是基于可获取数据的最小闭环。强行虚构会导致分析结论失真。所有事件字段均在models.py中设为null=True，允许缺失——这比硬编码默认值更符合真实数据质量。

4.2 路径分析：用Django ORM实现会话切割与漏斗归因

用户行为不是离散点击，而是有上下文的会话（Session）。项目用服务端会话切割替代前端埋点：

# user_analysis/utils.py from django.utils import timezone from datetime import timedelta def get_or_create_session(user_id, current_time, timeout_minutes=30): """根据时间间隔切割用户会话""" cutoff = current_time - timedelta(minutes=timeout_minutes) last_record = PlayRecord.objects.filter( user_id=user_id, play_time__lt=current_time, play_time__gte=cutoff ).order_by('-play_time').first() if not last_record: # 新会话 session = BehaviorSession.objects.create( user_id=user_id, start_time=current_time, end_time=current_time ) else: # 延续会话 session = BehaviorSession.objects.get( user_id=user_id, end_time__gte=cutoff, start_time__lte=current_time ) session.end_time = current_time session.save() return session

然后在PlayRecord.save()中调用：

def save(self, *args, **kwargs): if not self.session_id: session = get_or_create_session(self.user_id, self.play_time) self.session_id = session.id super().save(*args, **kwargs)

这样，每条播放记录自动归属到一个BehaviorSession，后续分析即可基于会话聚合：

• 会话时长分布：SELECT AVG(TIMESTAMPDIFF(MINUTE, start_time, end_time)) FROM behavior_session;
• 会话内平均播放数：SELECT AVG(song_count) FROM (SELECT session_id, COUNT(*) as song_count FROM playrecord GROUP BY session_id) t;
• 跳出率：SELECT COUNT(*) FILTER (WHERE song_count = 1) * 100.0 / COUNT(*) FROM (...) t;

避坑点：TIMESTAMPDIFF(MINUTE,...)在MySQL中比DATEDIFF更精确（后者只算天数），且避免了Django ORM对时间差计算的序列化开销。

4.3 漏斗转化：用Raw SQL实现跨事件归因，绕过Django ORM的JOIN限制

要分析“搜索→播放→加入歌单”路径，需关联3张表。Django ORM的select_related在多表JOIN时性能骤降。项目直接用Raw SQL：

# user_analysis/views.py from django.db import connection def funnel_analysis(request): with connection.cursor() as cursor: cursor.execute(""" WITH search_events AS ( SELECT user_id, search_keyword, play_time as search_time FROM user_analysis_playrecord WHERE search_keyword IS NOT NULL AND search_keyword != '' ), play_events AS ( SELECT user_id, song_id, play_time as play_time FROM user_analysis_playrecord WHERE play_duration > 30 ), playlist_events AS ( SELECT user_id, playlist_id, play_time as add_time FROM user_analysis_playrecord WHERE playlist_id IS NOT NULL ) SELECT COUNT(DISTINCT s.user_id) as search_users, COUNT(DISTINCT p.user_id) as play_users, COUNT(DISTINCT pl.user_id) as playlist_users, ROUND(COUNT(DISTINCT p.user_id) * 100.0 / COUNT(DISTINCT s.user_id), 2) as search_to_play_rate, ROUND(COUNT(DISTINCT pl.user_id) * 100.0 / COUNT(DISTINCT p.user_id), 2) as play_to_playlist_rate FROM search_events s LEFT JOIN play_events p ON s.user_id = p.user_id AND p.play_time BETWEEN s.search_time AND DATE_ADD(s.search_time, INTERVAL 1 HOUR) LEFT JOIN playlist_events pl ON p.user_id = pl.user_id AND pl.add_time BETWEEN p.play_time AND DATE_ADD(p.play_time, INTERVAL 30 MINUTE) """) result = cursor.fetchone() context = { 'search_users': result[0], 'play_users': result[1], 'playlist_users': result[2], 'search_to_play_rate': result[3], 'play_to_playlist_rate': result[4], } return render(request, 'funnel.html', context)

参数说明：INTERVAL 1 HOUR定义搜索后1小时内播放为有效转化，INTERVAL 30 MINUTE定义播放后30分钟内加歌单为有效转化——这两个阈值可根据业务实际调整，不是固定魔法数字。

5. 可视化大屏：ECharts直连Django API，拒绝打包构建，保持热重载能力

5.1 数据接口设计：用Django Class-Based View暴露JSON，不走REST Framework

大屏不需要CRUD，只需只读聚合。项目用最简View类，避免引入DRF增加复杂度：

# user_analysis/views.py from django.http import JsonResponse from django.views import View from django.db import connection class DashboardDataView(View): def get(self, request): # 所有指标在一个接口返回，减少HTTP请求数 with connection.cursor() as cursor: # 总用户数 cursor.execute("SELECT COUNT(*) FROM user_analysis_userprofile") total_users = cursor.fetchone()[0] # 实时在线数（近5分钟播放记录去重） cursor.execute(""" SELECT COUNT(DISTINCT user_id) FROM user_analysis_playrecord WHERE play_time >= DATE_SUB(NOW(), INTERVAL 5 MINUTE) """) online_users = cursor.fetchone()[0] # 流派分布（TOP5） cursor.execute(""" SELECT genre, COUNT(*) as cnt FROM user_analysis_playrecord WHERE genre IS NOT NULL GROUP BY genre ORDER BY cnt DESC LIMIT 5 """) genre_data = [{'name': r[0], 'value': r[1]} for r in cursor.fetchall()] return JsonResponse({ 'total_users': total_users, 'online_users': online_users, 'genre_distribution': genre_data, })

对应URL路由（urls.py）：

from django.urls import path from user_analysis.views import DashboardDataView urlpatterns = [ path('api/dashboard/', DashboardDataView.as_view(), name='dashboard_api'), # ... 其他路由 ]

为什么不用DRF？
因为DRF的Serializer、ViewSet、Router对简单聚合接口是过度设计。JsonResponse直接返回字典，无序列化开销，View类逻辑清晰，便于调试——当你发现genre_distribution数据为空时，可直接在DashboardDataView.get()中打断点，一行行看SQL执行结果。

5.2 ECharts初始化：在Django模板中内联JavaScript，规避Webpack构建陷阱

templates/index.html中直接写ECharts初始化代码，不拆分JS文件：

<!-- templates/index.html --> <!DOCTYPE html> <html> <head> <title>网易云音乐分析大屏</title> <script src="https://cdn.jsdelivr.net/npm/echarts@5.4.3/dist/echarts.min.js"></script> </head> <body> <div id="main" style="width: 100vw; height: 100vh;"></div> <script type="text/javascript"> // 初始化ECharts实例 const chartDom = document.getElementById('main'); const myChart = echarts.init(chartDom); // 获取数据并渲染 fetch('/api/dashboard/') .then(response => response.json()) .then(data => { // 渲染总用户数卡片 document.querySelector('.total-users').innerText = data.total_users; // 渲染在线用户数卡片 document.querySelector('.online-users').innerText = data.online_users; // 渲染流派饼图 const option = { tooltip: { trigger: 'item' }, series: [{ name: '流派分布', type: 'pie', radius: ['40%', '70%'], data: data.genre_distribution, emphasis: { itemStyle: { shadowBlur: 10, shadowOffsetX: 0, shadowColor: 'rgba(0, 0, 0, 0.5)' } } }] }; myChart.setOption(option); }); </script> </body> </html>

优势：修改图表配置（如把饼图改成环形图）只需改模板中的option对象，保存即生效，无需npm run build、无需配置webpack-dev-server、无需处理静态文件收集问题。这对快速迭代至关重要。

5.3 大屏适配：用CSS Grid+Viewport单位实现响应式，不依赖Bootstrap栅格

大屏常需适配不同分辨率（1920×1080、2560×1440、甚至LED拼接屏）。项目用纯CSS方案：

/* static/css/dashboard.css */ body, html { margin: 0; padding: 0; height: 100%; overflow: hidden; } .grid-container { display: grid; grid-template-areas: "header header header" "card1 card2 card3" "chart chart chart"; grid-template-rows: 10vh 20vh 70vh; grid-template-columns: 1fr 1fr 1fr; height: 100vh; } .total-users, .online-users, .genre-pie { grid-area: card1; /* 占据左上角 */ } /* 在index.html中应用 */ <div class="grid-container"> <div class="header">网易云音乐用户分析大屏</div> <div class="total-users">总用户：<span>0</span></div> <div class="online-users">实时在线：<span>0</span></div> <div id="main" class="genre-pie"></div> </div>

关键技巧：grid-template-rows: 10vh 20vh 70vh用视口单位（vh）而非像素，确保在任意分辨率下比例不变；overflow: hidden防止滚动条破坏大屏沉浸感；所有字体大小用rem，根元素font-size设为16px，保证缩放一致性。

6. 部署与调优：从开发机到生产环境，用Nginx+Gunicorn跑通最后一公里

6.1 生产部署：Gunicorn配置要点与Nginx反向代理模板

开发模式runserver不能用于生产。项目用Gunicorn作为WSGI服务器，Nginx作反向代理：

Gunicorn启动命令（gunicorn.conf.py）：

# gunicorn.conf.py import multiprocessing bind = "127.0.0.1:8001" # Gunicorn监听端口 bind_address = "127.0.0.1:8001" workers = multiprocessing.cpu_count() * 2 + 1 # 通常4核CPU配9个worker worker_class = "sync" worker_connections = 1000 timeout = 30 keepalive = 2 max_requests = 1000 max_requests_jitter = 100 # 日志 accesslog = "/var/log/netease/access.log" errorlog = "/var/log/netease/error.log" loglevel = "info" capture_output = True pidfile = "/var/run/netease/gunicorn.pid"

启动命令：

gunicorn --config gunicorn.conf.py netease_visual.wsgi:application

Nginx配置（/etc/nginx/sites-available/netease）：

upstream netease_backend { server 127.0.0.1:8001; } server { listen 80; server_name your-domain.com; location / { proxy_pass http://netease_backend; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; } # 静态文件由Nginx直接服务（提升性能） location /static/ { alias /path/to/netease-visual/static/; expires 1h; add_header Cache-Control "public, immutable"; } # 媒体文件（如有） location /media/ { alias /path/to/netease-visual/media/; } }

血泪经验：proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;必须设置，否则Django的request.META.get('REMOTE_ADDR')会显示为127.0.0.1，导致IP统计失效；expires 1h对静态资源启用缓存，避免每次刷新都请求JS/CSS。

6.2 性能瓶颈排查：当大屏加载慢于3秒时，按此顺序检查

大屏卡顿90%源于后端数据查询，而非前端渲染。按优先级排查：

1. 检查SQL执行计划：
   在Django shell中执行慢查询，用EXPLAIN分析：

   from django.db import connection cursor = connection.cursor() cursor.execute("EXPLAIN SELECT ...") # 替换你的慢SQL print(cursor.fetchall())

   关键看type列：ALL表示全表扫描（需加索引），range表示范围查询（可接受），const表示主键查询（最优）。

2. 为高频查询字段加索引：
   在models.py中为PlayRecord添加：

   class PlayRecord(models.Model): # ... 字段定义 class Meta: indexes = [ models.Index(fields=['user_id', 'play_time']), # 会话切割常用 models.Index(fields=['genre']), # 流派统计常用 models.Index(fields=['search_keyword']), # 搜索分析常用 ]

   然后执行python manage.py makemigrations && python manage.py migrate。

3. 启用Django Debug Toolbar（仅开发环境）：
   在settings.py中加入：

   INSTALLED_APPS += ['debug_toolbar'] MIDDLEWARE += ['debug_toolbar.middleware.DebugToolbarMiddleware'] INTERNAL_IPS = ['127.0.0.1']

   访问/__debug__/即可看到每个请求的SQL查询数、耗时、重复查询警告。

翻车现场：曾有团队在genre_preference计算中未加genre索引，5万用户时单次update_user_profiles耗时217秒。加索引后降至8.3秒——索引不是玄学，是确定性优化。

6.3 数据安全加固：3个必须做的最小权限配置

即使内部系统，也需基础防护：

1. Django Admin登录强制HTTPS（settings.py）：

   SESSION_COOKIE_SECURE = True CSRF_COOKIE_SECURE = True SECURE_SSL_REDIRECT = True # 仅当Nginx已配HTTPS时启用

2. 数据库用户权限最小化：
   MySQL中创建专用用户：

   CREATE USER 'netease_app'@'localhost' IDENTIFIED BY 'strong_password'; GRANT SELECT, INSERT, UPDATE ON netease_visual_db.* TO 'netease_app'@'localhost'; -- 禁止DROP、GRANT、FILE等高危权限 FLUSH PRIVILEGES;

3. 敏感信息环境变量化：
   settings.py中替换硬编码：

   import os SECRET_KEY = os.environ.get('DJANGO_SECRET_KEY', 'dev-key-change-in-prod') DEBUG = os.environ.get('DEBUG', 'False') == 'True' ALLOWED_HOSTS = os.environ.get('ALLOWED_HOSTS', 'localhost').split(',')

然后在生产环境启动前：

export DJANGO_SECRET_KEY="your-32-char-random-string" export DEBUG=False export ALLOWED_HOSTS="your-domain.com,123.45.67.89" gunicorn --config gunicorn.conf.py netease_visual.wsgi:application

后悔药：SECRET_KEY一旦泄露，所有session cookie可被伪造。生产环境必须用openssl rand -base64 32生成，并存入环境变量，绝不可提交到Git。

我带过的3个团队，有2个在首次上线时因DEBUG=True暴露了完整报错堆栈（含数据库密码），1个因ALLOWED_HOSTS=['*']被扫描器利用。这些不是“理论上可能”，而是真实踩过的坑。现在我的习惯是：每次git push前，用grep -r "DEBUG.*=.*True" .和grep -r "ALLOWED_HOSTS.*\[\*\]" .扫一遍——这句命令，就是我给自己写的后悔药。希望帮到你。

本文还有配套的精品资源，点击获取