这确实是iOS订阅开发里非常常见的痛点——用户修改设备时间来绕过订阅过期限制的情况，用本地时间判断肯定不靠谱！下面给你梳理下可行的解决思路：

核心原则：绝对不要依赖设备本地时间 #

设备时间完全由用户掌控，不管是手动修改还是通过其他手段篡改，都不能作为判断订阅是否活跃的依据。必须用可信的服务器端时间来做对比。

具体解决方案 #

1. 利用苹果收据中的可信时间字段 #

当你获取到苹果的收据响应后，里面有几个关键的时间字段是苹果服务器生成的，完全可信：

• expires_date_ms：订阅到期时间的UTC毫秒时间戳（对应最新订阅记录的到期时间）
• request_date_ms：苹果服务器处理你这次验证请求的UTC时间戳

你可以把这些字段转换成UTC日期，然后和可信的当前时间对比。但这里的关键是：不能用设备时间来做这个对比，必须获取服务器端的当前UTC时间。

2. 获取可信的当前时间的两种方式 #

• 方式一：调用你的后端接口获取当前时间
  这是最直接的方案。你的后端服务器维护着准确的UTC时间，设备端发起一个简单的请求，拿到后端返回的当前UTC时间后，再和收据里的expires_date_ms转换后的日期做对比，判断订阅是否仍在有效期内。

• 方式二：复用苹果验证接口返回的request_date_ms
  如果你是直接和苹果服务器做收据验证，苹果返回的响应里的request_date_ms就是苹果服务器处理请求的时间，这个时间是绝对可信的。你可以用这个时间作为“当前时间”的参考，对比订阅的到期时间。不过要注意，这个时间是你发起验证请求的时间，如果用户在验证之后修改设备时间继续使用，你需要定期重新验证收据，更新状态。

3. 进阶优化：把收据验证逻辑移到后端 #

你也提到了，本地验证收据并非最优方案——不仅有设备时间的问题，还存在用户篡改本地收据的风险。最安全的做法是：设备端把收据数据发送给你的后端服务器，由后端去和苹果服务器做验证，然后后端用自己的可信时间判断订阅状态，再把结果返回给设备端。这样设备端完全不需要处理时间校验和收据验证，只负责展示后端返回的订阅状态，从根源上避免了设备端的各种篡改问题。

额外注意事项 #

• 处理自动续期订阅时，一定要取latest_receipt_info数组里的最后一条记录，这才是用户当前有效的订阅信息，用它的expires_date_ms来判断到期时间。
• 如果订阅处于免费试用或intro期，也要结合is_trial_period、is_in_intro_period这些字段，但时间判断的核心逻辑还是不变。

内容的提问来源于stack exchange，提问作者passingnil