os.stat不能替代权限检查，因它仅验证路径存在性和元信息可读性，不校验实际访问权限；真正判断需模拟操作（如os.open）或用syscall.access预检，且须防范路径遍历和符号链接漏洞。
os.Stat 不能替代权限检查，别信它返回的“存在”
很多人用 os.Stat 判断路径是否可访问，结果线上出问题：目录明明存在，os.Stat 成功了，但后续 os.Open 却报 permission denied。这是因为 os.Stat 只查元信息可读性，不校验实际访问权——比如父目录缺 X_OK（执行位），你就进不去子目录，但 os.Stat 仍可能成功（只要上层有读权限）。
真正要确认“能读”，就该模拟读操作：
- 想读文件？直接
os.ReadFile(path)或os.Open(path)，捕获fs.PathError中的errno - 想写？用
os.OpenFile(path, os.O_WRONLY|os.O_CREATE, 0644)尝试打开 - 想遍历目录？用
os.ReadDir(path)，失败时看是不是syscall.EACCES
syscall.Access 是轻量预检，但只查最后一级
syscall.Access 是最接近系统原生 access(2) 的方式，适合快速预判。但它有个硬伤：只检查路径**最后一级组件**的权限，不验证中间路径是否可达。
比如检查 /a/b/c.txt 的 R_OK，内核只查 c.txt 文件本身的读权限；但如果你没有 /a 或 /a/b 的 X_OK，照样进不去。
实操要点：
- 必须传入绝对路径：
filepath.Abs后再调用，否则相对路径会按进程 cwd 解析，极易误判 - Linux 上受挂载选项影响（如
noexec），macOS 对目录X_OK检查更宽松，跨平台需测试 - 错误区分：
err == syscall.EACCES表示明确拒绝，err == syscall.ENOENT才是路径不存在
路径遍历防护不是加个 strings.Contains("..") 就完事
用户输入的路径拼接前不做规范化，../ 攻击分分钟绕过白名单。光用 strings.Contains(filename, "..") 不够——攻击者可用 %2e%2e/、....// 或符号链接绕过。
安全做法是两步闭环：
- 先用
filepath.Clean归一化路径（处理./、../、重复分隔符） - 再用
filepath.Abs转成绝对路径，然后用strings.HasPrefix(cleanedAbsPath, allowedRootAbs)校验是否落在白名单根目录下 - 注意：白名单根目录也必须是
filepath.Abs后的结果，且结尾带filepath.Separator，防止/var/data匹配到/var/datatest
os.Chmod 在 Windows 上基本无效，别当真
os.Chmod(path, 0444) 在 Linux/macOS 上能让文件只读，但在 Windows 上只尝试设置 FILE_ATTRIBUTE_READONLY，其他权限位全被忽略。管理员或文件所有者依然能通过资源管理器改写。
这意味着：跨平台服务中，靠 os.Chmod 做权限控制是伪安全。真正起效的只有应用层逻辑：
- HTTP handler 中对每个请求做路径白名单 + 用户角色校验
- 上传文件时强制重命名 + MIME 类型与扩展名双校验
- 敏感路径（如
/admin）走独立路由组 + JWT 中间件，不依赖文件系统位
最后提醒一句：符号链接是路径校验的最大漏洞。即使你做了 filepath.Abs + HasPrefix，攻击者仍可能用软链指向白名单外路径——所以生产环境务必禁用符号链接，或在打开前用 os.Stat 检查 os.ModeSymlink 位并拒绝。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
