海洋 CMS 采集后剧集分集错乱怎么解决

海洋CMS 采集后分集错乱，绝大多数情况不是 CMS 本身有 Bug，而是三件事造成的：采集源返回的集数顺序本身是乱的、播放地址格式不符合「集名$地址」规范、重复采集时旧地址没清空只做了追加。按「先备份 → 清空重采 → 统一地址格式 → 数字排序校验」四步走，基本都能修好。

海洋CMS 采集后分集错乱最常见的原因有哪些？

结论：分集错乱集中在四类原因，按出现频率从高到低是——字典序排序、重复采集叠加、播放地址格式不规范、多播放组串台。

第一类是字典序排序。字符串排序下 第10集 会排在 第2集 前面，列表看起来就是 1、10、11、2、3……这不是数据错，是排序方式错。判断方法很简单：如果乱了之后前 9 集正常、第 10 集开始往前插，基本就是这个原因。

第二类是重复采集叠加。采集程序如果只做 INSERT 不做 DELETE，同一部剧采两次就会出现 1,2,3,4,1,2,3,4,5 这种播放列表。海洋CMS 的采集模块对同一条数据的处理通常有「跳过 / 追加 / 覆盖」几种模式，把它固定成覆盖（更新），不要用追加。

第三类是播放地址格式不统一。海洋CMS 与苹果CMS 同源的播放地址字段格式是 第1集$http://xxx.m3u8#第2集$http://yyy.m3u8，集名和地址之间用 $ 分隔，多集之间用 # 分隔。如果采集源返回的是 第一集、01、EP01 混着来，解析脚本认不出边界，就会串集。

第四类是多播放组串台。同一部剧有「线路1」「线路2」两个播放组时，两个播放器的地址必须分别存在各自的播放组里，一旦合并到同一个播放组，集数就对不齐了。

已经乱掉的老数据怎么批量修复？

结论：老数据不要一条条手改，用「备份 → 定位表 → 按数字重排 → 回写」的方式处理，10 分钟内能修完一部剧。

第一步先备份，命令是 mysqldump -u用户名 -p 数据库名 > backup.sql，这一步不能省，改错了只能靠它回滚。

第二步定位播放地址存在哪。海洋CMS 不同版本表结构有差异，老版本常见的是 sea_data（影片主表）加 sea_playdata（播放地址表），新版本更接近苹果CMS 的 vod_play_url 字段。以你后台「播放地址」编辑框实际显示的内容为准，先在数据库里 SELECT 出这一条确认，再决定改哪张表。

第三步排序。如果用 SQL 排，别用 ORDER BY 集名，要转成整数再排，思路是 ORDER BY CAST(REPLACE(REPLACE(集名,'第',''),'集','') AS UNSIGNED)。更稳的做法是把播放地址拆成数组，用 PHP 或 Python 按解析出的集数整数重新拼回 第N集$url#... 格式，再整体 UPDATE 回去。脚本处理比 SQL 拼字符串安全，因为不用处理 $ 和 # 的转义。

怎么保证下次采集不再错乱？

结论：把「统一集名格式 + 覆盖模式 + 采集后校验」三件事固定成流程，可以彻底避免复发。

统一集名格式：在采集入库前加一层清洗，把所有集名强制转成 第N集，中文数字（第一集、第十二集）用映射表转阿拉伯数字，EP01、01 这类前缀统一去掉。海洋CMS 的采集模块支持自定义采集规则/字段处理，清洗逻辑放在这一步最省事。

覆盖模式：把同一部剧的重复采集处理设为覆盖而不是追加。如果资源站会持续更新集数（比如追更剧），可以先用只采集指定集数范围的方式补采，比如只采第 21 到 30 集，避免整片重采一次把前面 20 集又插一遍。

采集后校验：采完在后台打开这部剧的播放地址框，肉眼确认是不是 1 到 N 连续。这一步 10 秒钟，但能挡住 90% 的问题。定时采集任务建议加一条校验脚本，发现集数不连续或出现重复集号就报警。

最后提醒一点：如果清空重采之后顺序还是乱的，问题就不在 CMS，而在采集源本身——先去浏览器打开资源接口的 XML/JSON，看 <dd> 节点的原始顺序是不是已经乱了。源乱了，任何 CMS 都救不回来，只能换源或在入库前自己重排。