先别急着换框架。把“断”先变成可观测的退出，再谈修复：入口加 faulthandler.enable()，主循环用 try/except 包住并记录退出码；137 先查 OOM（dmesg -T | grep -i "killed process"，容器看 OOMKilled），143 查调度器或超时，1 才是业务异常。这样能避免把“被系统杀掉”误判成“代码有 bug”。我自己的最小改法分三块。第一，任务状态落 SQLite，一个 URL 一个事务：CREATE TABLE task(url TEXT PRIMARY KEY, state INTEGER NOT NULL, retry INTEGER DEFAULT 0, updated_at INTEGER);抓取前先占位，成功后置 2，失败 retry+1，超过 5 次进死信表；重启只捞 state=0/1 的记录，去重集合也从这张表来，不要放内存里的 set。第二，用 systemd 托管，别用 nohup 裸跑：[Service]ExecStart=/usr/bin/python3 /opt/crawler/main.pyRestart=alwaysRestartSec=5MemoryMax=2GOOMScoreAdjust=-200再配一个心跳文件：主循环每处理 100 条 touch 一次，外部脚本发现 mtime 超过 10 分钟就重启。WatchdogSec 也可以，但心跳文件更容易和业务进度对齐。第三，把资源上限写死：requests 全部 timeout=(5,20)，Session 复用并 mount HTTPAdapter(pool_maxsize=64)，响应体用 stream=True 边下边解析，日志用 RotatingFileHandler。每轮结束打印 processed/failed/queue_size/rss 四个数，rss 连续上升基本就是泄漏。最后提醒一句：如果断之前 CPU 和内存都正常、只是没有新日志，优先查“卡在某个 socket 读”而不是被限流；给 socket 设超时并加 SIGALRM 兜底，通常就能把“跑着跑着不动了”变成一条可重试的失败记录。

先分清「截止前」还是「截止后」，处理方式不一样：1. 如果提交通道还没关闭：先回赛事页看有没有「重新提交/覆盖提交」入口，截止前通常允许覆盖，直接重传正确文件即可。提交后一定下载回执或截图，核对文件名、大小和哈希，别只看页面提示成功。2. 如果已经截止：尽快联系赛事官方（公告里的组委会邮箱、赛事小助手或官方群），说明「最后一次提交误传了错误文件」，并一次性提供：队伍 ID/报名账号、提交记录截图（提交时间、提交 ID）、错误文件与正确文件的文件名和 SHA256、正确文件本身。请求人工替换或补交。3. 能否受理由主办方决定，不要假设一定能改；如果评分已经启动，通常无法替换，只能询问是否有申诉或补交窗口。不要为了「再交一次」去重复注册队伍或灌多个提交，容易触发风控。4. 邮件用正式标题，例如「第39期算法挑战赛-队伍XXX-误传文件申请补交」，正文写清时间线和请求，附件直接带正确文件，不要只给网盘链接。5. 后续提交前先本地校验：文件名、大小、SHA256 与要求一致；提交后立刻回读回执。把「提交成功」和「提交了正确文件」分开确认，能避免同类问题。

补充一个选型视角，重点不是背优缺点，而是看「哪些语句在 SBR 下结果不确定」：1. SBR 的 binlog 只记 SQL 文本，日志量小、可读性好，但从库要重新执行。只要语句里含非确定性因素，主从就可能不一致：NOW()/CURRENT_TIMESTAMP、RAND()、UUID()、USER()、不带 ORDER BY 的 LIMIT、以及依赖 auto_increment 或用户变量的写法。触发器、存储过程、跨库更新也要额外小心。它要求主从的表结构、数据、SQL 模式尽量一致。2. RBR 记录实际变化的行，不重新执行 SQL，所以对上述非确定性语句是安全的，一致性最好；代价是批量 UPDATE/DELETE 时 binlog 可能明显膨胀。可以用 binlog_row_image=minimal 减少记录列，再配合 binlog_expire_logs_seconds 控制保留时间。3. MBR 是按语句是否「安全」自动切换：安全语句走 SBR，不安全语句走 RBR。它看起来折中，但实际行为取决于版本对语句的分类，排查问题时不如纯 ROW 直观。4. 生产建议：InnoDB + 主从复制优先用 ROW（MySQL 5.7.7 起默认就是 ROW），把一致性放在第一位；只有日志量确实成为瓶颈、且 SQL 写法完全可控时，才考虑 SBR。无论选哪种，都建议用 pt-table-checksum 或定期抽样校验主从一致性，不要假设「配置了复制就一定一致」。

补充一个实测口径，供你选版本时参考：1. 体验版是免费的，但容器约 6 小时后释放，释放后数据不保留，再次进入是全新容器。它适合临时验证、跑一次性命令，不适合常驻服务。2. 持久化版按「实际使用时长」扣核时，关机/休眠期间不再扣运行核时；但关机后保留的磁盘/快照是否另计，页面没有统一说明，建议进入后在「核时控制器」里看额度明细，并以那里的口径为准。3. 常驻自建服务建议选持久化版，进入后用 tmux/screen 或 systemd 托管进程，避免终端断开导致进程退出；同时确认服务监听端口是否允许外部访问。4. 先估算额度：核时约等于分配 vCPU 数乘以运行小时。比如 4 vCPU 常驻，一天约 96 核时，8000 核时理论上可跑 80 天左右，但还要留出重启、调试和额度耗尽的余量。5. 如果只是白天使用，建议用完就关机；需要 7×24 常驻，先确认额度、磁盘保留和公网入口三项，再决定是否长期挂。

会不会回退，取决于版本。5.7 及更早，InnoDB 的自增计数器只存在内存里，实例重启后会用“表中当前最大 id + 1”重新初始化；如果重启前删掉了最大的一批行，计数器就会回退，后续插入可能复用已删除的 id。8.0 改变了这一点：自增计数器的值会持久化到 redo log，重启后按持久化的值恢复，不会因为删行而回退（除非手动 ALTER TABLE ... AUTO_INCREMENT 改小，或表被重建）。另外 8.0 的 innodb_autoinc_lock_mode 默认是 2（interleaved），并发插入时更偏向性能，批量插入的 id 可能出现空洞；5.7 默认是 1（consecutive）。所以：不要依赖自增 id 连续、不要用它做业务编号；用 BIGINT UNSIGNED 留足空间；如果业务要求“删除后不复用”，8.0 的持久化能帮上忙，但最稳妥的还是用独立的序列/雪花 id，或在删除时保留墓碑记录。

两者本质上是“数据文件放在哪里、能否独立管理”的区别。innodb_file_per_table=ON（5.6.6 之后默认）时，每张表有独立的 .ibd 文件，可以单独备份/迁移，DROP/TRUNCATE 后磁盘空间能还给操作系统，碎片也能通过 OPTIMIZE TABLE 或重建表回收；缺点是文件数量多，文件系统元数据和打开句柄压力更大。设为 OFF 时，新建表的数据进入共享的系统表空间 ibdata1，所有表混在一起，空间只能整体增长、很难单独收缩，单表备份/迁移也不方便，所以生产上一般不建议关闭。需要注意：该参数只影响“之后新建的表”，已有表不会自动搬迁；从 OFF 改 ON 后，老表仍在 ibdata1 里，要迁出得用 ALTER TABLE ... REBUILD 或导出重建。另外 8.0 把数据字典放进 mysql.ibd，undo 和 doublewrite 也有独立表空间，ibdata1 的职责比 5.7 更窄，但“共享表空间难回收”这个结论仍然成立。

三种复制格式的核心区别在于 binlog 记录的是“SQL 语句”还是“行变更”。SBR 记录原始 SQL，日志量小、可读性强，适合批量更新；但它要求从库执行结果与主库完全一致，遇到 NOW()、RAND()、UUID()、用户变量、LIMIT 无 ORDER BY 等不确定语句时容易主从不一致，触发器/存储过程也有额外风险。RBR 记录每一行的前后镜像，结果确定、主从一致性好，是生产环境更稳妥的选择；代价是批量 DML 的日志量可能明显变大，可以通过 binlog_row_image=MINIMAL 只记录必要列来缓解。MBR 是折中：由 MySQL 根据语句是否确定自动在 SBR/RBR 之间切换，日常小语句省日志，不确定语句走 RBR；但“是否确定”的判断并不总能让所有人放心，排查时也不如纯 ROW 直观。实践上建议 binlog_format=ROW + binlog_row_image=MINIMAL，配合定期 checksum/一致性校验；只有明确追求日志体积且 SQL 全部可控时才考虑 SBR。