cached.loader在django 4.x中默认仍不启用，仅修复loader链异常传播问题以提升命中稳定性；其缓存机制与3.x一致，只缓存“模板路径→编译后template对象”映射，不加速渲染执行；真正提速依赖正确配置嵌套结构、重启开发服务及注意st_mtime准确性。
cached.Loader 在 Django 4.x 中默认仍不启用，但行为更稳定
Django 4.x 没有在模板渲染速度上做底层引擎重构，cached.Loader 的逻辑和缓存机制与 3.x 完全一致——它依然只缓存「模板路径 → 编译后 Template 对象」的映射，不涉及渲染执行层。真正变化的是稳定性：4.x 修复了若干 loader 链中异常传播导致缓存跳过的问题，尤其在自定义 loader 或 select_template() 多 fallback 场景下，cached.Loader 更大概率能命中并复用编译结果。
模板编译阶段的 minor 优化对真实请求影响极小
4.x 对 django.template.base.Parser 做了少量 AST 构建路径裁剪，比如减少无用 token 的重复检查、优化 {% if %} 嵌套时的条件节点合并。这些改动在纯基准测试（如单次编译 1000 个模板）中可测出 3–5% 提速，但对实际 Web 请求几乎无感——因为模板编译耗时通常不到 1ms，而数据库查询或上下文构建动辄几十毫秒。
debug-toolbar 的 Templates Panel 在 4.x 中更准，但不等于渲染变快
Django 4.x 同步更新了 django-debug-toolbar 的模板面板信号监听逻辑，能更精确捕获 template_rendered 事件，避免因中间件顺序或异步视图导致的漏统计。这让你更容易发现「某个 include 被意外调用了 12 次」这类问题，但它本身不加速任何渲染——只是把原本就存在的瓶颈暴露得更清楚。
真正该关注的不是版本差异，而是配置是否生效
很多团队以为升级到 4.x 就自动提速，结果发现 cached.Loader 还是没生效。关键点就三个：
- 必须用嵌套结构：
['django.template.loaders.cached.Loader', ['django.template.loaders.filesystem.Loader', 'django.template.loaders.app_directories.Loader']]，不能写成平铺 list - 开发期改模板后必须重启 dev server，
cached.Loader的缓存存在进程内存里，清 Redis 没用 - 生产环境若用 NFS 或容器挂载模板目录，
st_mtime可能不准，导致缓存永不刷新
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
