text/template原生不支持include，因Parse阶段无法动态加载文件；需用“file:”前缀方案在解析期递归加载并注册define块，避免循环引用且子模板须优先注册。
text/template 本身不支持 include 指令，Go 的标准模板引擎在解析阶段无法动态加载并内联其他文件内容——所有 {{define}} 块都是运行时才生效的，而 Parse 阶段早已结束。所以你写 {{include "header.tmpl"}}，它不会报错，但也不会起作用；模板里该缺失的部分依然缺失。
为什么原生 template.ParseFiles 不能解决 include 需求
你可能会尝试先 ParseFiles("base.tmpl", "page.tmpl")，指望后者能复用前者定义的 {{define "header"}}。但问题在于：
-
template.ParseFiles是按参数顺序依次解析，后一个模板无法“引用”前一个模板中未导出的define名称（除非显式调用template.New("base").Parse(...)再funcMap["include"] = ...） - 多个文件间没有依赖声明机制，你得手动维护加载顺序，一旦 base.tmpl 依赖了 layout.tmpl，就得改成
ParseFiles("layout.tmpl", "base.tmpl", "page.tmpl")—— 这不可扩展 - 无法做路径解析或相对引用，
{{define "header"}}和{{define "file:./shared/header.tmpl"}}在语义上完全不同，后者才能表达“我要加载这个外部文件”
如何在解析期实现真正的 include（file: 前缀方案）
核心思路是：把 include 的意图编码进 {{define}} 名称里，让解析器能识别并递归加载。比如写 {{define "file:layouts/base.tmpl"}}，就表示“请把 layouts/base.tmpl 的内容也 parse 进来，并把它所有 {{define}} 注册到当前模板集合中”。
实操要点：
- 所有待 include 的文件路径必须以
"file:"开头，且路径相对于项目根目录（不是相对于当前模板文件） - 递归解析时要记录已处理的文件名，避免循环引用（如 a.tmpl → b.tmpl → a.tmpl）
- 最终合并模板时，顺序很重要：子模板（被 include 的）应优先于父模板注册，否则同名
define会被覆盖——所以实际要逆序追加：append(tmpls, childTmpl)放在append(tmpls, parentTmpl)之前 - 不要直接用
template.Must(template.New(...).Parse(...))，因为错误需统一捕获并带文件路径上下文
配置文件层级设计中容易忽略的路径与作用域问题
很多人把配置文件也当成模板来 include，比如 config.tmpl 中写 {{include "db.tmpl"}}，再用 os.ExpandEnv 或 envsubst 做变量替换——这会出问题。
Pandas 配置文件报告生成器
下载
使用ydata-profiling（前身为pandas-profiling）生成全面的数据质量报告，包含相关性分析、缺失值模式和基数检测。导出交互式HTML仪表板和JSON摘要。
立即学习“go语言免费学习笔记（深入）”；
关键区别：
- 模板
include是代码级嵌入，发生在 Go 程序启动时；配置文件include是数据级组合，应由配置解析器（如viper）在加载时完成 -
viper不支持原生 include，但可通过viper.SetConfigFile+ 多次ReadInConfig模拟：先读base.yaml，再读service.yaml并用viper.MergeConfigMap合并 - 若硬要用模板生成配置，务必注意：模板函数不能访问运行时环境变量（除非显式传入
map[string]interface{}），而os.Getenv在Parse阶段不可用
最稳妥的做法是分两层：用 viper 加载多文件配置（支持 SetConfigName("base") + SetConfigName("prod")），再把最终 map 传给 template.Execute 渲染模板——这样 include 是数据的，不是模板的。
