安全读取用户文件需三步：先os.Stat验证为常规文件且大小合理，再http.DetectContentType检查MIME类型是否在白名单，最后拒绝危险扩展名以防范SSTI。
用 os.OpenFile 创建文件时，权限设成 0666 就出事了
很多开发者以为“文件得让Web服务器读到”，就随手写 0666，结果敏感配置、用户上传的临时文件全被同组或其他用户读取——尤其在共享主机或容器多租户环境下，这等于把钥匙挂门把手上。
真正安全的做法是：仅授予必要权限，且明确打开模式：
-
0600用于私有配置（如 API 密钥、数据库密码）——只有当前用户可读写 -
0644用于静态资源（如公告文本、公开消息）——所有者可读写，其他人只读 - 必须显式传入
os.O_CREATE | os.O_WRONLY | os.O_TRUNC，避免意外追加或覆盖已有内容 - 别忘了
defer file.Close()，否则 fd 泄漏可能撑爆进程上限
用户传来的文件名，filepath.Clean 不是万能解药
filepath.Clean("../../etc/passwd") 确实会变成 ../etc/passwd，但它不解决根本问题：你仍可能拼出越权路径。关键不在“清理”，而在“校验是否还在白名单目录内”。
正确姿势是组合使用 filepath.Clean + filepath.Join + strings.HasPrefix：
立即学习“go语言免费学习笔记（深入）”；
func isValidPath(input, baseDir string) (string, error) {
cleanPath := filepath.Clean(input)
fullPath := filepath.Join(baseDir, cleanPath)
rel, err := filepath.Rel(baseDir, fullPath)
if err != nil || strings.HasPrefix(rel, "..") {
return "", fmt.Errorf("invalid path: %s", input)
}
return fullPath, nil
}
注意：baseDir 必须是绝对路径（如 /var/data/board），否则 filepath.Rel 可能失效；另外，别用 path/filepath 处理 URL 路径（含 // 或 %2e%2e），那是 net/url 的活。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
读取消息内容前，别跳过 stat 和 MIME 检查
直接 os.ReadFile 一个用户指定的路径，哪怕路径已校验，也挡不住符号链接指向系统文件、或普通文件被恶意改成设备节点（如 /dev/zero）——轻则读空，重则阻塞或泄露。
安全读取应分三步走：
- 先
os.Stat检查是否为常规文件（fi.Mode().IsRegular()）、大小是否合理（比如限制 ≤1MB） - 再用
http.DetectContentType读前 512 字节，确认 MIME 类型在白名单内（如text/plain、text/markdown） - 拒绝任何扩展名为
.sh、.php、.go的文件名（即使内容是纯文本）——这是防御服务端模板注入（SSTI）的第一道筛子
用 html/template 渲染消息时，template.HTML 是信任开关，不是逃生出口
很多人看到“支持富文本”就直接把用户输入转成 template.HTML，结果 XSS 立刻上线。Go 模板的自动转义只对 {{.Content}} 生效，一旦你写 {{.Content | safeHTML}} 或返回 template.HTML，Go 就彻底放手不管了。
真要渲染用户提交的 HTML，必须前置净化：
- 用
bluemonday.UGCPolicy()这类成熟库做白名单过滤，禁用script、onerror、javascript:等一切执行上下文 - 永远别用
strings.ReplaceAll或正则删标签——绕过方式太多，比如<scr></scr>或注释混淆 - 如果消息板根本不需 HTML，那就强制纯文本输出，连
template.HTML都别碰
最常被忽略的一点：模板里用 {{template "sub" .}} 时，若 "sub" 名称来自用户输入（比如 URL 参数），就构成服务端模板注入（SSTI），和 SQL 注入一样危险——这种动态模板名必须硬编码或白名单校验。
