把模板文件用 //go:embed 放入 embed.FS 后，将这个FS传给 html/template.ParseFS 即可提供模板源。解析路径相对于嵌入FS，执行时则使用文件基名或 define 定义的模板名。文件已经打包，并不等于模板定义已经被ParseFS读入。

官方地址：https://go.dev/

常见现象是本地页面正常，换目录运行却找不到模板；改成embed以后，又出现“模板未定义”。这两种错误涉及不同名字：文件路径与模板名字。下面用一个资源清单页把它们分开，保持示例简短，不启动Web服务。

先区分没有打包与没有解析

准备一个Go模块，文件组织如下。这是项目结构文字示例，不是终端截图：

main.go
views/
  page.html
  row.html

构建工具读取go:embed模式，匹配源码包目录里的文件；运行时ParseFS从嵌入FS取内容。模板中的template动作再从已经解析的模板集合查找定义。排查时先确认自己用错的是哪个名字。

让ParseFS读取嵌入文件系统

main.go采用下面完整内容。embed.FS实现fs.FS，因此可作为ParseFS的读取来源，不需要先把文件解压到临时目录。

package main

import (
    "bytes"
    "embed"
    "fmt"
    "html/template"
    "os"
)

// views 保存构建时匹配到的模板文件，而不是运行目录的实时文件。
//go:embed views/*.html
var views embed.FS

func render() error {
    pages, err := template.ParseFS(views, "views/*.html")
    if err != nil {
        return fmt.Errorf("解析嵌入模板: %w", err)
    }
    data := struct {
        Title string
        Items []string
    }{
        Title: "资源清单",
        Items: []string{"daily.csv", "summary.txt"},
    }
    var buf bytes.Buffer
    // 这里使用define名称；不是嵌入文件路径views/page.html。
    if err := pages.ExecuteTemplate(&buf, "inventory-page", data); err != nil {
        return fmt.Errorf("执行页面模板: %w", err)
    }
    // 先渲染到缓冲，模板失败时避免向输出写入半页HTML。
    if _, err := buf.WriteTo(os.Stdout); err != nil {
        return fmt.Errorf("写出页面: %w", err)
    }
    return nil
}

func main() {
    if err := render(); err != nil {
        fmt.Fprintln(os.Stderr, err)
        os.Exit(1)
    }
}

本例只嵌入指定目录的html文件。go:embed的路径分隔符使用正斜杠，模式相对于源码所在包目录；不要把部署机器的绝对路径填进指令。模板文件需要在构建前存在。

用模板名执行页面与片段

将页面保存到views/page.html：

{{/* inventory-page 是ExecuteTemplate使用的显式模板名。 */}}
{{define "inventory-page"}}

{{.Title}}
{{range .Items}}{{template "inventory-row" .}}{{end}}
{{end}}

将片段保存到views/row.html：

{{/* range中传入的点号已经是单个字符串，不再是整个页面数据。 */}}
{{define "inventory-row"}}
{{.}}
{{end}}

两个文件都显式定义名字，因此代码执行inventory-page，页面再引用inventory-row。range内部的点号是当前条目，示例传给片段的是文件名字符串。如果片段要读页面Title，应另行组织传入的数据，不应假设点号一直指向外层结构体。

若没有define，解析文件通常按基名建立模板名；多个目录出现相同基名时可能覆盖。这里用唯一显式名降低混淆，但显式定义也不能重名滥用，应保持页面和片段命名清楚。

为什么换工作目录仍能渲染

在包含main.go和views目录的项目根目录运行以下命令。示例需要支持embed与ParseFS的Go 1.16或更新工具链：

# 只在新目录尚无go.mod时初始化一次。
go mod init example.com/embed-inventory
# 模板在构建时打包；生成的程序执行嵌入的页面。
go build -o inventory .
./inventory

预期输出包含“资源清单”标题及daily.csv、summary.txt两个列表项。程序不依赖运行时重新打开views/page.html，所以在其他工作目录使用正确可执行文件路径运行，仍读取同一份嵌入模板。这是代码预期，不声称已在本机切换目录执行。

改动源码目录中的模板后，必须重新构建并部署二进制，旧程序不会热更新。若部署后仍显示旧标题，先确认启动的是哪一个构建产物，而不是在服务器补建同名views目录。

按错误阶段定位并维护资源

构建阶段出现嵌入模式无匹配，应检查文件位置和模式；ParseFS返回错误，应检查FS中的名字、模式以及模板语法；ExecuteTemplate提示模板未定义，应检查define名与片段是否一同解析。按这三个阶段分别处理，比反复改相对路径更直接。

本例先渲染到bytes.Buffer，再写stdout，能避免模板执行错误时先输出部分页面；最终写出仍可能失败，因此WriteTo错误也要返回。这个缓冲策略用于说明小页面的完整性，不承诺任意大小页面都应在内存一次生成。

ParseFS会自动提供CSS或图片地址吗？

不会。本文只向模板解析器提供模板内容。浏览器资源需要另行提供访问入口，不能因为文件嵌入就假设某个URL可用。

页面解析成功为什么片段仍未定义？

确认片段文件属于ParseFS匹配范围。只嵌入文件却没有把它解析进同一模板集合，不能直接调用其定义。

数据里有HTML要手动转为template.HTML吗？

本例以普通字符串作为数据，保留html/template的转义处理。不要为了显示方便把不可信字符串标记为可信HTML；模板源本身也应由应用维护。

本例的定位重点是三组名字：嵌入路径、解析范围、执行模板名。固定它们的职责后，embed.FS就能作为稳定的模板来源，而不会把当前工作目录变成隐藏依赖。

官方资料：embed包说明；html/template.ParseFS说明。