必须先完成vivo健康开放平台oauth2授权并正确配置权限，php通过bearer令牌调用/v1/health/sleep/list（毫秒时间戳）或心率接口，token需持久化存储并及时刷新。
调用 vivo 健康开放平台前必须确认授权流程走通
PHP 本身不能直接获取用户睡眠或心率数据，所有数据都得通过 vivo 健康开放平台的 OAuth2 授权 + API 调用链完成。如果你还没拿到 vivo 开放平台的 client_id 和 client_secret，或者没在后台配置好回调域名和权限范围（比如 health.sleep.read、health.heart_rate.read），后续任何 PHP 请求都会返回 {"code":4001,"msg":"invalid access_token"} 或 403 Forbidden。
实操建议：
- 先在
https://dev.vivo.com.cn/health创建应用，勾选「睡眠数据」和「心率数据」两个接口权限 - 授权时
scope参数必须显式带上health.sleep.read health.heart_rate.read，少一个，后续调用/v1/health/sleep/list就会 403 - PHP 中用
curl或GuzzleHttp\Client发起请求时，Authorization头必须是Bearer <access_token></access_token>，不是Basic也不是token=xxx
用 PHP 获取用户最近一次睡眠记录的正确写法
vivo 健康平台的睡眠数据接口是 GET /v1/health/sleep/list，它不支持单条查询，只能按时间范围拉取列表，再取第一条当“最近一次”。很多人卡在参数拼错或时间戳格式不对——它要求 start_time 和 end_time 是毫秒级时间戳（不是秒级），且 end_time 必须大于 start_time，差值还不能超过 30 天。
实操建议：
- 用
round(microtime(true) * 1000)生成毫秒时间戳，别用time() * 1000（会少三位） - 查询最近 24 小时睡眠：把
start_time设为$now - 24 * 60 * 60 * 1000，end_time设为$now - 响应体里真正数据在
data.list[0]下，不是直接在data里；字段如sleep_start_time、sleep_end_time也是毫秒时间戳
curl -X GET "https://openapi.vivo.com.cn/v1/health/sleep/list?start_time=1715212800000&end_time=1715385600000" \ -H "Authorization: Bearer xxxxx"
心率数据分实时与历史，PHP 要区分调用方式
vivo 平台把心率拆成两个接口：GET /v1/health/heart_rate/realtime（实时，最多返回最近 1 条）和 GET /v1/health/heart_rate/list（历史，按天聚合）。很多人误以为实时接口能拉出全天数据，结果只拿到一个 value: 72 就以为失败了。
实操建议：
- 要全天趋势图？必须用
/v1/health/heart_rate/list，传date=20240501（格式固定为 YYYYMMDD） - 实时接口响应快但数据稀疏，通常只有设备刚同步过才有值；若返回
{"code":200,"data":{"list":[]}}，说明用户当天没测过或没同步 - 历史接口返回的
data.list每项含time（分钟级时间戳，如1714521600）、value（心率值）、type（1=静息，2=运动）
错误码 40001、40003 和 token 过期处理最常被忽略
40001（invalid appid）通常是 client_id 写错或应用状态为“未上线”；40003（invalid refresh_token）则意味着你拿旧的 refresh_token 去换新 access_token 失败了——vivo 的 refresh_token 30 天有效，且每次刷新后原 token 作废，但 PHP 代码里如果没更新本地存储的 refresh_token，下次就必然失败。
实操建议：
- 别把
access_token和refresh_token存 PHP session，要用持久化存储（如 Redis 或数据库），并带更新时间戳 - 每次调用 API 前检查
access_token是否过期（vivo 返回的expires_in是 7200 秒），过期就用refresh_token调POST /oauth2/token换新 - 换 token 成功后，务必把新的
refresh_token写回存储——这是 90% 的 token 失效问题根源
平台对频率限制很严：单个 access_token 每分钟最多 60 次请求，超了就返回 429 Too Many Requests，且没有重试头信息，得自己加退避逻辑。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
