当实现 io.Writer 接口时，若逻辑上主动忽略部分输入字节（如跳过前10字节、过滤偶数位等），只要操作成功，Write 方法必须返回 len(p) 并返回 nil 错误；仅当因异常（如底层资源不可用、缓冲区满、中断）导致处理中断时，才可返回 n

当实现 `io.writer` 接口时，若逻辑上主动忽略部分输入字节（如跳过前10字节、过滤偶数位等），只要操作成功，`write` 方法必须返回 `len(p)` 并返回 `nil` 错误；仅当因异常（如底层资源不可用、缓冲区满、中断）导致处理中断时，才可返回 `n

在 Go 中，io.Writer 是一个基础而严谨的接口，其契约（contract）远不止方法签名那么简单。核心在于：Write 的返回值 n 表达的不是“物理落盘/传输的字节数”，而是“逻辑上已成功处理并确认接纳的字节数”。这一点常被初学者误解为“实际写出量”，但官方文档与标准库实践均明确指向语义一致性。

例如，标准库中的 io.Discard（即 /dev/null 的 Go 实现）从不保存任何数据，但它始终返回 len(p), nil —— 因为它完整、无误地“消费”了所有输入，完成了预期的丢弃语义。同理，你的过滤型 writer（如跳过首10字节的 SkipWriter）若成功解析并按规则丢弃了全部 p，就应视作完整处理，返回 len(p)：

type SkipWriter struct {
    skip int
}

func (w *SkipWriter) Write(p []byte) (n int, err error) {
    if len(p) <p>关键注意事项如下：</p>

• 严禁“部分成功”返回 n ：这直接违反 io.Writer 合约，将导致 io.Copy、bufio.Writer 等依赖该语义的组件行为异常（如死循环、数据截断）。
• 错误必须真实反映失败原因：仅当处理流程被强制中断（如下游 Write 返回 err != nil、内存分配失败、上下文取消）时，才返回 n
• 文档即契约：你的类型必须在 godoc 中清晰声明处理逻辑，例如：
  // SkipWriter 丢弃前 N 字节后，将剩余字节透传至下游。Write 总是返回 len(p) 和 nil（除非下游写入失败）。
  这让使用者能准确预判数据流向，避免误以为“返回值 n = 实际落库字节数”。

总结而言，io.Writer 的 n 是处理完整性指标，而非存储有效性指标。设计自定义 writer 时，应优先保证接口语义的严格遵守——这比实现细节更重要。标准库的稳健性正源于此共识：只要 n == len(p) 且 err == nil，调用方即可安全假设输入已被按约定方式完整处置。