单纯用 os.Stat + os.Chmod + os.Chown 无法可靠同步文件属性，因其忽略符号链接、丢失 NTFS ACL、Windows 静默失败，且不处理跨文件系统硬链接的元数据继承问题。
单纯用 os.Stat + os.Chmod + os.Chown 无法可靠同步文件属性——它会忽略符号链接、丢失 NTFS ACL、在 Windows 上静默失败，且不处理跨文件系统硬链接的元数据继承问题。
为什么 os.Chmod/os.Chown 不能直接用于属性同步
这两个函数只修改目标路径的权限和所有者，但实际同步中常见陷阱远不止“改不了”：
-
os.Chown在非 root 用户（Linux/macOS）或任意 Windows 用户下必然返回operation not permitted，不应 panic 或中止流程，而应忽略错误 - Windows NTFS 支持 ACL（访问控制列表），
os.Chmod只能设置基础权限位（如0644），对WRITE_DAC、FILE_GENERIC_EXECUTE等完全无感 - 若源文件是符号链接，
os.Lstat获取的是链接本身元数据，但os.Chmod(dst, fi.Mode())作用于目标链接指向的文件（除非你显式用os.Lchmod） - 硬链接共享同一 inode，修改任一链接的权限会反映到所有链接上——这看似省事，实则可能破坏其他进程依赖的权限状态
如何安全复制 symlink / mode / owner / xattrs
真正可靠的属性同步必须分层判断、按需调用：
- 先用
os.Lstat读源路径元数据，检查fi.Mode() & os.ModeSymlink != 0；若是软链接，用os.Readlink读目标，再用os.Symlink在 dst 创建同名链接 - 权限同步：Linux/macOS 用
os.Chmod，Windows 则跳过（或用golang.org/x/sys/windows调用SetFileSecurity） - 所有者同步：仅当运行用户为 root 且目标支持时才调用
os.Chown；否则记录 warn 日志并继续 - 扩展属性（xattrs）：Linux 需
github.com/pkg/xattr，读取源xattr.List后逐项xattr.Set到目标；macOS 和 Windows 均不支持标准接口，应提前检测并跳过
Windows 下 ModTime 和 ACL 的精度陷阱
NTFS 的 ModTime() 实际只保留到 100ms，且 os.FileInfo.Sys() 返回的 *syscall.Win32FileAttributeData 不包含 ACL。直接比对会导致：
初始化并管理阿里云SDK Go 客户端，涵盖 sync.Once 单例、goroutine 安全、endpoint 与 region 配置、VPC 端点及调试。
立即学习“go语言免费学习笔记（深入）”；
- 频繁误判“文件已更新”，触发无意义哈希计算与复制
- ACL 完全丢失，同步后权限比源宽松（如源禁止删除，目标却允许）
对策是：在 Windows 上默认禁用 ModTime 比较，改用 Size() + 双端 SHA256（前 64KB + 后 64KB）快速判定；ACL 同步需额外调用 windows.GetNamedSecurityInfo + windows.SetNamedSecurityInfo，且必须以管理员权限运行。
并发同步时属性写入的竞态与顺序
多个 goroutine 并发处理不同文件时，若属性设置和内容写入不在同一事务中，会出现“权限已设但内容未写完”的中间态。尤其当目标被其他进程监控（如 antivirus、backup agent）时，可能因权限不足拒绝读取半成品文件。
- 正确顺序是：
os.Create→ 写内容 →os.Chmod（或os.Lchmod）→os.Chtimes→os.Rename（原子替换） - 不要在
io.Copy前调用os.Chmod，因为临时文件权限若太宽（如0777），可能被其他用户提前访问 - 用
os.Chtimes显式设置Atime和Mtime，避免系统自动更新访问时间干扰后续比对
最易被忽略的一点：Windows 上 os.Rename 替换已有文件时，新文件会继承原文件的权限——这意味着你前面设的 Chmod 全白干。必须在 Rename 前确保目标不存在，或 rename 后立即再 Chmod 一次。
