Go模板中嵌套nil导致panic的真实触发点是interface{}字段的非顶层访问：传入struct{Data interface{}}且Data为nil时，{{.Data.Name}}会panic，而{{.Data}}安静输出空字符串；根本原因在于indirect()函数在字段链求值时对nil interface{}解引用失败。
Go 模板中嵌套 nil 导致 panic 的真实触发点
不是所有 nil 都会报错，template: master:1:15: executing "master" at <.data.foo>: nil pointer evaluating interface{}.Foo</.data.foo> 这类错误只在「非顶层字段访问」时爆发。比如传入 struct{ Data interface{} } 且 Data 为 nil，模板写 {{.Data.Name}} 就崩；但 {{.Data}} 只输出空字符串，完全安静。
根本卡点在于 Go 模板对 interface{} 的解引用策略：它允许顶层 nil 安静失败，但一旦进入字段链，就会调用内部 indirect() 函数层层取值，最终在 nil 上触发 panic。
- 避免把
interface{}当通用容器字段——这是最常见也最危险的设计 - 改用
map[string]interface{}或预定义 struct（如type User struct { Name string }），它们天然支持== nil判断 - 若必须保留
interface{}，应在模板里加{{if .Data}}{{with .Data}}{{.Name}}{{end}}{{end}}两层防护
Thymeleaf 中通过 fragment + 参数实现上下文透传
th:fragment 本身不携带上下文，但可通过 th:fragment="header(title, subtitle)" 声明形参，并在调用时用 th:replace="~{header :: header('首页', '欢迎回来')}" 注入实参。关键点是：参数必须显式声明，不能靠隐式继承父模板变量。
如果想让片段自动读取全局状态（比如用户登录态），不要依赖“父作用域自动可见”——Thymeleaf 默认不穿透。正确做法是：
立即学习“前端免费学习笔记（深入）”；
- 在主模板中把全局变量显式传入：
th:replace="~{header :: header(${user}, ${config})}" - 片段内用
th:fragment="header(user, config)"接收，而非直接写${session.user} - 避免在 fragment 内部调用
#{...}国际化表达式时依赖未声明的上下文变量，否则渲染时报ExpressionEvaluationException
HTML 模板引擎（如 Django/Jinja2）中 context 的生命周期边界
模板 context 是一次性的、不可跨请求复用的数据快照。你传入 {'user': user_obj, 'menu_items': [...]}，它只在本次 render() 调用中有效。不存在“全局 context 注册表”这种东西——所谓“全局”，只是开发者在每个视图函数里重复传入相同结构。
真正能接近“全局注入”的只有两类机制：
- 中间件注入：Django 的
context_processors在每次请求时自动把指定字典合并进 template context，例如django.template.context_processors.static总提供STATIC_URL - 模板继承中的 block override：父模板定义
{% block global_js %}{% endblock %}，子模板在对应位置插入脚本，但这不等于数据注入，只是 HTML 结构拼接 - 绝对不要在模板里尝试
import或include时动态构造 context 字典——Jinja2 的{% include 'header.html' with context %}只透传当前 scope，无法绕过作用域隔离
iframe 子页面与父页面之间无法共享 template context
iframe 是独立文档上下文，document 不同，window 不同，更别说 template context。你在父页渲染出的 {{user.name}} 和 iframe 里加载的 profile.html 完全无关——后者要自己发起请求、自己传 context、自己 render。
常见误操作是试图用 JS 把父页数据塞进 iframe：iframe.contentWindow.context = {...}。这不仅无效（子页 JS 无法直接读取该属性），还破坏了同源策略封装。可行路径只有：
- 子页面 URL 带 query 参数（如
profile.html?uid=123），服务端根据参数查数据并注入 context - 父子页面同源时，用
postMessage发送结构化数据，子页 JS 接收后手动更新 DOM（注意：这不是模板 context 注入，而是纯前端状态同步） - 若子页是静态 HTML，干脆放弃模板，用 JS fetch 拉取 JSON 数据再
innerHTML插入——但这就脱离了 server-side template context 体系
真正难的不是怎么传，而是认清边界：template context 是服务端概念，只存在于单次 HTTP 响应生成过程中；一旦响应发出，它就固化为 HTML 字符串，不再可变。任何试图“跨文档共享 context”的方案，本质都是重新发起一次服务端渲染或切换到客户端渲染范式。
