这会造成混乱吧。

另外，为什么会出现错误的时候，“值是部分可用”？是函数返回多个值，然后某几个可用吗。
那这种情况是不是一个函数揉了太多的东西了，有必要放在一个函数里面返回一堆值吗，把功能拆出来，拆成几个小函数不可以吗。

你需要的是把数据包装到错误中。
```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);
}
}
```

看起来是很正常的需求，没必要自定义 error

在一个有很多步骤的逻辑中，虽然中间某一步骤报错，但是仍然根据返回的可用值继续进行，这个操作没啥毛病

go 语言挺自由的，没有那么多严格规范

另外就算是报错，也不能简单的定义为流程无法进行

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

您输入的密码部分有误(第 1 、3 、4 、6 位错误).

错误了, 就不应该在给出部分正确的信息, 除非这个错误本身就是可接受的, 比如同时向 100 个 API 推送消息, 但有个别 API 失败了这种场景(不影响主流程的).

大家有共识, 也不算问题.

那就别返回错误，因为看起来你的这个场景不是错误，部分失败是一个正常的业务流程。

返回一个 Result 之类的结构，里面定义状态， 成功，失败，部分失败之类的。

```
// Reader is the interface that wraps the basic Read method.
//
// Read reads up to len(p) bytes into p. It returns the number of bytes
// read (0 <= n <= len(p)) and any error encountered. Even if Read
// returns n < len(p), it may use all of p as scratch space during the call.
// If some data is available but not len(p) bytes, Read conventionally
// returns what is available instead of waiting for more.
//
// When Read encounters an error or end-of-file condition after
// successfully reading n > 0 bytes, it returns the number of
// bytes read. It may return the (non-nil) error from the same call
// or return the error (and n == 0) from a subsequent call.
// An instance of this general case is that a Reader returning
// a non-zero number of bytes at the end of the input stream may
// return either err == EOF or err == nil. The next Read should
// return 0, EOF.
//
// Callers should always process the n > 0 bytes returned before
// considering the error err. Doing so correctly handles I/O errors
// that happen after reading some bytes and also both of the
// allowed EOF behaviors.
//
// If len(p) == 0, Read should always return n == 0. It may return a
// non-nil error if some error condition is known, such as EOF.
//
// Implementations of Read are discouraged from returning a
// zero byte count with a nil error, except when len(p) == 0.
// Callers should treat a return of 0 and nil as indicating that
// nothing happened; in particular it does not indicate EOF.
//
// Implementations must not retain p.
type Reader interface {
Read(p []byte) (n int, err error)
}
```
每一个开发者的设计不同，上面的代码是 Reader 的注释，说了应该总是先处理 p ，再处理错误。

我遇到的基本都是有错误只有错误会有意义，其余均是 0 值。