上传路径必须绑定用户id且由后端生成，禁用前端传入的路径片段；需校验权限、隔离存储、脱敏文件名并使用系统级配额。
上传路径必须绑定用户ID，不能依赖前端传来的目录名
用户上传文件时，如果直接用 request.FormValue("dir") 拼接本地路径，就等于把文件系统控制权交给了客户端。攻击者可以传 ../../../etc/passwd 或 ./admin/secret.txt 绕过隔离。正确做法是：所有路径由后端根据 userID（从 session 或 token 解析）生成，且全程不接受任何路径片段输入。
实操建议：
- 用
filepath.Join(uploadRoot, strconv.FormatInt(userID, 10))构建用户专属根目录，uploadRoot设为固定绝对路径（如/var/uploads） - 上传前调用
filepath.Clean()处理原始文件名，再检查是否以.开头或含..—— 若有，直接拒绝 - 写入前用
filepath.EvalSymlinks()检查目标路径是否仍在用户目录内，防止符号链接逃逸
HTTP handler 中必须校验用户身份与文件操作权限
上传接口不是“登录即可用”，而是要明确区分“谁能在哪个空间写什么”。比如运营人员可上传 banner 图，但不能覆盖用户头像；普通用户只能写自己的 avatar/ 和 docs/ 子目录。
实操建议：
- 在 handler 开头解析 JWT 或 session，得到
userID和role；再查 DB 或缓存获取该用户的allowedUploadPaths列表（如["avatar/", "docs/"]） - 若请求中带
subpath（如avatar/123.jpg），需用strings.HasPrefix(subpath, allowed)逐项匹配，不允许通配符 - 避免在 handler 里调用
os.Chown()—— 权限应由目录结构和进程 UID 控制，而非运行时修改属主
磁盘配额不能靠应用层计数，得用 Linux quota 或 overlayfs
用 Go 定期扫描用户目录统计大小并拦截上传，既不准（并发写入时漏算），又慢（大目录耗 CPU）。真正的隔离需要操作系统级支持。
实操建议：
- 为每个用户创建独立子卷（如
zfs create tank/uploads/user_123）或使用quota设置 block limit，Go 只需捕获ENOSPC错误并返回413 Payload Too Large - 若用 Docker 部署，可用
overlay2的upperdir绑定到用户目录，配合--storage-opt size=5G - 不要在 Go 里实现“累计上传量”逻辑 —— 它无法应对硬链接、快照、删除延迟等真实文件系统行为
文件名存储必须脱敏，数据库只存哈希+元信息
数据库里存 original_name: "发票.pdf" 是安全隐患：它暴露用户行为，还可能被用于路径猜测或 XSS（如果前端直接渲染）。更严重的是，多个用户上传同名文件时，仅靠名字无法区分。
实操建议：
- 生成唯一 ID 用
uuid.NewSHA1(uuid.Nil, []byte(fmt.Sprintf("%d-%s-%d", userID, time.Now().UnixNano(), rand.Int()))).String()，截取前 16 位作文件名 - 数据库字段只保留
file_id（UUID）、user_id、mimetype、size_bytes、stored_name（如a1b2c3d4e5f67890），绝不存原始名 - 前端下载时通过
/download?id=a1b2c3d4e5f67890接口，在响应头设Content-Disposition: attachment; filename="发票.pdf"—— 原始名只在此处还原，且需做url.PathEscape()过滤
用户空间映射真正难的不是代码怎么写，而是目录树设计是否经得起审计 —— 比如 /uploads/{shard}/{user_id}/ 的分片策略一旦定死，后续扩容就只能靠迁移脚本，而不是改几行 Go 就能解决。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
