Go zip.FileHeader.Method 设置错误会导致压缩包打不开吗

会，但不是只要给 zip.FileHeader.Method 赋了一个非默认值，ZIP 就一定打不开。Go 的 archive/zip 把 0 当作 Store，把 8 当作 Deflate；这两条路径由标准库直接支持。真正容易出问题的是把未注册的方法编号交给 CreateHeader，或者在 CreateRaw 中让方法标记和实际压缩字节不一致。

排查时先看创建条目时的错误，再确认 Close 是否成功，最后沿着 zip.NewReader 和 File.Open 读回内容。不要只看文件名后缀，也不要把一个被截断的 ZIP 归因于压缩级别。

Method 的数值语义决定压缩器能否接手

FileHeader.Method 是 ZIP 条目的压缩方法编号，不是“压缩质量”或任意业务标记。zip.Store 的值为 0，表示直接存放内容；zip.Deflate 的值为 8，表示使用 Deflate。用 FileInfoHeader 创建头部时，方法字段默认未设置，此时仍会按 Store 解释；想压缩就要显式写入 zip.Deflate。

package main

import "archive/zip"

func headerFor(name string, compress bool) *zip.FileHeader {
	// 先约定相对路径，再明确选择 ZIP 方法，避免把业务枚举误当成方法编号。
	h := &zip.FileHeader{Name: name}
	if compress {
		h.Method = zip.Deflate
	} else {
		h.Method = zip.Store
	}
	return h
}

CreateHeader 与 CreateRaw 的边界不能混用

Writer.CreateHeader 接收未压缩的文件内容，Go 会根据 Method 选择压缩器，并在关闭当前条目时回填 CRC32 和尺寸。普通业务代码应走这条路径；如果方法编号没有对应压缩器，创建函数会返回 zip.ErrAlgorithm，调用方必须立即停止。

Writer.CreateRaw 是另一种契约：传入的内容不会再次压缩。它适合从已有 ZIP 条目复制原始数据，但不适合把普通明文直接写进去后再把 Method 假装成 Deflate。这样 ZIP 阅读器会按错误算法解释字节，常见结果就是打开失败、解压失败或 CRC 校验失败。

func writeEntry(w *zip.Writer, name string, data []byte) error {
	h := &zip.FileHeader{Name: name, Method: zip.Deflate}
	fw, err := w.CreateHeader(h)
	if err != nil {
		// 未注册的 Method 要在入口处返回，不能继续向 nil writer 写数据。
		return err
	}
	if _, err = fw.Write(data); err != nil {
		// 写入错误意味着条目内容不完整，交给调用方决定是否丢弃整个归档。
		return err
	}
	return nil
}

压缩包打不开时先按错误来源分层

值班排查可以按下面的顺序缩小范围：创建条目失败，优先看 Method；创建成功但归档损坏，检查每次 Write 和最后的 Close；读者提示不支持算法，再看是否使用了自定义方法或错误地走了 CreateRaw。

func makeZip(data []byte) ([]byte, error) {
	var buf bytes.Buffer
	w := zip.NewWriter(&buf)
	if err := writeEntry(w, "payload.json", data); err != nil {
		// 条目阶段失败时关闭 writer 也不能修复错误，直接返回更安全。
		return nil, err
	}
	if err := w.Close(); err != nil {
		// Close 负责写中央目录；不检查它，文件可能看似存在却无法打开。
		return nil, err
	}
	return buf.Bytes(), nil
}

上例还需要在导入区加入 bytes、archive/zip。生产代码中不要只记录“生成成功”，应把 CreateHeader、内容写入和 Close 的错误分别带上文件名和方法编号，便于判断是输入配置、底层 I/O，还是归档收尾失败。

用读取路径确认条目真的可用

发布或交给其他系统前，可以在内存中走一次读回路径：zip.NewReader 解析中央目录，遍历文件条目，读取 FileHeader.Method，再调用 File.Open 让标准库按方法解压并检查内容。返回的 io.ReadCloser 用完要关闭。

func inspectZip(raw []byte) error {
	r, err := zip.NewReader(bytes.NewReader(raw), int64(len(raw)))
	if err != nil {
		// 中央目录或 ZIP 结构不完整时，先修复写入收尾，不要改压缩级别。
		return err
	}
	for _, f := range r.File {
		fmt.Printf("%s method=%d\\n", f.Name, f.Method)
		reader, err := f.Open()
		if err != nil {
			// 这里能暴露未注册解压器、错误原始字节或校验问题。
			return err
		}
		_, readErr := io.Copy(io.Discard, reader)
		closeErr := reader.Close()
		if readErr != nil {
			return readErr
		}
		if closeErr != nil {
			return closeErr
		}
	}
	return nil
}

常见问题

Method 不设置是不是一定使用 Deflate？

不是。FileHeader.Method 为零时表示 Store；Writer.Create 才会替你创建一个使用 Deflate 的头部。

把 Method 改成 1 能不能表示“更高压缩率”？

不能。方法编号是算法标识，不是压缩等级。未注册方法会导致 ErrAlgorithm，需要调压缩级别时应注册对应的 compressor 或继续使用 Deflate。

为什么生成文件存在，但系统仍说 ZIP 损坏？

最常见的原因是没有检查 Close，中央目录没有完整写入；另一类原因是使用 CreateRaw 时方法、尺寸或 CRC32 与原始数据不匹配。

只读取 FileHeader.Method 就能证明文件没问题吗？

不能。它只能说明头部记录了什么方法。还要调用 File.Open 并读完内容，才能覆盖解压和 CRC 校验路径。