分享一些2026年有意思的现代化Django生态组件
2026年了,若还在忍受石器时代的模板和冗余CRUD,趁早转行。Cotton和Inertia总算给Django这老古董续了命,Ninja这类工具已是开发及格线。看一眼这些现代化组件吧,别再用那些自我感动的低效代码来折磨审美了。
STARBLOG / 技术与日常的文字存档
写下实践中的发现,也留住那些值得回看的想法。
2026年了,若还在忍受石器时代的模板和冗余CRUD,趁早转行。Cotton和Inertia总算给Django这老古董续了命,Ninja这类工具已是开发及格线。看一眼这些现代化组件吧,别再用那些自我感动的低效代码来折磨审美了。
呵,连WebSocket都没塞进去就敢叫大版本更新?不过模版片段和内置后台任务总算让Django像个现代框架了,至少写HTMX时不用再到处塞碎片文件。原生CSP?早该有了。至于抛弃Python 3.11——跟不上时代的版本留着也是累赘。
DjangoStarter v3.3.0?哦,不过是优化了Docker和换了个Granian服务器。导航栏多了管理后台,还扔了unfold。过渡版本就这?
WSGI 排名靠前?uWSGI 才是王道。ASGI 增加复杂度,性能还差一截。腾讯云服务器性能还掉线?真是够了。
DjangoStarter 成了时间黑洞?一堆无关组件拖累维护成本,果断瘦身砍掉 django-compressor、Prometheus、Grafana,小项目何必搞企业级运维?Less is more,把精力花在刀刃上。
Granian是Rust写的ASGI服务器,性能比Daphne强点,但离uWSGI还差着远?静态文件支持倒是省事。开发环境够用,生产环境还是得看情况。
前言 使用Django开发项目好是好,就是部署的时候太麻烦,使用Uwsgi服务器的话,每次修改了代码,都需要重新启动服务器才可以生效。然后uwsgi服务器的重启也挺麻烦。 看了一下官网的文档,最好是把uwsgi安装到venv虚拟环境里面,这样的话在 ps aux 的时候容易区分啦。 查看uwsgi进程 ps -aux | grep uwsgi 结束原uwsgi进程 kill -9 27543 结论
Django过时?技术趋势变了而已,异步支持短板在AI时代更明显。生态工程化再稳,也挡不住轻量框架和ASGI的冲击。独立开发者该考虑新选择了?
Django生态真够用,simple-history这种现成工具谁还手写审计?ModelAdmin混入就完事,历史记录自动记录,不过unfold集成倒是省心。别跟我提什么复杂配置,简单点挺好。
呵,又一篇Django表单美化的水文。自己封装了Tailwind样式还嫌不够,非得折腾django-crispy-forms这种老古董——Bootstrap都过时了喂!不过crispy-tailwind倒是勉强能看,至少比手写模板优雅点。反正最后都会用React重写,何必浪费时间?
腾讯COS集成Django真够折腾的,官方SDK和文档烂到不行。自己封装Storage虽然简单,但腾讯那帮人写代码的心思让人看不懂。Django这套东西倒是好用,`FileField`、`ImageField`自动转OSS,不过`django-filer`那中文locale问题得手动改。
Django-Ninja API鉴权机制?不就是又一套基于AppClient的认证系统,支持查询参数、请求头、Bearer Token认证,外加IP白名单和scopes权限控制?代码写得够复杂,够绕?
上个月底培训了一周就没时间更新博客 上周有一些空闲时间,就继续体验最近很火的AI辅助编程
在生成唯一 ID 这件事上,Django 和其他后端框架没啥不同的,思路都是类似的,只不过可以借助 Python 生态偷懒一下…
这个只是简单的demo,实际上生产还得考虑很多问题,本文就是为 channels 的应用开了个头,后续有新的研究成果会持续更新博客~
多阶段构建Docker镜像,自动处理Python和前端依赖,优化大小——终于不用手动折腾了。从uWSGI换到Daphne,支持ASGI,但静态文件共享真是心累,靠volume才搞定。部署方案整合进DjangoStarter,但折腾过程就像无情的网络搬运工。
无非继承MP_Node配置TreeAdmin,拖拽编辑树节点。可视化?也就django-treebeard能用,其他要么停更要么功能拉胯。初始化数据?手动导入,否则admin连按钮都没有,bug。接口输出无非path和depth,自己实现更舒服。
最近做的这个项目大量使用了 python 及其相关的生态,因此自然而然选择了我的 DjangoStarter 作为后端框架
之前看到有个叫 `django-tailwind` 的 python包,不过可能配套的 `tailwind` 版本不方便更新,再加上 **DjangoStarter** 很早就使用 NPM 和 gulp 来管理前端静态资源了,所以还是手动来添加 tailwind 比较好。
测试,在以前确实是经常被忽略的话题,特别是对于 Python Web 这种快速开发框架
DjangoAdmin DjangoAdmin本身就是一套大而全的系统,官方文档中介绍了很多配置方法,但仍然有大量的骚操作是文档中没有的,所以遇到特殊需求的时候,求助文档不一定有用。 在我看来 DjangoAdmin 虽然能快速生成一套管理后台,但如果要做大量特殊需求的定制,其成本不亚于用 Vue/React 重新开发一套,简单的使用成本不高,但深入定制的话需要对 DjangoAdmin 的工作流
前言 双十一光顾着买东西都没怎么写文章,现在笔记里还有十几篇半成品文章没写完… 今天来分享一下 Django 项目切换数据库和迁移数据的方案,网络上找到的文章方法不一,且使用中容易遇到各类报错,本文根据 Django 官方文档和工作中的经验,稳定可靠,在博客中长期更新~ 如果你遇到同样的问题,阅读本文应该能得到比较好的解决方案。 基本步骤 Django 默认使用 SQLite 数据库方便开发,同时
步骤 既然是快速开发,那废话不多说,直接说步骤: 安装Djagno 安装Django Rest Framework 定义models 定义Rest framework的serializers 定义Rest framework的viewsets 配置Rest framework的router 配置管理后台admin 根据需要写template和对应的view 经过这些步骤就能得到一个具备完整的后端接
前言 之前写过两篇跟这个插件有关的文章,可以回顾一下: Django数据导入导出神器django-import-export使用 Django-Import-Export插件关于外键的处理 最近有个朋友留言问我一个关于django-import-export插件的问题 为了形象表达这个问题,我举个书籍管理的例子来描述一下 数据库表 | id | name | price | | ---- |