go 的 encoding/ascii85 包自 1.0 起已被标记为 deprecated，因使用率低且被更安全通用的 base64 取代；其编码虽略紧凑（25% 膨胀 vs base64 的 33%），但实现复杂、易出错、不支持含 \0 的无损 round-trip，且标准库维护弱。
为什么 encoding/ascii85 在 Go 中几乎没人用
Go 标准库确实包含 encoding/ascii85，但它自 1.0 起就标记为 deprecated（已弃用），文档明确写明 “This package is deprecated: it is little-used and has been superseded by base64.”。实际项目中基本见不到它的身影——不是不会用，而是不该用。
ASCII85 编码比 base64 略紧凑（约 25% 数据膨胀 vs 33%），但代价是实现复杂、可读性差、易出错，且不支持任意字节流的无损 round-trip（比如含 \0 的数据在某些变体中会截断）。现代场景下，base64 和 base32 更安全、更通用、标准库维护更好。
如果真要跑通一个 ASCII85 编解码流程，该怎么做
尽管不推荐，但若需对接遗留系统（如 PostScript 或早期 Adobe PDF），仍可能遇到 ASCII85 编码数据。此时必须注意：encoding/ascii85 的 Encoder 和 Decoder 不处理换行或空格，只做纯编码转换；输入必须是合法 ASCII85 字符串（!–u 和 z），否则 Decode 会返回 ascii85: invalid byte 错误。
-
Encode接收[]byte，输出不含换行的[]byte；若想兼容 PostScript 换行规则（每 72 字符折行），得自己分段加\n -
Decode要求输入严格符合 ASCII85 字符集，z只能单独出现（代表 4 个 \0），不能嵌入中间；遇到空格、制表符、回车会被忽略，但非法字符（如v或大写字母）直接报错 - 编码后末尾可能有
~>（Adobe 变体终止符），但 Go 的实现不自动添加也不校验它；你得手动 strip 或补全
package main
import (
"encoding/ascii85"
"fmt"
"io"
)
func main() {
src := []byte("hello world")
var dst []byte
// 编码
enc := ascii85.NewEncoder(nil)
enc.Write(src)
dst, _ = io.ReadAll(enc)
fmt.Printf("encoded: %s\n", dst) // 输出类似 "F)Po,GA2@8l"
// 解码（注意：dst 是 []byte，不是 string；若含非 UTF-8 字节，转 string 可能乱码）
dec := ascii85.NewDecoder(nil)
dec.Write(dst)
out, _ := io.ReadAll(dec)
fmt.Printf("decoded: %v\n", out) // [104 101 108 108 111 32 119 111 114 108 100]
}
Decode 失败的常见原因和修复方式
最常见的错误是把带换行、空格或 ~> 尾缀的 ASCII85 字符串直接喂给 Decode，结果触发 ascii85: invalid byte。这不是 bug，是设计使然——Go 的实现只做核心编解码，不负责预处理。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 先用
strings.Map或正则去掉所有空白符（\r\n\t），再检查是否以~>结尾并截掉 - 确认字符串长度是 5 的倍数（不足补
u），否则Decode会卡在最后不满 5 字节的块上 - 避免用
string()强转原始数据再传入；Decode期望的是[]byte，而 Go 字符串不可变，中间有 \0 时容易被截断 - 测试时别用中文或 emoji 原始字节直接编码——ASCII85 本身不关心语义，但你的调试器显示可能误导判断
替代方案：什么时候该换 encoding/base64
除非协议强制要求 ASCII85（例如解析某款老打印机的响应），否则一律改用 base64。它在 Go 中稳定、高效、默认支持 URL-safe 变体（RawURLEncoding），且 DecodeString 和 EncodeToString 开箱即用。
迁移成本极低：base64.StdEncoding.EncodeToString(data) 替代手写 ASCII85 编码逻辑；遇到 illegal base64 data 错误时，大概率是填充符 = 缺失或混入了空格——这时用 base64.RawStdEncoding 即可绕过填充校验。
真正麻烦的从来不是选哪个包，而是发现生产日志里有一段“看似 ASCII85 实际是 base64 补了 =” 的数据，还被前端 JS 用错方法解了三次。
