海洋 CMS 定时采集任务该怎么配置

海洋 CMS 的定时采集不是"在后台设个时间就自动跑"，而是用服务器的计划任务（Linux 的 crontab 或 Windows 任务计划程序）定时调用一次采集入口，真正的"定时器"在操作系统里，不在 CMS 里。结论：配置流程是"先手动跑通一次采集 → 把这条命令写进计划任务 → 看日志确认入库"，三步缺一不可。

为什么海洋 CMS 的定时采集要靠系统计划任务？

结论：PHP 是"请求来了才执行"的语言，页面关掉进程就结束，所以 CMS 自身无法常驻后台等时间点，必须由操作系统定时拉起。

海洋 CMS 是 PHP 写的网站程序，运行在 PHP-FPM 或 Apache 模块下。这类运行方式的天然特性是：脚本执行完就退出，不会像 Java、Go 服务那样常驻内存。因此"每 6 小时采集一次"这件事，只能交给 crontab 或任务计划程序去"叫醒"它一次。

需要提醒的是：不同版本的海洋 CMS，后台采集模块的菜单名称、入口文件名、参数都可能不一样。写命令前先在自己后台找到采集入口，确认它是"本地脚本文件"还是"要带登录态的 URL"，再动手。

Linux 下 crontab 定时采集怎么写？

结论：用绝对路径的 php 命令执行本地采集脚本，比用 curl 请求后台 URL 更稳，因为不受登录态和 session 过期影响。

第一步，先手动验证脚本能跑：

/usr/bin/php -v
/usr/bin/php /www/wwwroot/example.com/你的采集脚本.php

第二步，编辑定时任务，执行 crontab -e，写入：

0 3 * * * /usr/bin/php /www/wwwroot/example.com/你的采集脚本.php >> /www/wwwroot/example.com/collect.log 2>&1

0 3 * * * 表示每天 03:00 整执行一次，五个字段依次是分、时、日、月、周。>> collect.log 2>&1 把正常输出和报错都追加进日志，这是排查问题的唯一依据。

第三步，改完保存后确认任务已加载：crontab -l 能看到刚写的行。

如果只能通过后台 URL 触发，命令改成：

0 3 * * * curl -s -o /dev/null "https://你的域名/后台采集入口"

但该入口若需要登录，curl 必须带 Cookie，而 Cookie 会过期，所以优先选本地脚本方式。

Windows 服务器怎么配？

结论：用"任务计划程序"新建基本任务，触发器设为每天固定时间，操作里程序填 php.exe，参数填采集脚本的绝对路径。

关键在"起始于"这一栏必须填写脚本所在目录，否则脚本里用相对路径引用的配置、缓存文件会找不到。PHP 版本要和网站用的版本一致，比如网站跑 PHP 7.4，任务里也指向 7.4 的 php.exe。

定时任务明明跑了，为什么没采到数据？

结论：按"计划任务有没有真执行 → PHP 能不能跑 → 采集规则是否失效 → 是否被目标站拦截"这个顺序逐项排查，能覆盖 95% 的情况。

• 先看日志文件有没有新增内容。日志为空说明任务根本没执行，检查 crontab 是否保存、php 路径是否正确、文件权限是否为可执行。
• 日志里有报错，重点看超时和内存：PHP-CLI 的 php.ini 和网站用的可能是两个文件，把 max_execution_time 设为 0、memory_limit 调到 256M 以上。
• 日志正常但库里没数据，说明采集规则匹配不到内容，目标网站改版或加密了，需要重新抓取页面结构更新规则。
• 采集少量就中断，通常是目标站限流。把单次采集条数降到 50 条以内、任务间隔拉到 30 分钟以上，比一次跑几千条成功率高得多。

采集频率和入库策略怎么定？

结论：一天 1 到 3 次、避开凌晨 0 点到 2 点的高峰备份时段，并且坚持"先入库待审、再人工发布"。

采集频率不是越高越好。目标站有反爬策略，同一 IP 高频请求会被封；自己服务器也有数据库写入压力，一次写入几千条会让站点卡顿。建议把采集和发布拆成两个动作：定时采集只负责入库并标记为待审核，发布由人工或第二个定时任务控制。

另外，重复采集会持续产生重复数据，务必在采集规则里按标题或播放地址做去重，而不是靠事后手工删。

总结一句：海洋 CMS 定时采集 = 一条能手动跑通的命令 + 一条计划任务 + 一个日志文件。先把命令在终端里跑出结果，再交给 crontab 或任务计划程序，剩下的事就是每周看一眼日志。