这个项目解决什么问题
N+1 查询、无索引过滤、全表加载这类性能问题有个共同特点:不报错、不打日志,只有访问量上来之后才以"CPU 100%"的形式暴露,而且很难说清到底慢在哪。本项目不是讲理论,而是把完整证据链搭出来:一个故意埋了四类典型性能问题的"论坛"(问题版),一个逐项修复的对照版(优化版),再加上自研的采集中间件与诊断引擎——问题在哪一行、为什么慢、怎么修、修完快多少,全部落在数据和报告里。
核心亮点
- 问题版 / 优化版同框对比:两个路由渲染同一个模板,功能完全一致,只有查询方式不同。页面底部实时显示 SQL 查询数与耗时,SQL 次数从"随帖子数线性增长"降到个位数,数字即证据。
- 纯自研 AST 诊断规则引擎(核心创新):用 Python 标准库
ast扫描视图源码,内置循环内查询(N+1 嫌疑)、未预取的外键访问、无 limit 的all()三条静态规则,再结合采集表的慢请求/慢查询数据做动态印证——不依赖任何外部 SaaS,每条结论都带问题位置、严重级别、推断原因和修复建议代码。 - 自写采集中间件:通过
force_debug_cursor捕获每个请求的 SQL(不依赖 DEBUG 开关),慢查询(>100ms)连同耗时一起写入 SQLite,面板与诊断引擎都吃这份数据。 - 一份数据,多处可用:ECharts 监控面板(AJAX 自动刷新)、可导出的 Markdown 诊断报告、简版 Prometheus
/metrics端点、进程内基准压测对比表——Prometheus/Grafana 可接可不接,平台自身独立可用。
效果预览
监控面板的请求耗时趋势,问题版长期在告警线附近,优化版稳定在几十毫秒:

自动诊断报告(静态扫描 R1-R3 + 动态指标 D1-D2),定位到 forum/views.py 的具体行号并给出修复片段:

预览图基于 init_data 模拟指标与演示代码的实际扫描结果排版,实际运行效果以平台页面为准。
你将学到
- Django 性能问题的标准成因与修法:
select_related/prefetch_related/annotate/ LIMIT / 索引,以及它们为什么有效 - 用一个中间件完成请求级性能采集(耗时、SQL 次数、慢查询落库)
- 用标准库
ast写静态分析规则:安全地遍历语法树、定位可疑模式、生成可解释的报告 - 简版 Prometheus 文本格式的写法,以及 Grafana 面板的常用查询
适合谁
需要完成 Web 方向毕业设计、或想系统搞懂"Django 到底慢在哪"的学习者。难度 ★★★,代码注释齐全,四类性能问题都是真实生产环境的常见形态,不是造出来给人看的。
交付内容:完整可运行源码、README.md(逐步运行方法与实现说明)、requirements.txt。
许可:个人使用,可用于自己的学习、课程实验与研究报告,请勿转售或公开传播。