ed25519签名必须使用go标准库crypto/ed25519，不可用crypto/ecdsa替代；私钥为64字节（前32字节seed、后32字节公钥），签名和公钥固定为64字节和32字节，消息须原样传入，禁止预哈希或修改字节。
Ed25519 签名必须用 crypto/ed25519，别碰 crypto/ecdsa 或手写曲线
Go 标准库的 crypto/ed25519 是唯一安全、经过充分审计的 EdDSA 实现。它不暴露私钥结构，不支持自定义哈希或随机数生成器——这不是缺陷，而是设计约束。试图用 crypto/ecdsa 模拟 Ed25519 会失败，因为底层曲线（Edwards25519）和签名流程（PureEdDSA）与 ECDSA 完全不同。
常见错误现象：panic: invalid private key 或签名验证失败，往往源于误把 ed25519.PrivateKey 当作字节切片直接序列化，或用非 ed25519.GenerateKey 生成的密钥。
-
ed25519.GenerateKey返回的PrivateKey是 64 字节：前 32 字节是 seed（用于派生），后 32 字节是公钥；不能截断或重组 - 签名必须用
ed25519.Sign，传入原始消息[]byte，不加前缀、不哈希——库内部已做 SHA-512 哈希和上下文处理 - 不要对消息先
sha256.Sum256再传给Sign，这会导致双重哈希，验证必然失败
私钥导出和加载必须用 ed25519.PrivateKey 的原生格式
标准库不提供 ToPEM 或 FromDER 方法。私钥序列化就是直接拷贝 64 字节，加载时也必须是完整 64 字节切片，且需确保是 ed25519.PrivateKey 类型（底层是 []byte，但类型检查存在）。
容易踩的坑：json.Marshal 私钥会转成 base64 字符串，再 json.Unmarshal 后得到的是 []byte，但类型不是 ed25519.PrivateKey，直接传给 Sign 会 panic。
监控加密货币价格并在达到阈值时触发警报。支持 BTC、ETH、SOL 及 100 多种其他币种，使用 CoinGecko API。可配置价格上限和下限阈值。
- 保存私钥：用
copy(dst[:], privKey)或privKey[:]获取底层数组，写入文件或数据库 - 加载私钥：读取 64 字节 → 构造
ed25519.PrivateKey：priv := ed25519.PrivateKey(append(make([]byte, 0, 64), data...)) - 若从 PEM 解析，需先 base64 解码，再校验长度是否为 64，最后类型转换
ed25519.Verify 失败的三个高频原因
验证失败不等于签名错，大概率是输入不匹配。验证函数只做三件事：检查公钥长度（32 字节）、签名长度（64 字节）、以及 PureEdDSA 验证逻辑。其余全靠调用方保证。
- 公钥不是 32 字节：常见于把整个
ed25519.PrivateKey（64 字节）当公钥传，或从私钥中错误提取（应取privKey[32:]，不是privKey.Public().(ed25519.PublicKey)的返回值） - 签名不是 64 字节：Base64 解码后没校验长度，或传输中截断
- 消息字节完全不一致：HTTP body 有 BOM、JSON 序列化字段顺序不同、字符串末尾多了换行符——EdDSA 对输入字节零容忍
需要上下文绑定（Context）？只能自己封装，标准库不支持
标准 ed25519.Sign 实现的是 PureEdDSA，不带 context（如 "SigEd25519 no Ed25519 collisions"）。如果协议要求 HashEdDSA（例如某些 DID 规范），必须手动拼接 context 和消息再哈希，再用 ed25519.Sign 签这个哈希值——但这已脱离 EdDSA 标准流程，验证端也必须同步实现同样拼接逻辑。
性能影响：手动哈希 + 签名比原生调用慢约 15%，且丧失标准互操作性。除非明确协议要求，否则不要加 context。
- 若真要加 context：
h := sha512.New(); h.Write([]byte("MyContext")); h.Write(message); sig := ed25519.Sign(priv, h.Sum(nil)) - 公钥和签名长度不变，但验证方必须用完全相同的 context 和哈希方式预处理消息
- 注意：这样签出来的不是标准 EdDSA，OpenSSL 或 libsodium 默认不认
hex.Dump 对比两端消息字节，而不是假设“内容一样”。
