今天复盘一个藏得挺深的大改造：给宝可梦答题小程序做判题本地化 + 后端从云开发迁到自建 Fastify。表面看是换套实现，真正折磨人的是——你怎么向自己证明新旧两套答案完全没漂？
先说判题本地化。原来每次猜都打云函数，我把判题下沉到小程序本地。核心原则只有一条：本地不重算取题公式，只拿服务端下发的 id 去查包里数据。数独早就这么干了，好处是前端和后端永远不会各养一份池子，从根上杜绝漂移。
验证我做了个狠的：Node 双跑。本地模块和云端 core.js 各跑一遍，ability 314 条、dex 722 池子加 3480 组对比板逐字比、silhouette 1025 池子，结果零漂移。这个"双跑对拍"后来成了后端迁移的护城河。
后端迁到 Fastify 5 + Prisma + SQLite，对拍升级成"真·双跑"：桩掉 wx-server-sdk 直接调云函数 main()，和后端 handler 整对象逐字比，9 玩法 × common/replay × 4 种记录状态，138 项全绿。它还顺手逮到一个真 bug——云端揭晓卡带 rec.targetId === target.id 守卫，自建后端 Record 表没 targetId，这句恒 false，揭晓卡永远不弹。去掉守卫并钉成断言才收住。
迁移有个关键取舍我写进了文档：不做服务端权威重算，信任客户端上报的 correct。理由很实在——判题已本地化、没排行榜、战绩私有，盲目并题库只加大攻击面。但我也钉死：将来做排行榜必须并题库加校验，不能偷这懒。
部署踩的两个坑很典型：prisma migrate deploy 不重新生成 Client，加新表后必须补 prisma generate；nginx 逐条列 location，新接口漏加就"本机 curl 正常、公网 404"，而且 reload 后旧 worker 还服务几十秒，差点让我误判配置错。
做"换心脏不换脸"的迁移，最值钱的能力是把"看起来一样"变成"逐字一致"。你们做类似云端到自建迁移时，靠什么锁住两端行为？
