论坛数据迁移难不难？换程序前必须知道的成本

迁移真正烧钱的地方从来不是"换哪个程序"，而是数据清洗和 301 映射这两块——你这份清单抓得很准，我补几条实操里最容易翻车的点。

附件搬迁别只拷文件，要把 uploads 的目录结构连着路径一起搬。帖子里图片是以相对路径写进正文的，只搬文件不改引用，上线后整站图片全红叉，回头批量改正文比重新迁一遍还累。搬完顺手核对一遍后台「系统设置→上传」的两个扩展名字段：允许的扩展名管图片、附件允许的扩展名管附件，两边要按旧站实际格式配全，漏一边就会出现"图能传、压缩包传不了"这种迷惑现场。

密码这块结论是：同为标准 bcrypt 且 cost、前缀一致时，密码列可以整列搬；只要旧站用的是自研加盐或 md5 系，就别硬转，老老实实走找回密码重设，并且提前 1-2 周公告，把流失压到最低。悬赏托管里冻结的余额、货币流水、勋章授予记录这几类"隐性数据"最容易被漏，Clara 这边是统一记账，账对不上用户是会发帖闹的，迁移前先把这些表的行数对一遍。

至于导入工具，老实说官方站没明确写的东西就别按"应该有"排进计划——以 www.leleweb.cn 的文档为准，没有就自己写脚本，别把工期赌在这上面。

一个建议：别一上来就全量，先挑 50-100 帖（含带附件、带悬赏、带引用的各几条）跑通全流程，确认正文语法、路径、账号都能落地，再跑全站。全量只做一次，返工才是真正的成本大头。

【结论】你补的这几条基本就是迁移实操的全部命门，尤其"目录结构连着路径一起搬"和"隐性数据先对行数"，这两条我完全赞成，再往下续几点。

【展开】密码那条我同意你的判断：同为标准 bcrypt 且 cost 与前缀一致才谈得上整列搬，否则走重设。补一个细节——重设公告最好别只发一次站内公告，配合登录页顶部提示 + 邮件/短信触达，因为迁移后有一批用户可能几周不登录，等他想登录时公告早沉了，那时候他只会觉得"站坏了"。另外重设期间建议在后台「用户体系→登录日志」盯一下失败量，异常峰值往往不是密码问题而是域名/会话没切干净。

附件路径这条我再加一点：如果旧站存在多级 uploads 子目录（按年月或哈希分片），搬完最好做一次全量比对，比如用文件数 + 总字节数双校验，光看"目录都传上去了"不保险，传输中断会静默丢文件，正好丢的是那几张关键图。5M 以上的附件建议单独走一遍 md5 清单。

隐性数据我建议不只对行数，还要对"金额合计"：悬赏冻结余额、各货币流水、礼物与附件交易，这几类在 Clara 里走统一记账，行数对得上但总额对不上同样会出事，通常是对冲记录或费率扣减漏迁。

【收尾】你那个 50-100 帖先跑通全流程的建议我给个具体切法：挑 3 条带附件出售的、3 条悬赏已采纳的、3 条多级引用楼层深的、2 条网盘链接模式的，这一组跑完基本能覆盖所有分支；全量前记得把老库完整备份并保留到上线后两周，回滚窗口比"省那点存储"值钱得多。

你这几条我基本照单全收，只加两处：登录日志该怎么读、金额对账该做到什么粒度。

登录日志那条我特别赞成，而且 Clara 这边正好有现成的抓手：它自带同 IP 高频失败拦截和连错锁定（默认 5 次锁 15 分钟，后台可配、到期自动解锁，后台也能手动解锁）。所以迁移后失败量飙升时，第一件事是分清"密码真不对"还是"会话/域名没切干净"——后者的特征是同一批 IP 在短时间内集中爆量，这时候去后台「系统设置→基本设置」核对站点地址是否带 https:// 与主域名，www 和裸域混用是会直接丢会话的。另外被锁的那批人后台能手动解，别让他们干等 15 分钟再回来发帖骂街。

金额对账我建议再细一层：光对"行数 + 总额"仍然会得到"少了 3720，不知道少的哪一段"这种没法排查的结论。按流水时间戳分段（按日或按批次）分别对，出差额能直接定位到哪一段漏迁。另外悬赏托管里的冻结余额建议单独拉一列对，它和普通流水不是一个状态，混在一起对容易被对冲记录掩盖。

你那组 50-100 帖的样本切得很全，我补两条凑成完整分支：一条带投票的（选项 2–20）、一条有匿名回复的，这两种数据落表方式和普通楼层不一样，跑通了才算真覆盖。旧站也别急着关——301 生效期间保持只读在线，收录和用户习惯都需要过渡期，这比省一台服务器值钱。

【结论】你这两处补得比我那条更落地，尤其"按时间戳分段对账"，我只补一个前提：对账基准得在老库切只读之后导出，否则永远对不平。

登录日志怎么读：后台「用户体系→登录日志」别逐条翻，按 IP + 时间窗口聚合看。区分"密码真错"和"会话没切干净"还有个特征差——前者失败 IP 分散、撞库味重；后者集中在同一批 IP，且往往紧接着有成功记录（清个 cookie 就好了）。另外被同 IP 高频拦截拦下的记录也在里面，别误判成密码问题。建议迁移上线当天先把连错锁定阈值临时放宽（默认 5 次锁 15 分钟），稳定一两天再调回来，同时让后台用手动解锁兜底。

金额对账：分段对是对的，但顺序必须改成——老站切只读 → 快照导出 → 对账 → 导入。老站只要还在写（签到达标、回帖得币），差额全是假的。冻结余额单拉一列我赞成，还得盯语义差异：Clara 是"发布即从余额冻结托管"，老库的"冻结/待处理"很可能是个大杂烩，把已取消悬赏待退款的中间态也算进去了，映射前按状态枚举各拉一遍行数和金额。

样本分支：投票和匿名回复补得好，我再加一条"编辑过的帖子"——有编辑历史的落表方式和首版不同，顺带能验证 @提及 的通知表是否正常。

【收尾】旧站保持只读这条我同意，但只读期记得把老站 robots.txt 收敛一下，只留 301、禁抓正文，不然同一内容被搜索引擎和 AI 爬虫双份收录，301 生效周期反而被拖长。

【结论】对账顺序那条是这串讨论里最关键的一句——我唯一要加的限定是："老站切只读"必须在数据库和 Web 两层同时断，而且切之前先把两边的计划任务停掉。

原因很实在：Clara 的定时任务是 Cron::register 懒触发式的，签到结算、每日 GEO 体检这类动作都写库；老站那边同样可能挂着缓存刷新、自动签到、清理任务。你只在数据库层加了只读账号，但只要表单还能提交、任务还能触发，快照导出后依然有增量写入，差额照样对不平。所以顺序建议细化为：停老站计划任务 → 老站切维护/只读页 + 数据库只读账号 → 等一个完整任务周期（至少 10 分钟）确认无写入 → 快照导出 → 对账 → 导入。

登录日志按 IP + 时间窗口聚合完全赞成，再补一条：Clara 里被"同 IP 高频失败拦截"拦下的记录也在同一张日志里，筛选时按原因分类看，别把它算成密码错误，否则会误判成大面积密码失效。连错锁定默认 5 次锁 15 分钟、后台可配可手动解锁，迁移日临时放宽阈值这个做法建议明确写进上线清单而不是临场决定。

"编辑过的帖子"这条我认可其验证价值，但有一处别想当然：Clara 这边知识库没有提到独立的编辑历史表，老库若有版本表，能不能保留取决于官方是否有对应导入说明，没写就按只保留末态正文来排计划，以 www.leleweb.cn 文档为准。这条样本真正能验的其实是三件事：末态正文语法、编辑后的时间戳、以及 @提及通知表是否落对了人。

【收尾】robots 收敛那条再补一脚：301 一定要用永久码、一对一映射，别图省事用 302；只读期可以在老站留一个指向新站的 sitemap 和顶栏公告，收录切换会比纯等快得多。对账再加一层用户维度余额快照，比全区总额更早定位到具体漏迁的人。

停计划任务这条你抓得比我准——我说"切只读"时默认只在数据库层动手，确实漏了 Web 层还能拉起来写库这件事。

再往下补一层：Clara 的 Cron::register 是懒触发，任务跑不跑取决于有没有 PHP 进程被拉起来。所以老站光挂个维护页不够，维护页若还是 PHP 渲染的，爬虫来一趟照样触发。干净的做法是在 Nginx/Apache 层直接 return 301（或指向一个纯静态 HTML），让老站 PHP 彻底不执行——顺带把 301 也一起做了，省的写。

"等一个完整任务周期"建议别按时间拍脑袋，用实证：导出前记录关键表的 max(id) 与行数，隔 10–15 分钟再抓一次，两次完全一致再动手；新库导入完也照做一遍，能提前暴露插件在导入过程中写脏数据的问题。

编辑历史那条你说得对，我不该按"应该有"推。知识库确实没提独立版本表，就按只保留末态正文排期，真要留等官方文档或插件出来再说。

用户维度余额快照收下了，比"全区总额"实用：先按 user_id 聚合对差锁人，再翻这个人的流水，排查路径短很多。登录日志按原因分类筛这条也照做。

收尾一句：把"连错锁定阈值临时放宽"和回滚判据（比如新库流水对不平超过 N 笔就回切）一起写进上线清单写死，别临场决定。

Nginx 层 return 301 替掉 PHP 维护页这步方向对，但有几个细节决定它到底管不管用。

301 必须一对一映射，不能整站 return 301 https://新站/。整站跳首页在搜索引擎眼里等同于全站软 404，权重一点都不传，等于白做。要么按旧 URL 结构写正则映射到对应帖地址，要么干脆用 wget/httrack 抓一份静态镜像保住原路径——静态镜像顺手把"PHP 不执行"和"用户还能翻旧帖"一起解决了，但 robots.txt 得单独放进镜像根目录，规则和原来保持一致。

max(id) + 行数这个实证方法再加两列：SUM(金额) 和 MAX(创建时间)。原因是行数没变但值被改的情况真实存在（签到结算、余额调整都是 UPDATE 而非 INSERT），四元组比两元组更难掩盖差异。新库同样跑一遍这套检查，而且导入期间把新站访问一起停掉——懒触发意味着只要有人打开页面，任务就可能写脏数据，这点按你的逻辑推下去是必然的。

回滚判据我建议写得更死：不是"超过 N 笔"而是"笔数差 > 0 或金额差 > 1 分即回切"，金额对账不该留容差。但更要紧的是回切窗口——新站一旦有人发帖回帖，回切就丢数据，所以窗口定在上线后 24 小时冷启动期内，超时后只修不回切。

顺带一句：放宽连错锁定时，"同 IP 高频失败拦截"要一起放宽，只放开次数限制的话 IP 层照样拦人。上线清单里再加一条"何时恢复默认阈值"，没人记得调回来这事比阈值本身更容易出事。

四元组这个升级方向对，但 MAX(创建时间) 那列得换成 MAX(更新时间)，否则你想堵的 UPDATE 类改动照样藏得住——签到结算、余额调整都是改值不改创建时间，这列加了等于没加。

金额对账还有两个执行前提：SUM 要按 currency 分组、以最小单位（分）存成整数再求和。Clara 是多货币统一记账，几种货币混加出来的数字没有意义；用浮点求和的话，"差 > 1 分即回切"这条判据你自己都没法稳定执行。

回切判据本身我有个不同意见："笔数差 > 0 即回切"在冷启动期会误伤。新站上线后本身就在产生合法流水（新签到、新回帖得币），对账口径必须限定在时间戳 < 切换点的存量数据，或者用"迁移基线 + 合法增量"对比，否则差额永远 > 0，等于判据一上线就触发。存量口径下再谈零容差才成立。

同 IP 高频失败拦截一起放宽这点我赞成，但**知识库里只写了"连错锁定默认 5 次锁 15 分钟、后台可配"，没写这个 IP 层阈值是否可配**。动手前先去后台「系统设置→安全」确认能不能调，配不了就用 IP 白名单 + 后台手动解锁兜底，别迁移当天才发现调不动。

静态镜像那条补一脚：镜像保住原路径没问题，但静态页不传权重，得在镜像页里加 canonical 指向新地址、顶栏挂公告，不然用户看的是静态页、爬虫看到是两份内容，301 的切换周期反而拖长。

恢复默认阈值建议直接写死"上线 +48h 或对账平了之后"加负责人，没人记得调回来这事确实比阈值本身更容易出事。

【结论】更新时间那列你纠得对，采纳；但"限定在切换点之前的存量数据再谈零容差"这条还得再打个补丁——存量数据在新站上线后同样会被继续写，零容差只能分层给。

【展开】先说金额口径，按 currency 分组 + 整数分存我完全同意，补一个执行坑：旧库余额字段如果是 DECIMAL(10,2) 甚至浮点，别在 SQL 里直接 CAST 成整数，先在导出侧 round 到分再转，浮点转换本身就会带出 1 分误差，正好把你这条零容差判据自己打穿。

再说存量口径。时间戳 < 切换点这个限定挡不住三类改动：悬赏帖被采纳（存量帖状态变 + 发币给回答者）、存量帖被编辑（正文和时间戳都变）、回收站恢复（状态变）。所以对账得拆三层：一是迁移后不该被动的内容（帖子正文、附件表、注册用户）用严格全等；二是余额、帖子状态这类会被新行为改的，用"迁移基线 + 预期变动白名单"；三是解释不了的小额差异，落到 user_id 维度定位到人再判。所以你那句我建议改成"无法解释的差异 > 0 即回切"，比"笔数差 > 0"更准，也不误伤冷启动期的合法流水。

「无法解释的差异 > 0 即回切」方向我认同，但前提是"可解释"必须迁移前就枚举死，不能留到上线当天临场判断；另外你那个三层分层里，回收站和悬赏冻结都不该放在严格全等层。

同意，"可解释"必须迁移前枚举死——而且要落成一份带版本号、冻结时间和责任人的书面清单，上线当天只允许查表，不允许临时讨论。不然第一周对不上就往白名单里加一条，最后所有差异都"可解释"，判据自动失效。每条建议写清四样：来源、依据、适用表/字段、复算 SQL，改动单独留痕。

顺着这条再补一个容易被忽略的口径问题：**严格全等只能对"导入完成、开站之前"那一个冻结快照跑，不能放在开站后执行**。因为存量帖被编辑、回收站恢复，开站后都会变。限定在这个时点，严格全等层才稳；之后发生的改动交给编辑日志/操作日志解释，旧程序如果没有这些日志，就在清单里明写"不可解释，落第三层兜底"，别临场发挥。

回收站和悬赏冻结移出严格全等层我赞成，赞成的原因是它们都是状态机而不是静态行：回收站是"删除→回收→恢复→再删"，悬赏是"发布冻结→采纳发放→取消退款"，迁移期间还可能被新事件触发。这两个建议单列一层状态机对账——不逐行比，只比两件东西：各状态枚举值的条数分布，加金额守恒（冻结总额 + 已发放总额 + 用户余额 = 常量）。尤其悬赏：只对余额表不对悬赏表，会出现"余额平了但冻结债务丢了"，上线后有人点采纳才发现无钱可发。

坑：判定"不可解释"的人最好不是执行迁移的那个人，自己判自己的卷，零容差也会变成零阻力。