2026 年 6 月，Django Software Foundation 将 Salim Nuru 选为本月成员。这不是一个单纯的社区人物介绍：他的经历把几条开发者常见路径串在了一起——从临时接下 Django 项目开始学习，到参与 Djangonaut Space，再到组织 DjangoCon Africa、负责 DjangoCon US 网站团队，并把安全研究和本地 LLM 带进自己的项目。
一周学 Django：框架的入口要足够低，天花板要足够高
Salim 最早在大学期间接触 Django。当时他主要用 .NET 和 JavaScript 做自由职业项目，但遇到一个明确要求 Django 的大项目。机会不能错过，于是他用一周时间密集学习。
这段经历说明了 Django 长期受欢迎的一个原因：它不是只给“框架专家”准备的。模型、路由、模板、管理后台、认证、安全默认值这些能力被组织在一个完整体系里，新手可以快速落地，老手也能继续深入。
他最喜欢 Django 的三点是：社区、安全默认值和 admin 管理后台。这三个点很实际：
- 社区让新贡献者更容易留下来，而不是只提交一次 PR。
- 安全默认值降低了常见 Web 风险的暴露面。
- admin 后台让很多内部系统和运营工具可以更快起步。
安全研究者眼里的 Django：默认安全不是“永远安全”
Salim 白天是软件工程师，晚上做安全研究。他提到自己正在复现 Django 过去出现过的 CVE，用这种方式理解漏洞成因，并期待未来能在 Django 安全方向做出贡献。
这点值得开发团队借鉴：不要把“Django security by default”理解成可以忽略安全工程。框架帮你处理了很多底层问题，例如 CSRF、防点击劫持、密码哈希、SQL 注入防护等，但业务配置、部署环境、第三方包和 API 权限仍然需要团队自己负责。
可以这样实践：为每个 Django 项目准备一个最小安全检查命令，把容易遗漏的配置放进 CI。
# 在项目根目录运行，检查 Django 部署安全配置
python manage.py check --deploy
# 如果使用 pip，可以顺手检查依赖是否存在已知漏洞
python -m pip install pip-audit
pip-audit
如果你想把它放进 GitHub Actions，可以改造成下面这个工作流：
name: django-security-check
on:
pull_request:
push:
branches: [main]
jobs:
security:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-python@v5
with:
python-version: '3.12'
- run: python -m pip install -r requirements.txt
- run: python manage.py check --deploy
- run: python -m pip install pip-audit && pip-audit
这不是完整的安全体系，但它能把“上线前才想起安全”变成“每次 PR 都看一眼”。
DRF、Debug Toolbar 与“希望 Django 原生支持 REST API”
Salim 常用 Flask、FastAPI，也在大多数项目里使用 Django REST Framework。他提到如果有“魔法能力”，希望 Django 能开箱支持 REST API。
这个愿望很有代表性。Django 的核心仍然偏向传统 Web 应用，而现代团队经常需要同时服务前端 SPA、移动端、内部工具和第三方集成。DRF 之所以流行，正是因为它补上了序列化、权限、分页、认证、Browsable API 等 API 开发中的常见拼图。
可以这样搭一个最小 DRF 接口。假设你已经有 Django 项目，并安装：
python -m pip install django djangorestframework
python manage.py startapp api
在 settings.py 中加入：
INSTALLED_APPS = [
# ...
'rest_framework',
'api',
]
创建一个可直接改造的只读 API：
# api/views.py
from rest_framework.decorators import api_view
from rest_framework.response import Response
@api_view(['GET'])
def health(request):
return Response({
'status': 'ok',
'service': 'django-api',
})
# api/urls.py
from django.urls import path
from .views import health
urlpatterns = [
path('health/', health),
]
# project/urls.py
from django.urls import include, path
urlpatterns = [
path('api/', include('api.urls')),
]
运行后测试：
python manage.py runserver
curl http://127.0.0.1:8000/api/health/
如果接口变复杂，再引入 serializers、viewsets、permissions，不要一开始就把所有抽象都堆上去。
贡献开源：先接小角色，再进入社区网络
Salim 的开源经历很典型：第一次贡献来自一个二进制插桩工具，因为逆向工程时遇到 bug，只能读懂并修掉它。后来在 Djangonaut Space 中，他参与 Django CMS，修复 Advanced form 中缺失 X-Frame-Options 相关的问题。
他给新贡献者的建议很直接：不要等到“准备好了”再开始。这个状态很少会来。先接一个小角色，依赖周围的人，保持沟通。
这同样适用于会议组织。Salim 第一次参加 DjangoCon Africa 是作为演讲者，后来加入组织团队。他惊讶于社区成员愿意从很远的地方赶来参会。现在，他担任 DjangoCon US 网站团队主席，负责让参会者通过网站清楚了解会议信息。
如果你想从“使用者”变成“贡献者”，可以按这个顺序开始：
- 找
good first issue、文档 typo、测试补充这类低风险任务。 - 在 issue 里先复述你的理解，再说明你准备怎么改。
- PR 保持小而聚焦，避免顺手重构无关代码。
- 接受维护者反馈，把它当作协作而不是考试。
- 参加 Djangonaut Space、DjangoCon 或本地 Python/Django 社群，让贡献变成长期关系。
采用建议：把社区、框架和安全放在同一张路线图上
Salim 的故事有一个清晰信号：技术成长不只发生在编辑器里。Django 的价值来自框架本身，也来自文档、会议、维护者、组织者、安全研究者和新贡献者共同形成的生态。
对团队来说，可以从三个小动作开始：
- 新项目默认运行
python manage.py check --deploy，并把结果纳入 CI。 - API 项目优先评估 DRF，明确权限、认证和序列化边界。
- 给工程师预留社区贡献时间，哪怕只是修文档、复现 bug 或参与会议网站维护。
不要等到完全准备好。小 PR、小议题、小角色，往往就是进入大型开源社区的第一扇门。