去年接手一个维护了五年的Django老项目，第一件事不是看代码，而是检查settings.py。果然，DEBUG=True还挂在生产环境里，更讽刺的是，项目用了Django自带的admin，而那个admin界面居然能直接通过.media路径拿到本地文件。我忍不住想起来：这个团队之所以选Django，就是冲着它“开箱即用”的安全宣称——CSRF防御、XSS转义、ORM防注入，结果呢？所有人都以为这些默认值能兜住一切，于是没人再理解这些机制到底在防什么。
Django的安全体系确实成熟，但它的成熟反而成了一种“保姆式”的麻痹。新人入职只需要跟着教程走，Django就自动帮你转义了模板变量，自动在form里加了CSRF token，甚至自动把ORM查询参数化。我见过一个同事，在需要拼接动态表名时本能地想用format去组装SQL，因为他忘了ORM里有一个.raw()危桥。后来出了线上故障，他还在抱怨Django没提示他。这让我想起使用Rails时的体验，Rails的ActiveRecord同样有防护机制，但Ruby社区的人普遍会去读Arel源码，而Python社区里有多少人能说清Django的query如何parameterized？默认的安全措施教不会你安全，它只是替你做了安全，而替你做的部分一旦失效，你就裸奔了。
如果把Django和Flask、FastAPI放在一起比，那种“不安全感”反而更能逼出一个人的安全意识。我写过Flask，一个轻量应用要自己接入CSRF库，自己处理SQLite的注入隐患，甚至自己要给响应头加上X-Frame-Options。那种每一步都战战兢兢的感觉，会让你认真去读OWASP，去理解什么是SQL注入的边界。而FastAPI虽然也是现代框架，但它的依赖注入和pydantic校验让你觉得舒服，可它并不强制你规范使用Security类，你需要自己决定怎么用。说起来讽刺，我在Django里放心大胆地用了三年的ORM，却是在用Flask做一个小工具时第一次意识到filter_by和raw_sql的差异会带来什么后果。
当然，我并不是说Django应该抛弃这些安全默认值，而是说我们应该主动去“拆解”它。比如，你能否在你的项目里禁用掉默认的CsrfViewMiddleware，然后手动给每个POST请求加验证？你能否把模板的自动转义关掉，然后亲手给每一个变量套上escape过滤器？如果你的团队做不到这些，那就意味着你们对安全的理解停留在框架的遮阳伞之下。另外，Django的ORM确实高效，但在高并发下，那些懒加载的QuerySet可能会让你浪费几十次SQL循环。别盲目迷信select_related和prefetch_related，有时一条简单的JOIN比ORM的魔法更清晰。我最近在调一个慢接口，用Django的aggregate死活生成不了想要的子查询，最后直接写原生的SQL才把耗时从4秒降到200毫秒。所以，下次再用Django时，试着问自己：如果这个框架明天消失，我还会写安全又高效的web应用吗？如果答案是犹豫的，那你正在被它的便利驯化。
我有个偏激的观点：Django应该学着做点“减法”。它把admin、auth、session、migration、template……一股脑全塞给你，看似全自动，其实让你失去了独立摸索的空间。相比之下，FastAPI让你从零搭建中间件，Flask让你自己选择数据库抽象层，那种“半成品”的感觉反而更健康。我知道很多人会反驳说这是Django的生态优势，但优势不等于真理。如果你只是需要一个能快速跑起来的CRUD后台，Django依然是神器；可如果你是一个渴望成长的开发者，别让孩子睡在Django的舒适区里。我用了十年的Django，如今越来越喜欢在项目里用裸的ASGI + 自己的验证代码来解决安全问题。这样做很痛苦，但很清醒。
最后说一件小事。上个月我指导一个实习生，他一上来就用Django的create_user方法，我问他这个方法内部对密码做了什么处理？他愣了半天说：“不是自动加密吗？”那一刻我明白了，框架的安全机制正在批量制造“无知的自信”。我们要的不是感谢Django帮我们挡住了黑客，而是有一天我们拆掉它时，还能知道自己站在什么土地上。这就是我眼中Django最大的陷阱。
