企业官网建设流程全解析

1. 项目概述：为什么需要Java调用保利威视频数据同步

“java调用保利威视频文件数据信息同步”这个标题，表面看是个技术接口调用任务，但背后实际承载着一套典型的企业级音视频内容治理闭环需求。我接触过多个教育类、培训类和SaaS服务型客户，他们普遍面临一个共性痛点：视频上传到保利威后台后，前端页面展示的标题、时长、封面、状态、播放次数等元数据，和业务系统（比如教务系统、课程CMS、用户学习记录平台）里的对应字段长期不同步——老师改了视频标题，学员端看不到；管理员下架了违规视频，后台订单系统仍显示“可观看”；甚至出现过因时长字段未更新，导致按分钟计费的课程包多扣费的客诉事件。

这个问题的本质，不是“能不能调”，而是“怎么稳、怎么准、怎么可持续地调”。保利威提供的是标准RESTful API体系，但它的接口设计逻辑和业务系统天然存在三重错位：第一是语义错位——保利威的“video_id”在业务系统里可能叫“course_material_id”，字段映射必须人工对齐；第二是时效错位——保利威的异步转码完成回调（callback）和主动轮询（polling）机制，与业务系统要求的“秒级可见”存在天然延迟；第三是容错错位——保利威API返回的错误码（如40012表示“视频不存在”，40033表示“签名过期”）在Java工程中若不做分级兜底，一次网络抖动就可能导致全量同步中断，后续数据雪崩式偏移。

所以，这个项目真正要解决的，不是写几行HttpURLConnection代码，而是一套带状态追踪、幂等控制、失败回溯、日志可溯的轻量级同步中间件。它适合两类人直接参考复现：一类是正在做在线教育、知识付费或企业内训系统的Java后端开发者，手头正卡在视频数据割裂问题上；另一类是技术负责人，需要评估第三方音视频平台对接的真实成本——别被“开放API”四个字忽悠了，真正的难点永远在异常流、边界条件和长期运维上。接下来我会从整体架构设计、核心参数解析、实操代码拆解、典型故障排查四个维度，把我们在线上稳定运行18个月的同步模块完整还原出来，不讲虚的，只说踩过的坑和验证过的解法。

2. 整体设计思路与方案选型逻辑

2.1 同步模式选择：推还是拉？为什么最终放弃Webhook

刚接手这个需求时，团队第一反应是“用保利威的Webhook推送”。毕竟官方文档明确写了支持“视频上传完成”“转码成功”“审核通过”等7类事件回调，听起来最省事。但我们做了三天压测就放弃了——根本原因在于事件不可靠、顺序无保障、重试无策略。

保利威的Webhook机制在实际生产中暴露三个硬伤：第一，事件丢失率真实存在。我们在测试环境模拟弱网（丢包率5%），连续触发100次上传，有7次回调完全没到达，且保利威后台不提供“未送达事件查询”功能；第二，事件乱序无法避免。比如一个视频先触发“上传完成”，1秒后触发“转码成功”，但在高并发场景下，后者可能比前者早100ms到达，如果业务系统按时间戳入库，就会存入一个“已转码但未上传”的荒谬状态；第三，重试机制形同虚设。官方只承诺“最多重试3次”，但不告知重试间隔（实测是30s/60s/120s），更不提供“重试失败后转入死信队列”的能力。一旦某次回调因业务系统临时宕机失败，这单数据就永久掉线。

权衡之后，我们转向**“主动拉取+事件驱动”混合模式**：日常用定时任务轮询（每5分钟查一次“最近2小时新增/变更视频”），关键节点（如管理员手动点击“发布”按钮）则由前端触发一次即时同步。这样既规避了Webhook的不可控性，又比纯轮询节省90%的API调用量。计算依据很实在：保利威API调用配额按月计费，基础版每月5万次，而我们日均视频增量约300条，纯5分钟轮询（24×12=288次/天）年消耗仅10.5万次，远超配额；但混合模式下，95%的变更由业务动作触发，轮询仅作兜底，实测年消耗降至1.8万次以内。

2.2 架构分层设计：为什么坚持“三隔离”原则

很多团队一上来就写个Service类把所有逻辑塞进去，结果半年后没人敢动——因为鉴权、参数拼装、HTTP通信、JSON解析、业务映射全搅在一起。我们强制执行“三隔离”：协议层隔离、数据层隔离、业务层隔离。

• 协议层：封装保利威所有API的通用调用规范。包括统一的签名生成（HMAC-SHA256）、请求头组装（Content-Type、X-Nonce、X-Timestamp）、响应体解析（统一处理4xx/5xx错误码并转换为自定义异常）。这里的关键细节是时间戳精度必须毫秒级，保利威校验逻辑要求X-Timestamp与服务器时间误差≤300秒，但若Java用System.currentTimeMillis()直接拼接，高并发下可能出现同一毫秒内多次请求，导致签名重复被拒。我们的解法是在时间戳后追加4位随机数（String.format("%d%04d", System.currentTimeMillis(), new Random().nextInt(10000))），既保证唯一性，又不破坏时间校验逻辑。

• 数据层：定义两套POJO。一套是PolyvVideoRaw，严格按保利威API返回字段命名（如videoId、duration、status），用于接收原始响应；另一套是CourseMaterial，按业务系统字段命名（如materialId、playTime、publishStatus）。两者之间用MapStruct做零反射映射，避免手写setter带来的维护成本。特别注意status字段：保利威返回数字码（0=草稿，1=审核中，2=已发布，3=已下架），而业务系统用枚举PublishStatus.DRAFT/REVIEWING/PUBLISHED/ARCHIVED，映射时必须做双向转换，否则数据库存入数字码会导致后续SQL查询失效。

• 业务层：只处理“什么该同步”和“同步失败怎么办”。比如判断视频是否需更新：不是简单比对videoId，而是计算lastUpdateAt时间差，若保利威返回的更新时间比本地库新3秒以上，才触发更新（规避时钟漂移）。再如失败处理：首次失败记录日志并告警；重试3次仍失败，自动将该videoId写入Redis的sync_failed_queue，由独立消费者每小时扫描并邮件通知责任人——这个设计让故障发现从“被动报修”变成“主动预警”。

2.3 工具链选型：为什么不用Spring Cloud OpenFeign

看到“Java调用API”，很多人本能想到OpenFeign。但我们线上环境明确禁用，原因有三：第一，OpenFeign的默认超时太短。其connectTimeout和readTimeout默认都是10秒，而保利威的“查询视频详情”接口在高清视频多码率场景下，平均响应达3.2秒，P95达8.7秒，10秒超时会导致约12%的请求被误判为失败；第二，错误解码器（ErrorDecoder）扩展成本高。保利威的400错误体是{"code":40012,"error":"video not found"}，而OpenFeign默认把400当业务异常抛出，需重写ErrorDecoder逐个匹配code字段，工作量大且易漏；第三，线程模型不匹配。OpenFeign底层用HttpClient，每个实例持有一个连接池，而我们的同步任务是定时调度（Quartz），若为每次任务新建FeignClient，连接池无法复用，频繁创建销毁反而拖慢性能。

最终选用OkHttp + Gson组合：OkHttp的Call.timeout()可精确控制到毫秒级（我们设为15秒），连接池自动复用；Gson的TypeAdapter能针对保利威特殊字段（如duration是字符串"00:12:34"）定制反序列化逻辑，比Jackson的@JsonDeserialize更轻量。最关键的是，我们把OkHttp封装成单例Bean，配合Dispatcher设置最大并发请求数为20（保利威QPS限制为30，留出缓冲），实测在200并发下CPU占用率稳定在35%以下，远优于Feign的65%。

3. 核心参数解析与实操要点

3.1 鉴权三要素：AppId、AppSecret、签名算法的致命细节

保利威API鉴权要求在请求头携带X-Polyv-AppId、X-Polyv-Nonce、X-Polyv-Timestamp、X-Polyv-Signature四字段，其中前三者是基础，最后的Signature才是命门。很多团队卡在这里超过一周，问题全出在签名原文拼接规则和编码陷阱上。

签名原文格式为：AppId=xxx&Nonce=yyy&Timestamp=zzz&AppSecret=www。表面看很简单，但三个坑必须避开：第一，AppSecret不能参与URL编码。保利威文档写“所有参数需URL Encode”，但实测发现AppSecret若被encode（如+变%2B），签名必然失败。我们的解法是单独提取AppSecret，拼接时保持原样；第二，Timestamp必须是字符串而非数字。Java里System.currentTimeMillis()返回long，若直接String.valueOf(time)再拼接，没问题；但若用time + ""，在某些JVM版本下会触发自动装箱，产生不可预知空格；第三，拼接顺序严格固定。必须按AppId→Nonce→Timestamp→AppSecret顺序，少一个等号、多一个空格、字母大小写错（如appid写成AppID），签名即失效。

我们封装的签名工具类核心代码如下：

public class PolyvSignatureUtil { private static final String CHARSET = "UTF-8"; public static String generate(String appId, String nonce, String timestamp, String appSecret) { try { // 拼接原文，注意：AppSecret不URL编码！ String plainText = String.format("AppId=%s&Nonce=%s&Timestamp=%s&AppSecret=%s", URLEncoder.encode(appId, CHARSET), URLEncoder.encode(nonce, CHARSET), URLEncoder.encode(timestamp, CHARSET), appSecret // 关键：此处不encode ); // HMAC-SHA256加密，转小写十六进制 Mac hmacSha256 = Mac.getInstance("HmacSHA256"); SecretKeySpec secretKey = new SecretKeySpec(appSecret.getBytes(CHARSET), "HmacSHA256"); hmacSha256.init(secretKey); byte[] hashBytes = hmacSha256.doFinal(plainText.getBytes(CHARSET)); return bytesToHex(hashBytes).toLowerCase(); } catch (Exception e) { throw new RuntimeException("Signature generation failed", e); } } private static String bytesToHex(byte[] bytes) { StringBuilder result = new StringBuilder(); for (byte b : bytes) { result.append(String.format("%02x", b)); } return result.toString(); } }

提示：测试签名是否正确，最笨但最有效的方法是用Postman手动构造请求头，对比Java生成的Signature和Postman生成的是否一致。我们曾因IDEA编辑器自动把Tab转成4空格，导致拼接字符串多出不可见字符，调试3小时才发现。

3.2 关键接口参数详解：从“查列表”到“取详情”的参数陷阱

保利威视频数据同步涉及两个核心接口：/videos/list（查视频列表）和/videos/view（查单个视频详情）。表面看都是GET请求，但参数设计暗藏玄机。

/videos/list接口必传pageNo和pageSize，看似标准分页，但pageNo从1开始而非0，且pageSize最大值为100（超限返回400错误）。更关键的是startTime和endTime参数：它们要求格式为yyyy-MM-dd HH:mm:ss，且必须是东八区时间（UTC+8）。我们第一次上线时用Instant.now().toString()传入2023-10-01T02:30:00Z，结果返回空列表——因为保利威服务器按北京时间解析，Z后缀被忽略，实际当成2023-10-01 02:30:00查询，而视频创建时间是2023-10-01 10:30:00。解决方案是用ZonedDateTime.now(ZoneId.of("Asia/Shanghai"))生成时间字符串。

/videos/view接口看似简单，只传videoId，但videoId不是保利威控制台看到的“vid”。控制台显示的vid是e3a1b2c3d4e5f6g7h8i9j0k1l2m3n4o5这类32位字符串，而API要求的videoId是e3a1b2c3d4e5f6g7h8i9j0k1l2m3n4o5_1234567890（下划线拼接10位数字）。这10位数字是保利威内部的channelId，普通用户不可见。获取方式只有两种：要么从/videos/list返回的videoId字段直接取（它已经是完整格式），要么调用/videos/get-channel-id接口查——但我们发现后者成功率仅68%，故强制要求所有同步流程必须先调列表接口。

另外，/videos/list返回的duration字段是字符串格式HH:mm:ss，而业务系统需要整型秒数。转换逻辑不能简单用LocalTime.parse()，因为保利威偶尔返回00:00:00（视频未转码完成）或00:00:00.000（含毫秒）。我们的健壮解析方法：

public static int parseDuration(String durationStr) { if (StringUtils.isBlank(durationStr)) return 0; // 移除毫秒部分（如00:00:00.000 → 00:00:00） String cleanStr = durationStr.split("\\.")[0]; try { LocalTime time = LocalTime.parse(cleanStr); return time.getHour() * 3600 + time.getMinute() * 60 + time.getSecond(); } catch (DateTimeParseException e) { log.warn("Invalid duration format: {}", durationStr); return 0; } }

3.3 数据一致性保障：幂等设计与状态机落地

视频数据同步最大的风险不是“调不通”，而是“调多了”——一次视频更新，因网络重试被同步三次，导致业务系统里播放次数+3、更新时间被覆盖为旧值。我们采用双保险幂等机制：请求级幂等 + 业务级幂等。

• 请求级幂等：在每次HTTP请求头添加X-Request-ID，值为videoId + "_" + timestamp（如e3a1..._1712345678901）。保利威虽不校验此头，但我们在Nginx层配置日志，当同一X-Request-ID在5分钟内出现3次，自动触发告警并冻结该videoId的同步任务1小时。这个设计帮我们捕获了73%的客户端重试问题。

• 业务级幂等：在数据库course_material表增加polyv_last_sync_time字段，每次同步前先查此字段。若保利威返回的lastUpdateAt（时间戳）≤ 本地polyv_last_sync_time，直接跳过更新。关键点在于时间戳比较必须用数据库函数，避免Java应用服务器和DB服务器时钟不一致。MySQL写法：WHERE FROM_UNIXTIME(polyv_last_sync_time) < FROM_UNIXTIME(?)。

状态机设计则解决“视频状态流转混乱”问题。保利威的status有4种值，但业务系统要求更细粒度的状态（如“审核中”需区分“初审”和“复审”）。我们定义状态映射表：

每次同步时，不仅更新字段，还检查状态流转合法性。例如：若当前业务状态是DRAFT，保利威返回status=2，但publishTime为空，则拒绝更新，记录告警“保利威状态异常：已发布但无发布时间”。这个校验拦截了12次因保利威后台操作失误导致的数据污染。

4. 实操过程与核心环节实现

4.1 环境准备与依赖配置

项目基于Spring Boot 2.7.18（JDK 11），Maven依赖精简到最低必要集。以下是pom.xml关键片段，删减了所有非核心依赖：

<dependencies> <!-- Web基础 --> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-web</artifactId> </dependency> <!-- 定时任务 --> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-quartz</artifactId> </dependency> <!-- HTTP客户端 --> <dependency> <groupId>com.squareup.okhttp3</groupId> <artifactId>okhttp</artifactId> <version>4.11.0</version> </dependency> <!-- JSON处理 --> <dependency> <groupId>com.google.code.gson</groupId> <artifactId>gson</artifactId> <version>2.10.1</version> </dependency> <!-- Redis缓存（失败队列） --> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-data-redis</artifactId> </dependency> <!-- Lombok（减少样板代码） --> <dependency> <groupId>org.projectlombok</groupId> <artifactId>lombok</artifactId> <optional>true</optional> </dependency> </dependencies>

注意：OkHttp版本必须≥4.9.0，低版本不支持HTTP/2，而保利威API已强制启用HTTP/2，旧版本会静默降级为HTTP/1.1，导致部分接口返回406错误。我们曾因此排查两天，最终抓包发现ALPN协商失败。

配置文件application.yml中保利威相关参数：

polyv: api: base-url: https://api.polyv.net/v2 app-id: your_app_id_here app-secret: your_app_secret_here # 超时设置：连接15秒，读取15秒，写入15秒 timeout: connect: 15000 read: 15000 write: 15000 sync: # 列表查询：每次拉取最近2小时数据 list-time-range-minutes: 120 # 定时任务：每5分钟执行一次 cron: "0 0/5 * * * ?" # 失败重试：最多3次，间隔指数退避（1s, 3s, 9s） max-retry: 3 retry-interval-base: 1000

4.2 核心同步服务代码实现

同步主服务PolyvVideoSyncService采用责任链模式，将“获取数据→校验→转换→持久化→通知”拆分为独立方法，便于单元测试和问题定位：

@Service @Slf4j public class PolyvVideoSyncService { @Autowired private PolyvApiClient polyvApiClient; // 封装OkHttp调用 @Autowired private CourseMaterialMapper courseMaterialMapper; // MyBatis Mapper @Autowired private RedisTemplate<String, Object> redisTemplate; /** * 主同步入口：拉取最近N分钟视频列表并同步 */ @Transactional(rollbackFor = Exception.class) public void syncRecentVideos() { long startTime = System.currentTimeMillis() - TimeUnit.MINUTES.toMillis(120); // 120分钟前 long endTime = System.currentTimeMillis(); // 1. 调用保利威API获取视频列表 List<PolyvVideoRaw> videoList = polyvApiClient.listVideos(startTime, endTime); log.info("Fetched {} videos from Polyv", videoList.size()); // 2. 过滤出需要同步的视频（本地不存在 or 保利威更新时间更新） List<PolyvVideoRaw> needSync = filterNeedSync(videoList); // 3. 批量同步（单个视频详情调用+业务转换+DB更新） needSync.parallelStream() .forEach(this::syncSingleVideo); log.info("Sync completed for {} videos", needSync.size()); } private void syncSingleVideo(PolyvVideoRaw raw) { try { // 3.1 获取视频详情（规避列表接口字段缺失） PolyvVideoDetail detail = polyvApiClient.getVideoDetail(raw.getVideoId()); // 3.2 转换为业务对象 CourseMaterial material = convertToCourseMaterial(detail); // 3.3 检查幂等：若保利威更新时间不新，跳过 if (!isPolyvUpdateTimeNewer(material.getVideoId(), detail.getLastUpdateAt())) { log.debug("Skip sync for video {}, local is newer", material.getVideoId()); return; } // 3.4 持久化 int updated = courseMaterialMapper.updateByVideoId(material); if (updated == 0) { courseMaterialMapper.insert(material); // 新增 } // 3.5 更新本地同步时间戳 updateLocalSyncTime(material.getVideoId(), detail.getLastUpdateAt()); } catch (Exception e) { log.error("Sync failed for video {}", raw.getVideoId(), e); handleSyncFailure(raw.getVideoId(), e); } } private void handleSyncFailure(String videoId, Exception e) { // 写入Redis失败队列，TTL 24小时 String key = "polyv:sync:failed:" + LocalDate.now(); redisTemplate.opsForSet().add(key, videoId); redisTemplate.expire(key, Duration.ofHours(24)); // 发送企业微信告警（简化版） AlertSender.send("保利威同步失败", String.format("videoId:%s, error:%s", videoId, e.getMessage())); } }

4.3 定时任务与失败队列消费

定时任务使用Quartz，配置在QuartzConfig.java中：

@Configuration public class QuartzConfig { @Bean public JobDetail polyvSyncJobDetail() { return JobBuilder.newJob(PolyvSyncJob.class) .withIdentity("polyvSyncJob") .storeDurably() .build(); } @Bean public Trigger polyvSyncTrigger(@Value("${polyv.sync.cron}") String cron) { return TriggerBuilder.newTrigger() .forJob(polyvSyncJobDetail()) .withSchedule(CronScheduleBuilder.cronSchedule(cron)) .build(); } }

对应的PolyvSyncJob仅负责触发服务：

public class PolyvSyncJob implements Job { @Override public void execute(JobExecutionContext context) throws JobExecutionException { // 从Spring容器获取Bean（Quartz不管理Spring Bean生命周期） ApplicationContext applicationContext = (ApplicationContext) context.getScheduler().getContext().get("applicationContext"); PolyvVideoSyncService syncService = applicationContext.getBean(PolyvVideoSyncService.class); syncService.syncRecentVideos(); // 调用主同步方法 } }

失败队列消费者独立为FailedSyncConsumer，每小时扫描一次：

@Component public class FailedSyncConsumer { @Autowired private PolyvVideoSyncService syncService; @Scheduled(fixedDelay = 3600000) // 每小时执行 public void consumeFailedQueue() { String key = "polyv:sync:failed:" + LocalDate.now(); Set<Object> failedIds = redisTemplate.opsForSet().members(key); if (CollectionUtils.isEmpty(failedIds)) return; log.info("Found {} failed videos to retry", failedIds.size()); failedIds.forEach(id -> { try { syncService.syncSingleVideoById((String) id); redisTemplate.opsForSet().remove(key, id); // 成功则移除 } catch (Exception e) { log.error("Retry failed for video {}", id, e); } }); } }

4.4 日志与监控埋点设计

没有日志的同步服务等于裸奔。我们在四个关键节点埋点：

1. 请求发起前：记录X-Request-ID、videoId、API路径、参数摘要（如list?startTime=1712345678&pageSize=50）
2. 响应接收后：记录HTTP状态码、响应耗时(ms)、返回数据量(KB)、首条videoId（避免日志刷屏）
3. 数据库操作后：记录影响行数、videoId、操作类型(insert/update)
4. 异常发生时：记录完整堆栈、保利威错误码（从响应体提取）、videoId

日志格式统一为JSON，便于ELK采集：

{ "timestamp": "2024-04-05T10:30:22.123+0800", "level": "INFO", "thread": "pool-2-thread-1", "logger": "c.p.s.PolyvVideoSyncService", "message": "Sync success", "context": { "requestId": "e3a1b2c3d4e5f6g7h8i9j0k1l2m3n4o5_1712345678901", "videoId": "e3a1b2c3d4e5f6g7h8i9j0k1l2m3n4o5_1234567890", "operation": "update", "rowsAffected": 1, "costMs": 423 } }

监控指标通过Micrometer暴露给Prometheus：

• polyv_api_request_total{method="list",status="200"}：API调用总数
• polyv_api_request_duration_seconds{method="view"}：详情接口P95耗时
• polyv_sync_failed_total{reason="network"}：失败总数（按原因分类）
• polyv_sync_queue_size：Redis失败队列长度

我们设置告警规则：若polyv_sync_failed_total5分钟内增长＞10，或polyv_api_request_duration_secondsP95 ＞ 10秒，立即触发企业微信告警。

5. 常见问题与排查技巧实录

5.1 典型故障速查表

5.2 实操中踩过的5个深坑

坑1：保利威的“审核中”状态会清空duration字段
某次上线后发现大量视频时长变为0，排查发现：当视频处于status=1（审核中）时，保利威API返回的duration是空字符串，而非保留原值。我们的parseDuration()方法遇到空字符串返回0，导致业务系统显示“0秒视频”。解法：在转换逻辑中增加状态判断，若status==1且duration为空，则沿用本地库上次存储的时长值。

坑2：批量同步时MySQL死锁
高峰期并发同步200个视频，数据库出现Deadlock异常。原因是updateByVideoId和insert语句竞争同一行锁。解法：将插入逻辑改为INSERT ... ON DUPLICATE KEY UPDATE，利用唯一索引（videoId）避免锁冲突。MyBatis XML配置：

<insert id="upsertMaterial"> INSERT INTO course_material (...) VALUES (...) ON DUPLICATE KEY UPDATE title=VALUES(title), duration=VALUES(duration), last_update_at=VALUES(last_update_at) </insert>

坑3：时区导致的“未来视频”问题
某天凌晨3点，同步任务拉取到大量publishTime为当天23:59的视频，业务系统判定为“未发布”而隐藏。原因是服务器时区为UTC，而保利威publishTime是北京时间。解法：在PolyvVideoDetail类中，publishTime字段用@JsonAdapter指定时区解析器：

public class PolyvVideoDetail { @JsonAdapter(UtcToLocalAdapter.class) private Long publishTime; // 自动转为本地时间戳 }

坑4：OkHttp连接池耗尽
压测时出现java.io.InterruptedIOException: timeout。jstat显示OkHttpClient连接池满。解法：调整OkHttp连接池参数，在PolyvApiClient初始化时：

OkHttpClient client = new OkHttpClient.Builder() .connectionPool(new ConnectionPool(20, 5, TimeUnit.MINUTES)) // 最大20连接，空闲5分钟释放 .build();

坑5：Gson反序列化丢失字段
/videos/list返回的cover字段有时是字符串（URL），有时是对象{"url":"xxx"}，Gson默认按第一个样本类型解析，导致后续类型不一致时报错。解法：自定义TypeAdapter，统一转为字符串：

public class CoverTypeAdapter implements JsonDeserializer<String> { @Override public String deserialize(JsonElement json, Type type, JsonDeserializationContext context) { if (json.isJsonObject()) { return json.getAsJsonObject().get("url").getAsString(); } else { return json.getAsString(); } } } // 注册：gsonBuilder.registerTypeAdapter(String.class, new CoverTypeAdapter());

5.3 性能优化实测数据

我们对同步模块做了三轮压测，环境为4核8G云服务器，保利威API QPS限制30：

关键优化点：

• 连接池复用：将OkHttpClient设为单例，连接复用率从32%提升至99.7%
• 批量减少请求：/videos/list一次拉取100条，比单条查100次减少99%的网络开销
• 本地缓存：对/videos/view的响应加Guava Cache（10分钟），命中率68%，降低保利威负载

最后分享一个小技巧