一. Panic问题概述

本周收到客户在bugclose上填写的一个issue：添加一个下发通道后，pushd程序panic并退出了！程序panic时输出的stacktrace信息摘录如下：

panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x8ca449]

goroutine 266900 [running]:
pkg.tonybai.com/smspush/vendor/github.com/bigwhite/gocmpp.(*Client).Connect(0xc42040c7f0, 0xc4203d29c0, 0x11, 0xc420423256, 0x6, 0xc420423260, 0x8, 0x37e11d600, 0x0, 0x0)
        /root/.go/src/pkg.tonybai.com/smspush/vendor/github.com/bigwhite/gocmpp/client.go:79 +0x239
pkg.tonybai.com/smspush/pkg/pushd/pusher.cmpp2Login(0xc4203d29c0, 0x11, 0xc420423256, 0x6, 0xc420423260, 0x8, 0x37e11d600, 0xc4203d29c0, 0x11, 0x73)
        /root/.go/src/pkg.tonybai.com/smspush/pkg/pushd/pusher/cmpp2_handler.go:25 +0x9a
pkg.tonybai.com/smspush/pkg/pushd/pusher.newCMPP2Loop(0xc42071f800, 0x4, 0xaaecd8)
        /root/.go/src/pkg.tonybai.com/smspush/pkg/pushd/pusher/cmpp2_handler.go:65 +0x226
pkg.tonybai.com/smspush/pkg/pushd/pusher.(*tchanSession).Run(0xc42071f800, 0xaba7c3, 0x17)
        /root/.go/src/pkg.tonybai.com/smspush/pkg/pushd/pusher/session.go:52 +0x98
pkg.tonybai.com/smspush/pkg/pushd/pusher.(*gateway).addSession.func1(0xc4200881a0, 0xc42071f800, 0xc42040c700)
        /root/.go/src/pkg.tonybai.com/smspush/pkg/pushd/pusher/gateway.go:61 +0x11e
created by pkg.tonybai.com/smspush/pkg/pushd/pusher.(*gateway).addSession
        /root/.go/src/pkg.tonybai.com/smspush/pkg/pushd/pusher/gateway.go:58 +0x350

印象中近大半年用Go写的程序，遇到panic情况不多。上一次是因为原生map变量的并发访问导致的panic，那次panic一眼就看到问题所在了。但这次又是因为啥呢？

二. 分析和debug过程

这个问题在印象中似乎出现过，不过由于当初没有复现，客户环境中又没有panic信息提供，那时没能定位和解决，后来问题并没有出现，显然这个问题是有一定“随机属性”。

对于panic，我们首先检查直接导致panic发生的那一行代码：

        /root/.go/src/pkg.tonybai.com/smspush/vendor/github.com/bigwhite/gocmpp/client.go:79 +0x239

下面是client.go 79行周围的代码片段：

也许是疏忽大意，当时瞅了一眼后，就断定这块没有问题（更多从业务协议层面考虑），这也直接导致后面绕了一个大圈子才查到”真凶”。如果您还没看出来问题，那继续往下看。

定式思维让我认为很可能是函数栈中的内存问题，于是我开始调查panic输出的函数调用栈中参数是否正确。

要想知道函数调用栈中参数传递是否有问题，先要知晓panic后输出的栈帧信息都是什么！比如下面panic dump信息中参数中的各种magic number都代表什么！

gocmpp.(*Client).Connect(0xc42040c7f0, 0xc4203d29c0, 0x11, 0xc420423256, 0x6, 0xc420423260, 0x8, 0x37e11d600, 0x0, 0x0)

pusher.cmpp2Login(0xc4203d29c0, 0x11, 0xc420423256, 0x6, 0xc420423260, 0x8, 0x37e11d600, 0xc4203d29c0, 0x11, 0x73)

pusher.newCMPP2Loop(0xc42071f800, 0x4, 0xaaecd8)

在Joe Shaw的《Understanding Go panic output》和William Kennedy的《Stack Traces In Go》中有针对Stack trace输出信息的解析。关于Stack trace输出信息的识别，总体遵循几个要点：

• stack trace中每个函数/方法后面的“参数数值”个数与函数/方法原型的参数个数不是一一对应的；

• stack trace中每个函数/方法后面的“参数数值”是按照函数/方法原型参数列表中从左到右的参数类型的内存布局逐一展开的; 每个数值占用一个word(64位平台下面为8字节)

• 如果是method，则第一个参数是receiver自身。如果reciever是指针类型，则第一个参数数值就是一个指针地址；如果是非指针的实例，则stack trace会按照其内存布局输出；

• 函数/方法返回值放在stack trace的“参数数值”列表的后面；如果有多个返回值，则同样按从左到右顺序，按照返回值类型的内存布局输出；

• 指针类型参数：占用stack trace的“参数数值”列表的1个位置；数值表示指针值，也是指针指向的对象的地址；

• string类型参数：由于string在内存中由两个字(word)表示，第一个字是数据指针，第二个字是string的长度，因此在stack trace的“参数数值”列表中将占用两个位置；

• slice类型参数：由于slice类型在内存中由三个字表示，第一个word是数据指针，第二个word是len，第三个字是cap，因此在stack trace的“参数数值”列表中将占用三个位置；

• 内建整型(int,rune,byte)：由于按word逐个输出，对于类型长度不足一个Word的参数，会做合并处理；比如：一个函数有5个int16类型的参数，那么在stack trace的信息中，这5个参数将占用stack trace的“参数数值”列表中的两个位置；第一个位置是前4个参数的“合体”，第二个位置则是最后那个int16类型的参数值。

• struct类型参数: 会按照struct中字段的内存布局顺序在stack trace中展开。

• interface类型参数：由于interface类型在内存中由两部分组成，一部分是接口类型的参数指针，一部分是接口值的参数指针，因此interface类型参数将用stack trace的“参数数值”列表中的两个位置。

• stack trace输出的信息是在函数调用过程中的“快照”信息，因此一些输出数值看似不合理，但是由于其并不是最终值，所以问题不一定发生在这些参数身上，比如：返回值参数。

结合上面要点、函数/方法原型以及stack trace的输出，我们来“定位”一下stack trace输出的各个“参数”的含义：

cmpp2Login和Connect的原型以及调用关系如下：

func cmpp2Login(dstAddr, user, password string, connectTimeout time.Duration) (*cmpp.Client, error)

func (cli *Client) Connect(servAddr, user, password string, timeout time.Duration) error

func cmpp2Login(dstAddr, user, password string, connectTimeout time.Duration) (*cmpp.Client, error) {
    c := cmpp.NewClient(cmpp.V21)
    return c, c.Connect(dstAddr, user, password, connectTimeout)
}

对照后，我们得出下面对应关系：

pusher.cmpp2Login(
        0xc4203d29c0,  // dstAddr的data pointer
        0x11,                  // dstAddr string的length
        0xc420423256,  // user 的data pointer
        0x6,                    // user string的length
        0xc420423260,  // password的data pointer
        0x8,                    // password string的length
        0x37e11d600,    // connectTimeout
        0xc4203d29c0,  // 返回值：Client的指针
        0x11,                 // 返回值：error接口的type pointer
        0x73)                 // 返回值：error接口的data pointer

gocmpp.(*Client).Connect(
        0xc42040c7f0,   //cli的指针
        0xc4203d29c0,  //servAddr string的data pointer
        0x11,                  //servAddr string的 length
        0xc420423256,  // user string的data pointer
        0x6,                    // user string的length
        0xc420423260,  // password的data pointer
        0x8,                    // password string的length
        0x37e11d600,   // timeout
        0x0,                   // 返回值：error接口的type pointer
        0x0)                   // 返回值：error接口的data pointer

在这里，cmpp2Login的dstAddr、user、password、connectTimeout这些输入参数值都非常正常；看起来不正常的两个返回值在栈帧中的值其实意义不大，因为connect没有返回，所以这些值处于“非最终态”；而Connect执行到第79行panic，因此其返回值error的两个值也是处于“中间状态”。

这样一来，似乎没有参数是错误的！

三. 回到起点，捉住“真凶”

在反复查看代码和对比stack trace的参数列表后，依然没有找到蛛丝马迹。遂决定平复心情，从头再来，回到起点！

        var ok bool
        var status uint8
        if cli.typ == V20 || cli.typ == V21 {
                var rsp *Cmpp2ConnRspPkt
                rsp, ok = p.(*Cmpp2ConnRspPkt)
                status = rsp.Status
        } else {
                var rsp *Cmpp3ConnRspPkt
                rsp, ok = p.(*Cmpp3ConnRspPkt)
                status = uint8(rsp.Status)   <------ 79行
        }

        if !ok {
                err = ErrRespNotMatch
                return err
        }

又反复看了这段代码！程序正常执行时都是经过这段代码的，都是正常的。为何随机爆出panic呢？79行如果要panic，显然是rsp为nil或其他非法地址。但rsp是由p进行type assertion而来的！难道是type assertion失败了！！！

从正常业务流程来看，这里是不会失败的！这也是当初这里没有立即检查ok这个bool值的原因。但是特殊情况下，也就是当tcp连接建立后，conn包发出后，对方未必返回是conn response包，很可能是其他包回来（比如active test），这样就会导致这块的type assertion失败！这也与这个问题随机发生的情况吻合！

而且当初保留了“ok”，而不是用”_”代替，说明设计思路中是存在返回的包不是conn response包的情况。看来是当初coding时逻辑混乱了:(

这就是问题所在了！教训：type assertion后一定要在检查ok这个bool值之后再决定是否使用assertion之后的变量。

四. 其他

借着这个问题的解决过程，再多说一句 stacktrace。在Go 1.11及以后版本中，go compiler做了更深入的优化，很多“简单”的函数或方法会被自动inline(内联)了，函数一旦内联化了，那么在stack trace中我们就无法看到栈帧信息了，就会看到如下在栈帧信息中存在省略号的情况：

 $go run stacktrace.go
panic: panic in foo

goroutine 1 [running]:
main.(*Y).foo(...)
    /Users/tony/test/go/stacktrace/stacktrace2.go:32
main.main()
    /Users/tony/test/go/stacktrace/stacktrace.go:51 +0x39
exit status 2

可以使用-gcflags=”-l”来告诉编译器不要inline。至于是否要这么做，就要看debug和性能之间您是如何权衡的了。

我的网课“Kubernetes实战：高可用集群搭建、配置、运维与应用”在慕课网上线了，感谢小伙伴们学习支持！

我爱发短信：企业级短信平台定制开发专家 https://tonybai.com/
smspush : 可部署在企业内部的定制化短信平台，三网覆盖，不惧大并发接入，可定制扩展； 短信内容你来定，不再受约束, 接口丰富，支持长短信，签名可选。

著名云主机服务厂商DigitalOcean发布最新的主机计划，入门级Droplet配置升级为：1 core CPU、1G内存、25G高速SSD，价格5$/月。有使用DigitalOcean需求的朋友，可以打开这个链接地址：https://m.do.co/c/bff6eed92687 开启你的DO主机之路。

我的联系方式：

微博：https://weibo.com/bigwhite20xx
微信公众号：iamtonybai
博客：tonybai.com
github: https://github.com/bigwhite

微信赞赏：

商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。

这几年关于Go语言未来演化的讨论成为了Gopher世界的热点，Go team官方对于Go语言的演化(以Go2为标签)也是十分上心，但吸取了其他语言，比如：Python3割裂社区的、不兼容演化的教训，Go team最终选择了一条尽可能地兼容Go1、稳健、平滑的演化之路，并逐渐开始落地。Go 1.11的Go modules是Go team开启Go2演化进程的标志性事件。随着“Go 2 Draft Design”的发布，Go team正在努力着手解决Go社区反响较为强烈的Error handling、Error values和Generics（泛型）这三个问题。从目前的进展上来看，Go error value相关机制的改善近期率先在以Proposal形式出现，并给出了待社区反馈的参考实现(golang.org/x/exp/xerrors)，并很可能是继Go module之后第二个落地的Go2 特性。在本文中，我们就和大家一起来前瞻性探索一下Go2 error inspection及其参考实现。

一. Go2要解决关于Error的哪些问题

从全局角度，Go亟需解决的关于Error的问题包含两个大的方面，一个是Error handling机制，即尝试解决代码中大量重复出现下面代码的问题：

if err != nil {

   .... ....

}

第二个要解决的就是有关测试error变量值，并根据error变量值来选择后续代码执行路线的问题（面向机器），同时也要解决如何将error信息更完整、更全面地呈现给人的问题（面向人）。

关于error handling，draft引入了handle和check的新设计机制，该draft目前还在discuss之中；而第二个问题的解决正如我们前面提到的，已经率先成为Proposal并给出了参考实现，也是我们在本文中要重点探讨的内容。

Go error最初被创新地设计为一个interface：

type error interface {

    Error() string

}

这种设计是符合OCP(open-close principle)的，但是由于在error value test方面相对模糊且在标准库中缺少统一机制，导致gopher们在使用error时体验并不好。这里我们先来回顾一下在这之前我们是如何测试error变量值的。

1. 与预先定义好的知名error变量进行值相等测试 （以下称方法1）

如下面例子中，我们通过将ReadByte调用返回的err与io包中预定义的error变量: EOF(var EOF = errors.New(“EOF”))进行值测试，并根据测试结果选择接下来的代码执行路线：

func main() {
    reader := strings.NewReader("string reader buffer demo")

    for {
        s, err := reader.ReadByte()
        if err == io.EOF {
            fmt.Println("end")
            return
        } else if err != nil {
            fmt.Println(err)
            return
        }
        fmt.Printf("%c\n", s)
    }
}

对于预先已经定义的error变量，这样的error test方法是非常自然的，多数程序员从学习C语言那个时候就已经熟知该方法了。但是这种方法的局限就在于“扩展不足”。这些预定义好的error变量要么在标准库中，要么在依赖的第三方包中，我们只能使用这么多且这些变量所携带的信息有限。如果包中没有预定义或是想让这些变量携带更多对程序员有益的错误信息，我们就还得用其他办法来做error变量的值测试和扩展定义。

**2. 使用type assertion和type switch来测试是否是某种error的实现 **

标准库中net包中OpError的一些method中就采用了这种方式：

// $GOROOT/src/net/net.go

func (e *OpError) Timeout() bool {
    if ne, ok := e.Err.(*os.SyscallError); ok {
        t, ok := ne.Err.(timeout)
        return ok && t.Timeout()
    }
    t, ok := e.Err.(timeout)
    return ok && t.Timeout()
}

一些包还提供了一些专用方法来测试判定特定的error实现类型，比如：os包提供的IsNotExist、IsPermission等方法。不过这些方法在实现层面也都是使用的type assertion。

**3. 通过字符串匹配 **

由于缺少标准的、统一的error变量的值测试方法，尤其是针对重新wrapped的error变量(加上自己了的context信息，隐藏了underlying的error变量类型信息)，在上述两种方法都无法使用的情况下，基于error变量Error()方法返回的string进行字符串匹配来进行error变量测试的手段成为了广大Gopher最后的“救命稻草”，但是这种方法也是最为“丑陋”的，是Go team最不希望gopher们使用的。

// 一个demo，现实中可能不存在这样的逻辑

func writeTxtFile(path string, content string) error {
    f, err := os.OpenFile("notes.txt", os.O_RDWR, 0755)
    if err != nil {
        return fmt.Errorf("open txt file: %s failed, reason: %s", path, err.Error())
    }

    defer f.Close()

    // ... write something
    _, err = f.Write([]byte(content))
    if err != nil {
        return fmt.Errorf("write to txt file: %s failed, reason: %s", path, err.Error())
    }

    return nil
}

func main() {
    err := writeTxtFile("./notes.txt", "write txt test")
    if err != nil {
        s := err.Error()
        if strings.Contains(s, "open txt file") {
            fmt.Println("open txt file error:", s) //但是我们仍然无法根据打开txt文件的具体原因类型(比如权限、还是文件不存在)做出相应的动作
            return
        }

        if strings.Contains(s, "write to txt file") {
            fmt.Println("write txt file error:", s)
            return
        }
    }
}

归根结底，fmt.Errorf提供的error wrap功能将最原始的error信息隐藏了起来，使得我们没有办法通过方法1或2来对wrapped的error变量进行值测试。这也是go2 error新方案要解决的问题。

二. xerrors的使用

下面我们来结合一下参考实现golang.org/x/exp/xerrors来看看该proposal是如何解决上述问题的。

1. wrapping error变量的创建

从前面的问题描述，我们知道Go2亟需提供一种简单的、标准的包裹(wrap)其他error变量并生成新error变量的方法，生成的新error变量中将包含被wrapped的error变量的信息：

xerrors通过Errorf来提供这个功能。下面是参考上图函数调用和error变量包裹关系的一个Demo：

//github.com/bigwhite/experiments/xerrors/wrapper/wrapper1.go

func function4() error {
    return xerrors.New("original_error")
}

func function3() error {
    err := function4()
    if err != nil {
        return xerrors.Errorf("wrap3: %w", err)
    }
    return nil
}

func function2() error {
    err := function3()
    if err != nil {
        return xerrors.Errorf("wrap2: %w", err)
    }
    return nil
}

func function1() error {
    err := function2()
    if err != nil {
        return xerrors.Errorf("wrap1: %w", err)
    }
    return nil
}

func main() {
    err := function1()
    if err != nil {
        fmt.Printf("%v\n", err)
        return
    }

    fmt.Printf("ok\n")
}

通过xerror.Errorf对已知error变量进行包裹后，返回的error变量所归属的类型实现了error、xerrors.Formatter和xerrors.Wrapper接口，携带了被包裹(wrap)变量的信息，而传统的通过fmt.Errorf生成的error变量仅仅实现了error接口，没有被包裹的error变量的任何信息。这些携带的信息将在后续error变量值测试时(Is和As)以及error变量信息展示时被充分利用。

我们运行一下上面的demo(默认得到单行的错误信息输出)：

$go run wrapper1.go
wrap1: wrap2: wrap3: original_error

如果使用”+v%”输出error信息，我们将得到下面输出(多行)：

$go run wrapper1.go
wrap1:
    main.function1
        /Users/tony/go/src/github.com/bigwhite/experiments/xerrors/wrapper/wrapper1.go:32
  - wrap2:
    main.function2
        /Users/tony/go/src/github.com/bigwhite/experiments/xerrors/wrapper/wrapper1.go:24
  - wrap3:
    main.function3
        /Users/tony/go/src/github.com/bigwhite/experiments/xerrors/wrapper/wrapper1.go:16
  - original_error:
    main.function4
        /Users/tony/go/src/github.com/bigwhite/experiments/xerrors/wrapper/wrapper1.go:10

我们看到”+v%”还输出每个错误变量生成时的位置信息，这是因为xerrors.Errorf生成的变量类型:wrapError中携带了“位置信息(frame Frame)”：

// golang.org/x/exp/xerrors/fmt.go

type wrapError struct {
    msg   string
    err   error
    frame Frame
}

上面的demo仅是为了演示通过xerrors.Errorf wrap的error variable携带了error chain的信息，并可以输出这些信息。下面我们来看看在函数调用的外部，如何对wrapped error variable进行各种值test。

2. error value test

对应上面提到方法1(等值测试)和方法2(type断言的类型测试)，xerrors提供了对应的Is和As方法，这两个方法最大的不同就是可以针对wrapped error变量，在变量的error chain上做逐个进行测试，只要某个chain上的error变量满足要求，则返回true。我们分别来看看！

1) Is方法

xerrors的Is方法原型如下：

func Is(err, target error) bool

Is会将target与err中的error chain上的每个error 信息进行等值比较，如果相同，则返回true。我们用下面这幅图来诠释一下其原理:

对应的测试代码见下面：

// github.com/bigwhite/experiments/xerrors/errortest/errortest1.go

func main() {
    err1 := xerrors.New("1")
    err2 := xerrors.Errorf("wrap 2: %w", err1)
    err3 := xerrors.Errorf("wrap 3: %w", err2)

    erra := xerrors.New("a")

    b := xerrors.Is(err3, err1)
    fmt.Println("err3 is err1? -> ", b)

    b = xerrors.Is(err2, err1)
    fmt.Println("err2 is err1? -> ", b)

    b = xerrors.Is(err3, err2)
    fmt.Println("err3 is err2? -> ", b)

    b = xerrors.Is(erra, err1)
    fmt.Println("erra is err1? -> ", b)
}

运行结果：

err3 is err1? ->  true
err2 is err1? ->  true
err3 is err2? ->  true
erra is err1? ->  false

2) As方法

Is方法是在error chain上做值测试。有些时候我们更方便做类型测试，即某一个err是否是某error类型。xerror提供了As方法：

func As(err error, target interface{}) bool

As会将err中的error chain上的每个error type与target的类型做匹配，如果相同，则返回true，并且将匹配的那个error var的地址赋值给target，相当于通过As的target将error chain中类型匹配的那个error变量析出。我们也用下面这幅图来诠释一下其原理:

对应的测试代码见下面：

// github.com/bigwhite/experiments/xerrors/errortest/errortest2.go

type MyError struct{}

func (MyError) Error() string {
    return "MyError"
}

func main() {
    err1 := MyError{}
    err2 := xerrors.Errorf("wrap 2: %w", err1)
    err3 := xerrors.Errorf("wrap 3: %w", err2)
    var err MyError

    b := xerrors.As(err3, &err)
    fmt.Println("err3 as MyError? -> ", b)
    fmt.Println("err is err1? -> ", xerrors.Is(err, err1))

    err4 := xerrors.Opaque(err3)
    b = xerrors.As(err4, &err)
    fmt.Println("err4 as MyError? -> ", b)
    b = xerrors.Is(err4, err3)
    fmt.Println("err4 is err3? -> ", b)
}

运行结果:

err3 as MyError? ->  true
err is err1? ->  true
err4 as MyError? ->  false
err4 is err3? ->  false

我们看到As方法从err3的error chain中匹配到MyError类型的err1，并将err1赋值给err变量析出。在后续的Is测试也证实了这一点。代码中还调用了xerrors的Opaque方法，该方法将传入的支持unwrap操作的error变量转换为一个不支持unwrap的类型的error变量。在最后的对err4（通过Opaque调用得到)的测试我们也可以看到：err4无法匹配MyError type，与err3的等值测试也返回false。

三. 小结

以上就是xerrors提供的有关Go2 error inspection机制的主要功能。注意：xerrors及其proposal仍然可能会变动(包括设计和具体的实现)，因此这里不能保证本文demo示例在后续的版本中依然可以编译运行。本文中的示例代码可以在这里得到。

目前go官方的golang.org/x/exp repo中有两个版本的实现：golang.org/x/exp/errors和golang.org/x/exp/xerrors。差别在于前者没有提供errors.Errorf。如果我们将wrapper1.go中的xerrors换成golang.org/x/exp/errors，则会在编译的时候出现下面错误：

$go run wrapper1.go
go: finding golang.org/x/exp/errors latest
go: downloading golang.org/x/exp/errors v0.0.0-20190125153040-c74c464bbbf2
# command-line-arguments
./wrapper.go:15:10: undefined: errors.Errorf
./wrapper.go:16:10: undefined: errors.Errorf
./wrapper.go:27:10: undefined: errors.Errorf
./wrapper.go:28:10: undefined: errors.Errorf

从官方的说明情况来看，golang.org/x/exp/errors将来要么进化到golang.org/x/errors，并作为Go标准库的vendor(类似于http/2) 包；要么直接merge到Go标准库中，然后该库作废（类似于vgo)。无论哪种形式，errors在merge后，会由fmt.Errorf来提供xerrors.Errorf的功能。

而golang.org/x/exp/xerrors则是可以用于任何版本的。

目前Go team给出的初步计划是在Go 1.13 dev cycle中将该Go 2 error inspection机制加入到main branch，并就像当年的http/2、vgo一样期待Gopher社区对该机制的反馈、然后优化，直到成熟并被广大Gopher所接受。

我的网课“Kubernetes实战：高可用集群搭建、配置、运维与应用”在慕课网上线了，感谢小伙伴们学习支持！

我要发短信：企业级短信平台定制开发专家 https://tonybai.com/
smspush : 可部署在企业内部的定制化短信平台，三网覆盖，不惧大并发接入，可定制扩展； 短信内容你来定，不再受约束, 接口丰富，支持长短信，签名可选。

著名云主机服务厂商DigitalOcean发布最新的主机计划，入门级Droplet配置升级为：1 core CPU、1G内存、25G高速SSD，价格5$/月。有使用DigitalOcean需求的朋友，可以打开这个链接地址：https://m.do.co/c/bff6eed92687 开启你的DO主机之路。

我的联系方式：

微博：https://weibo.com/bigwhite20xx
微信公众号：iamtonybai
博客：tonybai.com
github: https://github.com/bigwhite

微信赞赏：

商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。