1、解释下G、M、P分别代表什么？ G：是goroutine的缩写，一个G代表一个Go代码片段； M：是machine的缩写，一个M代表一个内核线程，也称工作线程； P：是processor的缩写，一个P代表执行一个Go代码片段所必须的资源； 2、使用go关键字生成的goroutine是放置在P中，还是M中？ 当一个G被创建并初始化完成后会立即被存储到本地P的runnext字段中，因为G必须先被添加入到P的可以运行G队列中才能在M中运行。

JWT（JSON Web Token）是一种用于在网络环境中进行安全信息传递的开放标准 完整的JWT由三部分组成，其结构可以表示为xxxxxx.yyyyyy.zzzzzz格式。 头部（Header）： 通常包含令牌的类型和加密算法； 载荷（Papload）： 包含自定义的数据如用户信息，权限等； 签名（Signature）： 作用是用来验证消息的完整性和真实性，防止消息被篡改； JWT是无状态的，服务器不需要为其保存会话信息，从而减轻了服务器的存储压力，但同时也意味着一旦泄露任何请求都会被允许，而常用的解决方法是给JWT设置不固定的过期时间，强制客户端过期重新获取。 JWT另一个特点是，一旦生成后在其过期前都不可再修改其有效期。 它的主要应用场景包括用户身份验证和授权，用户在登录成功后获取JWT后，后续的所有请求都需要携带该JWT向服务器请求资源，服务器则可以根据这个JWT来验证用户的有效性。

1、什么情况下会使用空struct，它会分配内存吗？ 空结构体 struct{} 是一个特殊的结构体，它没有字段属性，一些常见的使用场景包括：集合、实现接口、信号传递。 Go语言没有内置的集合类型，但是我们可以使用map[T]struct{}来模拟集合，因为struct{}不占用空间，因此只需要存储键，能节省内存。 空结构体还可以用来实现没有方法的接口，这中接口通常用于占位符或标记的用途。 type NoMethodInterface interface { } type EmptyStruct struct{} type AnotherEmptyStruct struct{} func process(i NoMethodInterface) { // 什么也不干，占位，将来可以扩展 } // 因为NoMethodInterface接口没有任何方法，所以任何类型都被认为是这个接口的实现，包括空结构体EmptyStruct func main() { var empty EmptyStruct var another AnotherEmptyStruct // 同一接口的两种不同的实现方式 process(empty) process(another) } 在Go的并发编程中，使用 chan struct{} 来传递信号，由于 struct{} 不占用内存，因此可以高效的用于信号传递而无需携带任何额外的数据。 最后，空结构体 struct{} 在实例化的时候并不会分配内存，每个空结构体的实例在内存中占用0个字节，即使在一个集合中存储了多个struct{}实例，它们也不会占用额外的内存空间而只会占用集合本身存储键所需要的内存空间。 2、Go中接口有什么用，如何实现？ 接口的精髓在于抽象和多态度，接口允许我们定义一个行为的集合，而不关心实现这些行为的具体类型，这样我们就可以编写更加抽象的代码，当我们需要改变具体实现时，不需要修改使用接口的代码，对调用者做到了透明。接口使得不同类型可以实现相同的方法，从而通过接口类型的变量来引用不同的具体实现，这种特性大大增加了代码的灵活性和可扩展性。此外，接口还有利于代码解耦，它定义的是一组行为而不是具体实现，使得不同实现可以通过接口进行通信，从而减少了模块之间的耦合。 Go接口的实现非常简单，只需要实现接口中定义的所有方法即可。 Go源码中最通俗易懂的实现之一就是标准库中的 io.Writer 接口： package io type Writer interface { Write(p []byte) (n int, err error) } io.Writer接口非常简洁，只有一个Write方法，任何实现了Write方法的类型都可以被视为io.Writer，例如标准库中的os.File类型就实现了Writer接口：

顾名思义，中间人攻击就是指通信双方的对话内容被第三个人窃取了。 回想抗日谍战剧里潜伏在敌人内部的情报员是如何将获得的重要情报传递给后方根据地的？ 情报员获得情报后通过某种加密手段将情报内容加密后再传递给根据地，根据地同志在获得了情报后再用事先商量好的密钥解密情报以获取情报的真正内容。 该过程的优势是即使敌人获取到了被加密的情报也无法获取情报里真正的内容，但是，如果敌人知道了我们的加解密方法的话那就很容易知道情报的内容了。 中间人攻击就类似上图一样，左右两边的用户聊得正嗨，却不知道他们的聊天内容正在被头顶的人偷窥呢。 现在回过头来说HTTPS中间人攻击，既然HTTPS是加密通信，那中间人是如何窃取到对话信息的呢？ 这就需要了解HTTPS加密的过程了，我们假设小明和小花之间的对话采用了某种加密方法，在他们之间传递的都是密文，他们拿到密文后再各自用事先约定好的密钥来解密，当然这个密钥也是通过网络传递的，不是小明事先亲手偷偷的交给小花的，正常情况下的通信过程是： 1、小花把自己的公钥public key 1发送给小明； 2、小明用这个公钥 public key 1加密他和小花通信的真正密钥S，加密后叫S1； 3、小明把S1发送给小花； 4、小花用自己的私钥private key 1解密S1，,现在小花得到了S； 5、后续小明和小花就用这个密钥S进行通信了。 现在假设有一个中间人，也不知道他用什么方法拿到了小花的公钥，现在小明和小花的通信过程变成了下面这样： 1、小花在把自己的公钥public key 1传递给小明的时候被中间人调包了； 2、中间人把自己的公钥public key 2发给了小明； 3、小明现在有中间人给的公钥public key 2； 4、小明用这个中间人公钥 public key 2加密他和小花通信的真正密钥S，加密后叫S1； 5、小明把S1发送给小花，实际发送给了中间人； 6、中间人用自己的私钥private key 2解密了S1获得了S； 7、中间人拿到S后再用小花的公钥public key 1重新加密S得到S2； 8、中间人把S2发给了小花； 9、小花用自己的私钥private key 1解密S2，,现在小花得到了S； 10、后续小明和小花就用这个密钥S进行通信了； 但是因为此时中间人已经拥有了小明和小花的真正密钥S，所以他们之间的加密通信内容也能被中间人一览无余了。

虽然通过苹果的StoreKit2框架客户端可以直接处理整个支付流程，不再需要验证票据了，但是绝大多数业务场景都需要再服务器端再次验证支付逻辑，这时我们就需要解析苹果服务器到服务器到支付通知了，这里只说明通知数据结构的解析，具体可以分为如下三步来实现： 第1步：苹果服务器POST过来的JSON数据： { "signedPayload": "eyJhbGciOiJF这里是被加密的内容eyJhbGciOiJF" } 第2步：按照苹果官方提供的方法提取出signedPayload的内容如下： { "notificationType" : "DID_RENEW", "subtype" : "子类型", "notificationUUID" : "f2d65c0c-4980-4211-9d02-d104959a468e", "data" { "appAppleId" : 706*****38, "bundleId" : "App的Bundle Id标志符", "bundleVersion" : "20230506165910", "environment" : "Sandbox", "signedTransactionInfo" : "eyJhbGc加密的交易信息zV1Q", "signedRenewalInfo":"eyJhbGciO加密的续费信息giG29hdGA", "status" : 1 }, "version" : "2.0", "signedDate" : 1717485836523 } 其中notificationType字段表示通知的具体类型，共有18种可能的情况 ： 1、CONSUMPTION_REQUEST - 消费者发起了一个【退款/自动续期订阅】请求 2、DID_CHANGE_RENEWAL_PREF - 结合subtype字段【UPGRADE/DOWNGRADE】决定消费者修改了订阅计划，如果subtype字段为空表示该回至当前状态 3、DID_CHANGE_RENEWAL_STATUS - 结合subtype字段【AUTO_RENEW_ENABLED/AUTO_RENEW_DISABLED】一起决定订阅续期状态变化，如果用户发起了退款请求则App Store也会禁用自动续期 4、DID_FAIL_TO_RENEW - 结合subtype字段【GRACE_PERIOD/空】一起决定服务端是否可以停服务了，如还处在GRACE_PERIOD宽限期内不要停服务，否则可以收回服务了 5、DID_RENEW - 结合subtype字段【BILLING_RECOVERY/空】一起决定服务端是否可以提供服务了，subtype值为BILLING_RECOVERY表示上次过期的订阅自动续期成了，为空表示一个新的自动续期订阅成功了 6、EXPIRED - 结合subtype字段【VOLUNTARY/BILLING_RETRY/PRICE_INCREASE/PRODUCT_NOT_FOR_SALE/空】一起决定订阅过期原因，分别表示用户自主取消/上一个账单自动续期失败/用户不同意涨价/商品不再处于销售状态/其它原因 7、EXTERNAL_PURCHASE_TOKEN - 结合subtype字段【EXTERNAL_PURCHASE_TOKEN】仅启用了外部支付才有此值 8、GRACE_PERIOD_EXPIRED - 宽限期已结束还是无法扣款成功，服务端可以取消服务了 9、OFFER_REDEEMED - 结合subtype字段【INITIAL_BUY/RESUBSCRIBE/UPGRADE/DOWNGRADE/空】一起决定消费者使用了促销优惠或优惠码，分别表示第一次使用优惠码/非首次使用优惠码/用优惠码升级/用优惠码降级/用优惠码再次购买当前已买且有效的服务 10、PRICE_INCREASE - 结合subtype字段【PENDING/ACCEPTED】一起决定消费者是否同意服务涨价，分别表示待处理/接受涨价 11、REFUND - 表明App Store已经成功处理了一笔退款 12、REFUND_DECLINED - 表明App Store拒绝了开发发起的退款请求 13、REFUND_REVERSED - 表明App Store撤销了之前因消费者争议而产生的退款请求，需要继续提供服务 14、RENEWAL_EXTENDED - 表明App Store扩展了某个订阅的续订日期 15、RENEWAL_EXTENSION - 结合subtype字段【SUMMARY/FAILURE】一起决定App Store正尝试调用为所有活动订阅者延长订阅日期 16、REVOKE - 表明家庭共享服务关闭，不可再共享了 17、SUBSCRIBED - 结合subtype字段【INITIAL_BUY/RESUBSCRIBE】一起决定消费者订阅了一个产品，分别表示第一次订阅或通过家庭共享访问/非第一次 18、TEST - 表明App Store发送了一个测试通知，你请求了Test Notification API