Django框架自带的安全机制在默认配置下已经能拦截大量常见攻击，但真实生产环境中，漏洞往往不是出在框架本身，而是出在配置不当、第三方包缺陷、业务逻辑疏漏和部署层暴露。要真正做好Django站点的防护与性能优化，必须从默认安全机制的边界开始，逐层排查那些容易被忽略但攻击者最常利用的点。

关闭DEBUG与自定义错误页面是第一步

DEBUG=True在生产环境是灾难性的。一旦触发异常，Django会返回完整的traceback、局部变量、settings配置、已安装的中间件列表甚至数据库连接信息。攻击者利用一个故意构造的非法URL或参数就能获取大量内部情报。生产环境必须设置DEBUG=False，同时配置ALLOWED_HOSTS为实际域名，不要使用通配符“*”。错误页面要自定义，用handler404和handler500返回不含技术细节的静态页面，避免默认错误页暴露框架版本和路径结构。

SECRET_KEY管理常被低估

SECRET_KEY用于签名session、CSRF token、密码重置链接等。一旦泄露，攻击者可以伪造session直接以任意用户身份登录。不要把SECRET_KEY硬编码在settings.py然后提交到代码仓库。正确做法是从环境变量或专用密钥管理服务读取。定期轮换SECRET_KEY会使所有已登录用户的session失效，这在怀疑泄露时是必要的应急手段。另外，不要把SECRET_KEY放在前端代码、日志输出或错误报告里。

CSRF防护的边界与AJAX场景

Django的CsrfViewMiddleware默认对POST、PUT、DELETE等不安全方法生效。但很多开发者在用AJAX提交数据时图省事直接使用csrf_exempt装饰器，这等于在这个视图上完全关闭CSRF防护。正确做法是在前端请求头中携带X-CSRFToken，Django会自动从cookie中读取csrftoken并与请求头比对。如果使用前后端分离架构，确保CSRF cookie的SameSite属性设置为Lax或Strict，并考虑使用双提交token模式。对于公开的只读API，可以保持GET方法不受CSRF影响，但任何改变状态的操作都必须校验。

SQL注入的残余风险在原生查询

Django ORM的filter、exclude、get等方法会自动转义参数，基本杜绝了SQL注入。但一旦使用raw()、extra()或者直接通过cursor.execute拼接SQL字符串，风险立即回归。尤其是extra()中传入用户可控的where条件片段，等于把数据库大门打开。审查代码时重点搜索raw、extra、RawSQL和connection.cursor的使用位置。如果必须用原生SQL，所有参数一律通过参数化占位符传递，绝不做字符串拼接。对于需要动态排序或动态字段名的场景，用白名单映射而不是直接接收前端传来的字段名。

XSS防护要关注富文本与模板过滤

Django模板默认自动转义变量输出，这是很强的XSS防线。但两个地方会破坏它：使用mark_safe或safe过滤器，以及通过|safe输出用户内容。富文本编辑器是重灾区，用户提交的HTML如果直接safe输出，等于允许任意脚本执行。解决方案是使用bleach等库做白名单标签过滤，只允许p、br、strong、em、a等安全标签，并强制a标签的href只允许http、https和相对路径。对于JSON数据嵌入script标签的场景，要使用json_script过滤器而不是直接拼接，防止</script>提前闭合。

文件上传漏洞不止是扩展名检查

只检查文件扩展名完全不够，攻击者可以把PHP、JSP或可执行脚本改名为.jpg上传，再通过路径遍历或解析漏洞触发。Django的ImageField会校验图片文件头，但普通FileField不做内容检查。必须结合文件MIME类型、文件头魔数和扩展名三重校验。上传目录要放在Web服务器无法直接执行脚本的位置，或者通过X-Sendfile等机制由后端控制下载。文件名不要直接使用用户提供的名称，用uuid或hash重命名，避免路径穿越和特殊字符问题。对于图片上传，可以用Pillow重新编码图片，彻底剥离可能嵌入的恶意代码。

会话安全与Cookie属性

SESSION_COOKIE_SECURE必须设为True，强制session cookie只在HTTPS下传输。SESSION_COOKIE_HTTPONLY设为True防止JavaScript读取sessionid，降低XSS窃取会话的风险。CSRF_COOKIE_SECURE同样要开启。SESSION_EXPIRE_AT_BROWSER_CLOSE根据业务需求决定是否在浏览器关闭时失效。对于敏感操作，比如修改密码、绑定邮箱、转账确认，应该使用django.contrib.auth的update_session_auth_hash和独立的权限校验，必要时引入二次验证。SESSION_COOKIE_SAMESITE建议设为Lax，既保留基本的CSRF防护，又不影响正常的站内跳转。

点击劫持与安全响应头

Django的XFrameOptionsMiddleware默认设置X-Frame-Options为DENY，防止站点被嵌入iframe。但很多项目在集成第三方支付或地图组件时，会把这个中间件移除或改为SAMEORIGIN。如果业务确实需要允许特定域名嵌入，用CSP的frame-ancestors指令做精确控制，而不是全局放开。其他安全响应头需要手动添加：X-Content-Type-Options: nosniff防止MIME嗅探，Referrer-Policy控制来源泄露，Permissions-Policy限制浏览器特性滥用。可以在中间件中统一设置这些头，避免在每个视图重复添加。

第三方包供应链风险

Django生态的第三方包质量参差不齐。安装前检查包的维护状态、最近更新时间、issue数量和已知CVE。requirements.txt中不要使用未固定版本的范围写法，必须精确到版本号，防止某天拉取到带漏洞的新版本。定期使用pip-audit或safety检查依赖漏洞。特别关注那些涉及认证、支付、文件处理、模板渲染的包，它们一旦有漏洞影响面极大。对于不再维护的包，要么寻找替代品，要么fork后自行修复并维护。

数据库层优化从查询数量开始

Django性能问题最常见的原因是N+1查询。在模板或循环中访问外键和反向关联时，每个对象都会触发一次额外查询。用select_related处理一对一和多对一外键，用prefetch_related处理多对多和反向关联。但不要无脑加prefetch_related，如果关联数据量巨大，预取本身会成为内存负担。使用django-debug-toolbar的SQL面板观察单次请求的查询数量和耗时，把查询数从几十降到个位数。对于列表页，用only()和defer()限制查询字段，避免拉取不需要的大字段。

索引设计与慢查询定位

数据库索引不是越多越好，每个索引都会拖慢写入速度并占用磁盘。分析实际业务查询模式，为高频过滤、排序、关联的字段建立组合索引。Django的Meta.indexes可以定义复合索引，db_index=True只适用于单字段。对于已经上线的项目，开启数据库的慢查询日志，找到执行时间超过阈值的SQL，用EXPLAIN分析执行计划。注意避免在低区分度字段上建索引，比如性别、状态等只有几个值的字段，索引效果很差。对于大表，考虑使用分区表或归档历史数据。

缓存策略要分层设计

整页缓存适合变化不频繁的公开页面，比如文章详情、产品介绍。用cache_page装饰器或模板缓存标签，设置合理的过期时间。对于用户相关的动态内容，使用模板片段缓存只缓存公共部分，用户信息部分保持动态。Django的缓存框架支持多种后端，Redis比Memcached功能更强，可以同时承担缓存、session存储和队列。注意缓存穿透问题，对于不存在的ID，也缓存一个空值并设置较短过期时间。缓存键的设计要包含版本号，方便在数据模型变更时批量失效。

静态文件与媒体文件分离

生产环境不要让Django处理静态文件，这不是它的强项。用collectstatic把静态文件收集到指定目录，交给Nginx直接服务。媒体文件同样由Nginx或对象存储处理，Django只负责生成URL。对于用户上传的图片，考虑使用CDN加速，并在上传时生成缩略图，避免前端加载原图造成带宽浪费。静态文件设置长缓存时间，配合文件名hash实现更新时自动失效。Nginx层开启gzip或brotli压缩，对CSS、JS、HTML等文本文件压缩率可达70%以上。

异步任务与耗时操作解耦

发送邮件、生成报表、图片处理、调用第三方API这些耗时操作不应该阻塞请求。用Celery或Django-Q把这类任务放到后台队列执行。Celery需要配置broker和result backend，Redis是常见选择。任务设计要幂等，因为队列可能重复投递。对于实时性要求不高的场景，可以用django-background-tasks这种轻量方案。注意Celery worker的并发数和内存占用，避免worker本身成为性能瓶颈。定时任务用Celery Beat或django-crontab管理，不要用Django请求触发定时逻辑。

日志与监控是防护的最后一道防线

很多攻击在造成实际损失前会在日志中留下痕迹。配置Django的LOGGING，把WARNING以上级别的日志输出到文件或集中日志平台。记录登录失败、权限拒绝、异常堆栈、关键操作审计。对于安全事件，比如频繁的404扫描、异常的参数模式、短时间内大量请求，设置告警规则。使用Sentry等错误追踪工具收集生产异常，第一时间发现被攻击的迹象。监控指标包括请求响应时间、错误率、数据库连接数、缓存命中率、队列积压量。没有监控的优化是盲目的，没有日志的防护是脆弱的。

定期安全审计与依赖更新

Django官方会定期发布安全更新，关注Django项目的安全公告邮件列表，在漏洞披露后尽快升级。升级前在测试环境验证兼容性，特别是自定义中间件和第三方包。每半年做一次代码安全审计，重点检查权限控制、输入校验、文件操作和敏感数据存储。使用bandit等静态分析工具扫描Python代码中的安全问题。对管理员后台路径进行修改，不要使用默认的/admin/，并限制访问IP或增加额外认证层。管理后台的权限要最小化，普通编辑不要授予删除和用户管理权限。

Django的防护与优化不是一次性工作，而是持续的过程。框架提供的安全机制是底线，真正的安全来自对每个业务细节的审视和对攻击面的持续收敛。性能优化同样如此，从数据库查询到缓存设计，从静态资源到异步任务，每个环节的改进都会累积成显著的体验提升。把安全意识和性能意识融入日常开发流程，比事后补救有效得多。