Go zip.FileHeader 怎么保留文件权限和修改时间再写入归档

从源文件取得 FileInfo，调用 zip.FileInfoHeader 生成条目头，再设置归档内部的相对名称，最后用 Writer.CreateHeader 建立条目并写入内容。FileInfoHeader 会带入模式和修改时间；如果自己构造头，权限通过 SetMode 设置，修改时间写入 Modified。保存到 ZIP 的元数据是否在解压后恢复，还取决于解压工具、平台和恢复策略。

官方地址：https://pkg.go.dev/archive/zip

保护资产：内容之外还有名称、权限和时间

设想一个导出任务需要归档 reports/daily.txt。内容正确并不代表导出完整：归档中的名称决定文件放在哪里，权限影响后续使用方式，修改时间用于识别内容的时间背景。若只创建名称再复制字节，而没有从源对象生成条目头，原有模式和时间就没有自然进入归档的来源。

这里要保留的是文件系统提供的模式与修改时间，不是完整复制文件系统。所有者、访问控制列表、扩展属性和所有平台特性不应被一并承诺。文章也不比较压缩算法，示例使用默认的 Store 存储方式，让元数据处理保持清楚。

风险路径：把源路径当成条目名称

源路径与归档内部名称应分开传递。例如源文件位于调用方选择的目录，归档名称仍可固定为 reports/daily.txt。不要把本机绝对路径直接写入 Name，也不要让调用方随意指定上级跳转名称。归档名称使用正斜杠，普通文件名称不以斜杠结束。

FileInfoHeader 最初使用的是基本文件名，不会替调用者推导完整的目录层次。保留层次时，应在创建条目前明确覆盖 Name。也不要先用会消除上级片段的清理操作，把不符合导出策略的输入悄悄变成另一个有效名称；可以直接拒绝它，让调用者修正。

风险分级：保留信息与执行信息分别决定

如果目标是精确保留来源模式，就使用来源 Mode；如果导出要求统一为可读数据文件，则可以明确调用 SetMode 设置受限模式，但这属于归一化策略，不能再声称权限完全保留。两种需求应在接口层讲清楚。

防护控制：用同一个打开对象取得信息并复制

下面的函数读取一个普通文件，将它作为一个条目打包到内存。返回字节前会检查 ZIP 收尾错误；打开的源文件在所有返回路径上关闭。示例适合讲清元数据写入，大文件业务可采用流式输出设计。

package exportzip

import (
    "archive/zip"
    "bytes"
    "fmt"
    "io"
    "io/fs"
    "os"
    "strings"
)

func ArchiveFile(sourcePath, entryName string) (result []byte, resultErr error) {
    // 采用较严格的导出名称策略，同时拒绝反斜杠和盘符形式。
    if entryName == "." || !fs.ValidPath(entryName) ||
        strings.ContainsAny(entryName, "\\:") {
        return nil, fmt.Errorf("归档条目名称不合法")
    }

    source, err := os.Open(sourcePath)
    if err != nil {
        return nil, fmt.Errorf("打开源文件: %w", err)
    }
    defer func() {
        if err := source.Close(); err != nil && resultErr == nil {
            result = nil
            resultErr = fmt.Errorf("关闭源文件: %w", err)
        }
    }()

    // 从已打开的对象读取属性，避免另查一次路径再打开。
    info, err := source.Stat()
    if err != nil {
        return nil, fmt.Errorf("读取源文件属性: %w", err)
    }
    if !info.Mode().IsRegular() {
        return nil, fmt.Errorf("只支持普通文件")
    }
    header, err := zip.FileInfoHeader(info)
    if err != nil {
        return nil, fmt.Errorf("创建条目元数据: %w", err)
    }
    header.Name = entryName
    // 明确保留来源模式和现代修改时间字段。
    header.SetMode(info.Mode())
    header.Modified = info.ModTime()

    var output bytes.Buffer
    zw := zip.NewWriter(&output)
    entry, err := zw.CreateHeader(header)
    if err != nil {
        return nil, fmt.Errorf("创建归档条目: %w", err)
    }
    // CreateHeader 接管条目头，此后不再修改 header。
    if _, err := io.Copy(entry, source); err != nil {
        return nil, fmt.Errorf("写入条目内容: %w", err)
    }
    if err := zw.Close(); err != nil {
        return nil, fmt.Errorf("完成ZIP归档: %w", err)
    }
    return output.Bytes(), nil
}

函数没有关闭外部文件输出，因为它只写入自己持有的内存缓冲。中途失败时丢弃结果，不把部分字节作为成功归档交付。如果改为写入外部 io.Writer，ZIP Writer.Close 不负责关闭底层文件，调用方还需要处理底层关闭及交付逻辑。

从已打开对象 Stat 再复制，有助于保持内容来源与属性来源一致，但不构成不可变快照。另一个写入方仍可能修改同一文件。需要一致性导出的业务，应在源对象管理层协调读写，而不是仅靠设置条目头推断内容被冻结。

审计记录：保存来源与归档映射

多文件导出时，每个条目单独创建新的头，不要反复修改已经提交给 CreateHeader 的同一个指针。条目内容也应在创建下一个条目之前写完。否则名称、属性和内容的对应关系难以追踪。

导出记录可以保存内部条目名称、来源模式、来源修改时间、复制的字节数和任务结果。对外记录不一定需要保留机器专属绝对路径。若发生错误，应记录出错阶段和原始错误链，避免只保留一个“ZIP失败”的统一文案。

验证清单：读回字段，不扩大保真承诺

本文未执行本地代码或归档测试。读者自行使用时，可读取生成的归档，观察条目的 Name、Mode 和 Modified，分别与导出规则及源属性比较；内容则另行核对。这里不提供伪造的终端结果，也不把静态图当成归档执行证据。

时间比较应考虑 ZIP 的时间表达精度，不要求纳秒完全相同。不同工具也可能展示不同的本地时间文本。文件权限则应比较平台支持的模式含义；在一个平台记录了执行位，不保证另一个解压环境就会原样应用。

如果增加目录条目，名称需要以正斜杠结束，且不应写入普通文件数据。本例只处理普通文件，因此直接拒绝其他类型，避免把目录元数据和文件内容路径混在一个函数里。

常见问题

FileInfoHeader 后还必须调用 SetMode 吗？它已经从 FileInfo 设置模式。示例重复显式设置，是为了展示可保留或按策略调整的位置，并非缺少这行就一定丢失模式。

修改时间应该写 ModifiedTime 吗？新代码使用 Modified。ModifiedTime 与 ModifiedDate 是旧格式字段，不宜作为新业务接口。

写入完成后能修改 header.Name 吗？不要这样做。CreateHeader 接管头的所有权，调用后不能再修改该头；下一条目建立新的对象。

可靠的元数据导出依赖三个明确来源：属性来自源对象，名称来自归档规则，成功来自内容写入和归档收尾都没有报错。解压后的恢复能力则需要在目标环境单独判断。

参考：Go 官方 ZIP 元数据接口；FileInfoHeader 官方实现。