复刻老系统，最累的活不是把表建出来，是把老库里那套「人脑约定」翻译成机器能跑的口径。
第一次做迁移，直觉是先把老库 pg_dump 下来、按表建好、导进去。表结构确实一天能搞定，但导完才发现：字段名对上了，值却对不上——老系统的「数量」是市斤还是公斤、折扣 0 是「无折扣」还是「漏填」、作废单到底算不算数，这些全是老员工脑子里的约定，库里只有裸数字。
上线时经验库图片整页裂图，根因是三条叠加：
/uploads/ 反代，浏览器请求直接 404；pg_dump，文件目录没跟着迁——数据库里存的是路径，磁盘上没文件；三件事单独哪一个都不会全裂，叠在一起就成了「图片全坏」。
uploads/ 目录、公司 logo、打印页用到的图片，和数据库一起迁。nginx 反代、文件目录、数据三者缺一则图裂。为了验口径、查数据，把本地库刷成线上真实数据的副本——挑有数据的日子做校验，看到的就是真实单据，而不是造出来的假数据。好处是写查询、对字段时心里有底；代价是每次线上数据变动，本地基线要跟着重校，否则旧种子常量会让自测脚本集体误报。
关键纪律：迁移/基线必须「归数据线」重校。任何依赖历史快照数字的探针或脚本，在数据刷新后要重新核对，别把「旧基线过期」当成「功能回归」。
deleted_at 软删，所有查询都带 deleted_at IS NULL。加软删时要 grep 该表全部查询点（含 meta / ref-options 分支），漏一处就是「删了还能选到」。编号也必须不复用——nextCode 把已删行也算进序号，否则删一单后新单会撞号。created_by / updated_by，应用层写 JWT 里的 userId。ETL 迁入的历史数据这两列留 NULL，含义是「系统迁入」，不要用 0 或系统账号冒充。uploads/、logo、打印图片单列一项，和 pg_dump 同批执行。