Buffalo 默认不内嵌 assets/ 和 templates/，buffalo build 仅打包 public/ 下已构建的文件；若 public/ 为空或禁用前端构建，则二进制中无静态资源，导致 /assets/app.css 404 或模板渲染失败。
Buffalo 默认不内嵌 assets/ 和 templates/，buffalo build 只打包 public/ 下已构建的文件
这是最常被误解的一点：很多人以为 buffalo build 会把 assets/（如 SASS/JS 源码）、templates/ 或迁移文件一并打进二进制，其实不会。它只复制 public/ 目录内容——而这个目录是 Webpack 构建后输出的结果。如果你删了 webpack.config.js、禁用了前端构建，或者 public/ 是空的，那 buffalo build 打出来的二进制里就真没静态资源。
常见错误现象：buffalo build 成功，但运行时访问 /assets/app.css 返回 404，或模板渲染报 template: "index.html" not found。
- 根本原因是 Buffalo 的 asset pipeline 和打包逻辑分离：开发期走 Webpack → 输出到
public/→buffalo dev用app.ServeFiles提供；生产打包只“搬运”public/，不处理源码级资源 - 若你用的是纯 Go 内嵌（比如 Go 1.16+
//go:embed），必须手动声明包级变量并在App()前初始化，Buffalo 不会自动帮你做 -
buffalo build虽然内部集成了 packr/v2，但默认不启用；一旦你显式用了//go:embed，它还会静默跳过 packr 初始化，导致资源彻底丢失
用 packr/v2 手动打包 assets/、templates/ 进二进制最可控
绕过 Buffalo 自带的 asset pipeline，自己用 packr/v2 把源目录打进去，是目前最稳定、兼容性最好的方式。它不依赖 Webpack，也不和 //go:embed 冲突，且能统一管理静态文件、模板甚至 migration。
实操步骤：
立即学习“go语言免费学习笔记（深入）”；
- 安装工具：
go install github.com/gobuffalo/packr/v2/packr2@latest - 在项目根目录新建
box.go，内容类似：package main import "github.com/gobuffalo/packr/v2" var AssetsBox = packr.New("app-assets", "./assets") var TemplatesBox = packr.New("app-templates", "./templates") - 在
app.go的App()函数开头（务必在buffalo.New()之前）调用AssetsBox.Walk或直接传给app.Use(...)中间件；模板则用TemplatesBox初始化plush.Parser - 构建前先运行
packr2（它会生成packrd.go），再执行buffalo build；否则packr2不会注入初始化代码
注意：packr2 生成的代码必须和你的 Go 模块路径一致，否则运行时报 box not found；如果用了 Go 1.16+，别同时在同个包里混用 //go:embed 和 packr.New，会冲突。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
HTTP 层加缓存头要区分资源类型，别全设 Cache-Control: public, max-age=31536000
静态资源缓存不是越长越好。JS/CSS 文件可以用强缓存（配合内容哈希命名），但 HTML 页面、API 接口、登录态资源必须严格控制，否则用户看到旧版 UI 或脏数据。
Buffalo 默认不设任何缓存头，得自己加中间件或在 handler 里写：
- 对
/static/**路由（如 JS/CSS/图片）：用w.Header().Set("Cache-Control", "public, max-age=31536000")，前提是文件名含哈希（如app.a1b2c3.js），否则得配ETag或Last-Modified - 对
/api/**：设为no-cache或短时效，例如max-age=60；避免前端缓存 JSON 导致状态不一致 - 对 HTML 页面（如
/、/admin）：用private, no-store，禁止 CDN 和代理缓存，防止敏感信息泄露 - 别在
app.Use(middleware.Logger)后才写 header——中间件顺序很重要，缓存头必须在响应写出前设置
用 http.FileServer 服务静态文件时，路径和安全细节极易出错
Buffalo 的 app.Static 或 app.ServeFiles 底层就是封装的 http.FileServer，但直接用它容易踩坑：404、目录遍历、MIME 错误。
关键约束：
-
http.Dir必须是**绝对路径**，不能用"./public"—— 工作目录变化时会失效；建议用filepath.Abs("./public")初始化 - 它不自动补尾部斜杠，也不识别
index.html；访问/static（无 /）会 404，得额外加路由回退或用http.StripPrefix+http.ServeFile组合 - 目录遍历防护靠的是
http.Dir的路径校验，但仅限最终路径；如果你用filepath.Join(root, r.URL.Path)拼接后再传给FileServer，可能绕过检查——应先filepath.Clean，再确认是否仍在允许根目录内 - MIME 类型默认不全，CSS/JS 可能被当成
text/plain；需提前调用mime.AddExtensionType(".css", "text/css")
真正上线时，建议把静态资源交给 Nginx 或 CDN，Go 进程只负责 API；若必须内置，优先用 packr/v2 内嵌 + 自定义 http.Handler，而不是裸跑 http.FileServer。
