你可以实现两个接口，一个是 Error 接口，另一个是你定义的接口

你需要的是把数据包装到错误中。 ```go type MyErr struct { value int } func (err *MyErr) Error() string { return "MyErr" } func test(a int) (int, error) { if a%2 == 0 { return a, nil } return 0, &MyErr{value: a} } func main() { _, err := test(1) if err != nil && err.Error() =="MyErr"{ fmt.Printf("error %d\n",err.(*MyErr).value); } } ```

@PTLin #11 对哦, 是这样的

看起来是很正常的需求，没必要自定义 error 在一个有很多步骤的逻辑中，虽然中间某一步骤报错，但是仍然根据返回的可用值继续进行，这个操作没啥毛病 go 语言挺自由的，没有那么多严格规范

从程序流程角度看，发生错误之后，程序会进入错误处理流程，即使部分结果可用意义也不大了，除非你在错误处理流程中做正常的业务逻辑处理，一般不会这么做，也不推荐。

参考官方的设计意图： https://go.dev/blog/errors-are-values https://go.dev/blog/go1.13-errors 我补充一点个人理解： Golang 语境中的错误 error 是一种可以预期的行为，预期之外的叫 Panic （对应其他编程语言中的 Exception ）。 基于这种思想，Golang 中的错误处理有两个特点： 第一个特点就是上面两篇官方文档提到的，错误是值，使用这个值的方式是 wrap/unwrap ； 第二个特点是 Golang 主张显式控制流，所有的错误都应该按照调用链传播，并在恰当的位置进行处理。 这里“处理”的含义是停止传播，即忽略也是一种处理方式。

另外就算是报错，也不能简单的定义为流程无法进行 比如有些程序某些接口很容易因为各种原因无法获取到最新的值，选择重试几次，或者忽略此时的错误就可以了。是不会影响其他接口的获取和整体的刷新逻辑的

@shinonome 而且这种错误里包值的做法是非常场景的，为此 go 还内置了 errors 包替代这种手动转型和判断。

您输入的密码部分有误(第 1 、3 、4 、6 位错误).https://i.imgur.com/agAJ0Rd.png 错误了, 就不应该在给出部分正确的信息, 除非这个错误本身就是可接受的, 比如同时向 100 个 API 推送消息, 但有个别 API 失败了这种场景(不影响主流程的). 大家有共识, 也不算问题.

那就别返回错误，因为看起来你的这个场景不是错误，部分失败是一个正常的业务流程。 返回一个 Result 之类的结构，里面定义状态， 成功，失败，部分失败之类的。