Go base64.AppendDecode 返回部分结果时怎么继续处理

Go base64.AppendDecode 返回错误时，仍可能把已解码的前缀追加到目标切片中。继续处理前先保存调用前的长度，接住返回切片，再把新增区域和错误一起判断：需要完整消息就回退到原长度；确实允许残片的诊断任务才能保留这段前缀。错误位置不能直接当作断点续传游标。

官方文档：https://pkg.go.dev/encoding/base64#Encoding.AppendDecode

AppendDecode 从 Go 1.22 起提供。下面围绕它的缓冲区语义给出接入方式，不把既有能力包装成新发布新闻，也不假定追加接口总能省掉分配。

先认清追加结果的三部分

一次调用涉及原有目标 dst、编码输入 src、返回切片 out、本次新增区 added 和错误 err。start 是调用前的 len(dst)，新增区是 out[start:]；它不包括原有内容。len(out) 是旧内容与本次有效输出的总长度，不能当作本次解码量。

容量足够时追加可能复用底层数组，容量不足时可能扩容。因此，成功和失败两条路径都应使用返回值，不能只看旧 dst 的长度。API 不承诺把整条输入作为一个原子事务处理。

用返回切片保存部分输出和错误位置

下面的独立示例把坏字符放在完整编码单元之后，用于说明“部分结果与错误同时存在”。它是阅读示例，没有把运行记录作为证据。程序只展示本次新增前缀，随后按完整消息策略撤回本条新增内容。

package main

import (
    "encoding/base64"
    "errors"
    "fmt"
)

func main() {
    dst := []byte("record:")
    start := len(dst)
    src := []byte("YWJj!A==")

    // 即使失败，也接住返回切片；扩容后它可能指向新的底层数组。
    out, err := base64.StdEncoding.AppendDecode(dst, src)
    added := out[start:]
    fmt.Printf("本次取得的前缀: %q\n", added)

    if err != nil {
        var corrupt base64.CorruptInputError
        if errors.As(err, &corrupt) {
            // 这是当前 src 的输入字节位置，不是 added 的长度。
            fmt.Printf("输入损坏位置: %d\n", int64(corrupt))
        }
        // 完整消息策略：撤回本条新增区，保留调用前的内容。
        dst = out[:start]
        fmt.Printf("保留原内容: %q\n", dst)
        return
    }
    dst = out
    fmt.Printf("接收完整消息: %q\n", dst)
}

示例中的 YWJj 对应 abc，后面的感叹号不属于该编码字母表。由此可以理解为什么本次新增区可能已经有内容，但整条消息仍不能接受。使用 errors.As 取得 CorruptInputError 时，目标变量是该值类型；如果上层包装错误，仍能保留类型判断。

输入位置按 src 字节计算，和目标里预先放了多少字节无关，也不等于解码后的长度。不要先删除换行再声称错误位置仍对应原文；如果做了预处理，需要自己保存位置映射。

完整消息采用整条回退

文件导入、完整记录解析等任务通常要求整条有效。把 start 看作本条的提交起点：err 为 nil 才把 out 交给下一层，否则用 out[:start] 恢复可见长度。之后处理下一条独立消息，不要把本条残片当成完整消息的一部分。

这种回退只调整切片长度，不会擦除底层数组里已写过的字节，也不能撤销之前写入文件、发送网络请求或调用回调的副作用。因此应先完成当前消息的解码判断，再提交下游；若还要求原底层数组完全不被触及，应使用独立暂存缓冲区，成功后再合并。

修复输入后从原始目标重新解码

AppendDecode 不返回已消费输入量，也不保存跨调用的解码状态。CorruptInputError 用来描述输入问题；把 src 从该位置截开再调用，可能破坏编码单元、填充或消息边界。需要修正后重试时，从 out[:start] 开始，对重新取得的完整输入再解码，避免前缀重复追加。

// 已由上层重新取得完整、修正后的输入；不要只截取错误点之后的字节。
fixed := []byte("YWJjZA==")
base := out[:start]
next, retryErr := base64.StdEncoding.AppendDecode(base, fixed)
if retryErr != nil {
    // 再次失败仍回到本条起点，不把部分字节提交给下游。
    dst = next[:start]
} else {
    dst = next
}

这段代码接在前面示例的变量上下文中，用于表达另一条修复分支，而不是让前一个示例 return 后继续执行。fixed 必须由可信的上层纠正或重新读取，不应为了得到成功结果随意丢弃非法字符。

选择切片接口还是流式接口

从网络读到的任意分块不一定与 Base64 单元对齐，不能把每个分块都当成独立消息调用 AppendDecode。真正的连续流优先考虑 NewDecoder；应用本身有独立记录边界时，先收齐当前记录，再调用切片接口。复用容量可能减少分配，但是否有收益取决于实际缓冲区管理，不能直接承诺性能提升。

返回错误后，部分结果一定非空吗？

不一定。输入一开始就损坏时，本次新增区可能为空。判断 len(out) 时还要扣除 start，避免把原目标误认为新结果。

把 dst 切回原长度算清空了吗？

只恢复了可见范围。其他共享底层数组的引用以及容量范围内的字节不会因此被擦除。

能忽略换行之外的任意空白吗？

该接口忽略 CR 和 LF，不代表任意空格、制表符或坏字符都可忽略。输入清洗应遵守业务格式，不应把损坏静默改成可接受的数据。

源码参考：https://go.dev/src/encoding/base64/base64.go。处理这类返回值时，把新增字节和错误放在同一个决策里，再决定提交、保留诊断前缀或回到原长度。