XIJIAN DOCS

旧库表结构摸底

36 张核心表三分法落位/21 条迁移地雷 · ← 返回文档中心

目录
1. 总览：旧库业务表清单2. 逐表详录3. 三分法落位（汇总）4. 迁移地雷清单（19 坑 + 文档实测发现，逐条标出处）5. 给 P0-2.3 的开放问题附：本文档信息来源清单

旧库（lynoxi）表结构摸底 · schema-notes

P0-2.2 产出。纯调研，未连接任何数据库（生产/测试均未连接）；结构一律从 xijian-legacy/api 的 JPA/MyBatis-Plus 实体源码（entity/*.java，49 个 @TableName 类）与 xijian-legacy/admin-v3/docs/{backend-gotchas.md, legacy/system-and-data.md, legacy/core-modules.md, legacy/finance-ops.md, legacy/order-state-machine.md} 推导。行数量级引自这些文档里 2026-08-13 的生产库实测数字（本次未复核，标注来源）。

三分法定义（xijian/docs/dev-charter.md §4）： - 演进域：新表按新模型设计（建在 xijian 库），切流时自 lynoxi 一次性映射导入 - 历史只读：跨库只读 lynoxi.*，不重建不写 - 弃用不迁：不进新系统（死表/被产品判定从未真正上线/被新设计取代）

服务对象：P0-2.3（达人三层库新模型）与后续 P0-5.1（商单模型）、结算域模型设计的输入。

1. 总览：旧库业务表清单

共 49 张有 JPA 实体的表 + 4 类无实体层的表（shengyijing_* 5 张同族 / sys_config / sys_log / sys_file），文档口径合计 61 张（system-and-data.md，2026-08-13 实测）；本次清点到 53 张（49 实体 + shengyijing 系列记 1 项 + sys_config/sys_log/sys_file 3 项），与 61 的差额详见 §5 开放问题 #1。

行数标注格式：数字=有实测来源；—=文档未给出量级；0=死表实测 0 行。

1.1 达人域（8 张）

表 行数量级 主键 用途一句话 三分法
influencer — id 达人主档（真实姓名/手机/微信/入驻状态） 演进域
douyin_account 4,320+（fansDistribution bug 样本）/ 19,299（达人广场采集，待确认是否此表，见开放问题#2） id 抖音账号（含 100+ 集星字段），达人广场池的主要载体 演进域（历史 jixing_* 快照字段不整体搬，改走集星 API 实时拉取，见 §5）
influencer_payment_info — id 达人收款信息（对公/对私） 演进域
influencer_region — id 达人接单地区 演进域
influencer_visitor_info — id 入园/入住信息缓存（按达人+账号复用） 演进域
quality_douyin_account — id 优质达人池（人工手动加入） 弃用不迁，语义与新分级冲突（见 §5）
blacklist_douyin_account — id 黑名单（人工拉黑口子） 演进域（新分级取代自动降权，人工黑名单口子保留）
manager 9 id 团长主档 演进域

1.2 商单 / 任务 / 场次域（11 张）

表 行数量级 主键 用途一句话 三分法
task 163 id 任务（场次挂在 session_name 字符串字段下，无独立场次表） 演进域
task_order 13,864（各状态分布见 §2.2） id 商单主表，13 态状态机 混合：新增走演进域新表(12+2)；存量 1.4 万条历史只读映射用于展示/结算对账
task_requirement — id 任务达人准入条件 演进域
task_tag — id 任务标签 演进域（低优先级，未见后台前端消费，P0-2.3 评估是否弃）
task_view_record — id 达人浏览任务埋点 新域新表（埋点数据无迁移必要，随新功能重建）
visitor_info — id 入园/入住信息（订单维度） 演进域
work_review_record — id 作品审稿/回填链接/补发链接/数据统计的统一记录表（实体注释已过时，见 §4） 演进域
preselected_order — id 报名审核中订单的预选池（二次筛选暂存） 演进域
product 0 id 带货商品 弃用不迁（死表）
material — id 任务素材（图片/视频/直播切片） 演进域
proof_image — id 达人认证图片 演进域

1.3 结算域（9 张）

表 行数量级 主键 用途一句话 三分法
payment_request ≈1,038+（approval_status 五态分布合计，见 §2.3） id 达人付款申请（1 对 1 对应飞书审批实例） 演进域
payment_request_log — id 付款单状态流水 演进域
finance_payee_config — id 我方付款账户配置（填入飞书审批表单） 演进域（或并入配置中心评估）
serviceshare_signing 939（311 人 ×3 服务商，实测） id 身边云签约全量原始留档（只增不删） 演进域（持续同步的运营数据，非死表）
serviceshare_signing_current — id（idCard 唯一） 签约生效记录（按身份证消解后的结果表，下游只查这张） 演进域
approval_tax_accumulation — id 达人付款个税月度累计（按身份证） 演进域
settlement 0 id 结算记录（旧设计，从未真正使用） 弃用不迁（死表，被 payment_request+task_order 实际取代）
settlement_invoice — id 结算发票（对公结算硬关卡依赖） 演进域
withdrawal 0 id 达人提现 弃用不迁（纯前端 Mock，finance-ops.md 明确"从未真正上线"）

1.4 数据域（4 张，均为跨库高量级表）

表 行数量级 主键 用途一句话 三分法
video_data 133 万 id 视频数据（林客同步） 历史只读（禁止 OFFSET 深分页，必须带时间范围）
live_data 6.7 万 id 直播数据 历史只读（只有 uk_live_id 一个索引，需补 douyin_id/live_time）
order_data 161 万 id 订单数据（财务对账，正向/退款两型） 历史只读（禁止 OFFSET 深分页）
feishu_execution_record — id 0701 表镜像 + 人工录入待付款明细（source 区分 FEISHU/MANUAL） 演进域（过渡期继续同步，目标随 0701 退役；短中期仍是结款三数一致对账依据）

1.5 项目 / 计划域（4 张）

表 行数量级 主键 用途一句话 三分法
project 0 id 项目（客户名是自由文本，无主数据表） 弃用不迁（死表，项目维度需新建不是迁移，finance-ops.md 已判定）
merchant 0 id 商家 弃用不迁（死表）
life_account — id 来客商家账户（同步） 演进域（POI 校验 §7.3 依赖）
life_account_poi — id 来客门店 POI（同步，GCJ02 坐标） 演进域

1.6 系统 / 辅助域（简录，不展开逐字段——RBAC/日志/配置已被新系统体系覆盖）

表 行数量级 用途 三分法
admin_user/admin_role/admin_permission/admin_role_permission/admin_user_role — 旧 RBAC 五张表（136 权限码，5 内置角色） 弃用不迁（新表+一次性导入管理员，P0-2.5；不再直连）
operation_log — 操作日志 弃用不迁（被 xijian_audit_log 取代）
sys_request_log 29 万 全量请求日志 弃用不迁（纯日志，system-and-data.md 已建议"不进新后台"）
change_log — 字段级变更审计（visitor_info/payment_info/task_order 等） 弃用不迁（被新审计取代，字段设计可参考）
app_config — 小程序+后台共用配置（不存在 system_config 表，是红鲱鱼） 弃用不迁（被 xijian_config 取代）
banner 0 轮播图 新域新表（功能保留/前端模块判定必迁，但表当前 0 行无历史数据负担）
feishu_user — 飞书 OAuth 登录 token 弃用不迁（新系统认证方式不同，不复用）
feishu_table_manage 0 飞书多维表格管理 弃用不迁（死表）
data_sync_log 0 数据同步日志 弃用不迁（死表）
invite_record 0 邀请关系 弃用不迁（死表）
region — 省市区字典 演进域（若接单区域改省市区级联时需要，当前达人省份是纯文本，P0-2.3 评估）
sys_config（无实体，裸 JDBC） 26 V1 遗留，存飞书 admin_token 弃用不迁（遗留凭证表）
shengyijing_*（5 张，无实体层） 11 万（channel_analysis） 外部进程（疑 dls 采集服务）写入的经营数据 历史只读（若要用需自建读取层，api 仓库本身不读不写）
sys_log / sys_file（无实体） 0 V1 遗留 弃用不迁（死表）

三分法分布合计（按 §1.1–1.5 核心业务表，36 张，不含 §1.6 系统辅助表；task_order 按"含存量 历史只读映射"计入演进域一次，不重复统计）： 演进域 26 张（达人域 7 + 商单/任务/场次域 9 + 结算域 7 + 数据域 1〈feishu_execution_record，过渡期〉+ 项目/计划域 2）｜历史只读 3 张（video_data/live_data/order_data，纯跨库只读高量级表）｜ 弃用不迁 6 张（quality_douyin_account/product/settlement/withdrawal/project/merchant）｜ 新域新表 1 张（task_view_record；banner 在 §1.6 系统辅助表中，不计入此 36 张核心表统计）。

2. 逐表详录

2.1 达人域

influencer（达人主档）

字段 含义 口径备注
id 主键
openId / unionId 微信身份 小程序登录用
name 真实姓名
displayName 昵称
phone 手机号 唯一识别键之一（基线 §0：抖音号+手机号），企微加好友只能搜手机号
wechatId 微信号
idCard 身份证号
age 年龄 ⚠️ 抖音开放平台拿不到时返回 -1（gotchas 第 14 条），代码判断需 age > 0
gender 0未知/1男/2女
inviterId 邀请人 ID
onboardingStatus 0未入驻/1待审核/2已入驻/3已拒绝
rejectReason 拒绝原因
creditScore 信用分
adminRemark 后台备注
deleted 软删标记

⚠️ 达人级完全没有标签字段（core-modules.md）：标签只在 douyin_account.tags。基线 §8 提到 "达人标签入驻时自填，老达人需引导补填"——新模型需决定标签挂在人还是账号维度。

无证件照、无认证状态字段——idCard 只在编辑弹窗表单存在，未纳入前端 schema。

douyin_account（抖音账号，711 行全库最大实体）

核心业务字段（非集星部分）：

字段 含义 口径备注
influencerId 达人 ID 达人广场池阶段可为 null（未建联时无归属达人，见 §5 开放问题#2）
douyinId / uid 抖音号 / UID 唯一识别键；uid 是集星 API 调用参数，非抖音号
nickname / avatarUrl 展示信息
fansCount / mpFansCount 粉丝数 / 跨平台粉丝数
videoCarryingPowerLevel / liveCarryingPowerLevel 视频/直播带货力等级 1-5 任务定价按此取档；-1 渲染为「非团购达人」
accountTypes group_buying,promotion 逗号分隔 ⚠️ 与 tags/specialtyCategories 的 JSON 数组格式不一致（gotchas 第 12 条同类问题在此重现，core-modules.md 三套标签体系）
tags 账号标签，JSON 数组字符串 2026-07 改版为固定选项多选（亲子/情侣/攻略/国风/颜值/外国），历史自由标签已清空
specialtyCategories 擅长类目，JSON 数组字符串 ⚠️ 后台无编辑入口（只读，core-modules.md），迁移后需补
region / residentCity 账号归属地 / 常驻城市
jixing_*（约 100 个字段） 集星创作者数据全量快照 P0-2.6 定案：不再跨库读/搬运这批历史快照，改走集星 API dls.lynoxi.com 实时拉取（jixing-api-notes.md）。迁移时不建议逐字段照搬，新模型应只保留当前有消费场景的字段，其余靠 API 按需补
isPrimary / status 主账号标记 / 0待验证1已验证2已失效 无审核流程：管理员在编辑抽屉手动切 status
deleted 软删

⚠️ 关键单位坑（基线 §8）：大千数仓 dy_influencer 表 daren_gmv_30d 是分、 item_gmv_total_30d 是元——虽非本表字段，但集星/中台同族数据源迁移时必核对单位，其余 GMV 字段单位存疑，只放行已验证的。

账号绑定无流程：influencerId 就是外键，新建/编辑靠手填数字 ID，无搜索选择器—— core-modules.md 明确"新后台必须改为搜索选择器"，P0-2.3 设计时一并解决。

influencer_payment_info（收款信息）

accountType：PERSONAL/CORPORATE。CORPORATE 时 companyName/taxNo 必填——结算硬关卡依赖 （order-state-machine.md：CORPORATE 账户必须存在 settlement_invoice 且未被驳回才能批量结算）。

influencer_region / influencer_visitor_info / proof_image

结构简单，字段清单见源码，无特殊坑。influencer_visitor_info 是"达人+账号→缓存的访客信息"， 用于门票套餐场景快速填充，与 visitor_info（订单维度的实际提交记录）是两张不同的表，不要混淆。

quality_douyin_account（优质达人池）

字段：douyinAccountId / remark / createdBy。人工手动加入，无批量/无分面筛选。

⚠️ 语义冲突（本次调研发现）：基线 §2 的"优质"分级是履约后系统自动判定 （ROI>10 且 CPM<20 且酒旅品类），而旧表 quality_douyin_account 是运营人工手动加入的池子， 两者概念不同名却容易被当作同一件事迁移。建议：旧表弃用不迁，新"优质"分级作为 influencer/douyin_account 派生字段或独立分级记录表实现；如运营仍需要"重点关注名单"人工池， 应作为独立新概念命名，不复用"优质"这个已被基线定义占用的词。

blacklist_douyin_account

previousCreditScore 用于取消拉黑时恢复信用分——迁移新表时需保留这个"可逆"设计。

manager（团长）

字段与 influencer 几乎同构（无绑定抖音账号，多一个 managedInfluencerCount 冗余计数）。 基线 §0/§6.3："团长只开秒杀、不入库"——新模型下团长是否还需要"入驻"概念需与产品口径核对 （现状 onboardingStatus 与达人共用四态语义）。

2.2 商单 / 任务 / 场次域

task（任务，270 行）

关键字段：

字段 含义 口径备注
projectId 项目 ID ⚠️ 有数据层字段但前端硬编码传 1（core-modules.md），从未真正接入项目维度
sessionName 所属场次 场次是字符串字段，不是独立表——基线 §1 术语表定义"场次"为"一次具体执行批次（形如 ID2608922）"，新模型 P0-4.1 需要独立场次表
businessUnit scenic/hotel 只有两个硬编码枚举，core-modules.md 判定"项目维度统一后是否被吸收"待决策
type explore/live_onsite/live_greenscreen 三种任务类型无扩展表，完全靠此字段区分（system-and-data.md），字段是否生效因类型而异（见下表）
status 0草稿/1已发布/2进行中/3已取消 ⚠️ 三处定义冲突：详情页/schema 注释/列表页三份文档给出不同的 0-4 含义，以列表页 0-3 为权威（core-modules.md），且"2 进行中"与订单侧的"已结束"派生态是两回事
accountTypes / selfQuotedPrice / promotionTags 品宣专属字段 仅 explore 类型 + accountTypes 含 promotion 时生效
commissionAmount JSON {"1":".."，"2":"..",...} 按带货力等级分级定价；报名瞬间读取生成 expectedEarnings
commissionEnabled / commissionRate / incentiveEnabled / incentiveTiers 计价配置（2026 新增） 阶梯 JSON [{"gmv":10000,"reward":200}]，取满足条件最高档不累加——与基线 §7.1 后置激励口径一致
requireWorkReview / requireVisitorInfo 开关，仅 explore/live_onsite 部分生效 编辑态创建后不可改
entryInfoDeadline / workSubmitDeadline / linkFillDeadline / linkResendDeadline 四个 deadline 对应 §4 时效红线的系统字段
accepted_count / signed_up_count / completed_count 计数冗余字段 ⚠️ gotchas 第 8 条：计数字段会漂移（多条加减路径口径不一致，超时转失败不减、撤回时却加）——新模型不要再走冗余计数，用实时查询

三种类型的字段有效性矩阵（core-modules.md，迁移到新商单模型时必须保留这份判断表）：

字段 explore live_onsite live_greenscreen
requireVisitorInfo 生效 生效 无效（代码显式拒绝提交入园信息）
requireWorkReview 生效 无效 无效
workSubmitDeadline / linkResendDeadline 使用 不使用 不使用
commissionAmount 取哪一级 视频带货力 直播带货力 直播带货力

task_order（商单，705 行，全库字段最多的表）

真实落库字段（非 @TableField(exist=false) 关联查询字段，那些是 SQL join 出来的 VO 字段不进 新表设计）：

字段 含义 口径备注
orderNo 订单号
taskId / influencerId / douyinAccountId 三个外键 无外键约束，靠代码保证一致性
userType / managerId 达人/团长区分
signupType group_buying / promotion
status 0-13 见下方状态机小节
expectedEarnings / actualEarnings 预期/实际收益 system-and-data.md 金额字段生命周期表：expectedEarnings 报名瞬间写入但不定格，后台列表页会动态重算覆盖内存值——显示值 ≠ 库里的值，是本表最大的迁移地雷之一
pricingSnapshot 接单快照 JSON 代码中未见写入点，疑似未实现（system-and-data.md 已标注），新模型不应假设此字段有值
estimatedCommission / estimatedIncentive / estimatedTotal / gmvTotal 动态期每日重算，转 8 时定格
earningsLocked 收益是否定格 生产 13,864 条订单全部为 0——计价模型 2026-08-13 才上线，无历史数据可迁移参考
workRetryCount 作品重提次数（上限 99，超则转 12）
previousStatus 取消/失败前状态，用于撤销
entryInfoPreFilled 报名时预填入园信息标记
managerVisitorErrors 等 4 个 JSON 字段 团长批量提交错误详情 团长专属，新模型评估是否仍需要（团长线过渡方案未定）

⚠️ 订单表没有 projectId（gotchas 第 7 条）：只能通过 taskId 间接关联项目，这是"项目维度 需要新建"判断的又一佐证。

订单状态机（13 态，权威来源 order-state-machine.md + 实体 Javadoc 交叉核对一致）：

码 含义 生产行数（2026-08-13 实测）
0 已报名 同事务立即转 4，永远 0 行 0
1 待提交入园/入住信息 104
2 报名审核失败 终态 3,717
3 待提交作品审稿（仅 explore） 0
4 报名审核中 6,783
5 待回填链接 137
6 作品审核失败 0
7 作品审核中（仅 explore） 0
8 待结算 437
9 需补发链接（仅 explore） 0
10 数据审核中 1,594
11 已结算 终态 13
12 任务失败 终态 525
13 已取消 终态 550

三种任务类型使用的状态子集不同（explore 全量 0-13；live_onsite 不用 3/6/7；live_greenscreen 仅 0,2,4,8,10,11,12,13）。⚠️ 已结算仅 13 条——旧系统结算流程实际几乎未跑通，新模型不能假设旧 已结算 订单的金额字段可信度高，需要个别核对。

⚠️ 单条结算是 bug（order-state-machine.md + gotchas 第 3 条）：POST /{id}/settle 代码把 状态设为 12（任务失败），注释却写"已结算"——只有 /batch-settle 才是正确路径（校验 status=8 + 对公发票关卡 → 11）。新模型的状态机设计不要照抄这份代码的动作命名，按 order-state-machine.md 的权威定义重写。

⚠️ reviewType 参数与 work_review_record.review_type 字段是两套不同枚举（本次调研发现）： POST /{id}/review-withdraw?reviewType 的 reviewType=1/2/3 分别代表"报名/作品/数据审核撤回" （订单阶段维度）；而 work_review_record.review_type 字段的 1/2/3 代表"审稿/回填正片/补发随拍" （记录类型维度）。两者同名同取值范围但语义完全不同，新模型必须用不同的字段/枚举名区分， 避免重蹈覆辙。

task_requirement / task_tag / task_view_record

结构简单。task_requirement.gender 字段 Javadoc 写着"数据库表暂无此字段，等待 Flyway V61 迁移 执行后移除此注解"——说明这是一个曾经代码先行于迁移脚本的临时状态，迁移旧库前务必以 information_schema 或迁移脚本历史为准核对该字段是否真的落库（本次未连库确认，见 §5 开放问题#3）。

visitor_info（入园/入住信息，订单维度实际提交记录）

字段：orderId / visitorName / visitorIdCard / visitorPhone / visitTime / visitNotes。 注意与 influencer_visitor_info（缓存表）区分，见 §2.1。

work_review_record（审核记录，235 行）

字段 含义 口径备注
orderId / douyinAccountId 关联订单/账号 一个订单可有多账号多条提交记录
reviewType 实体类级注释与字段注释自相矛盾（见下）
contentType video / live
contentUrl / videoId / roomId 内容链接及解析出的 ID
pcScreenshotUrl（系统抓） / appScreenshotUrl（达人上传） 两种截图，用途不同不要混用
videoDuration（毫秒） / humanAppearanceDuration（秒） 时长两个字段单位不同（finance-ops.md：published-links 模块坑同源）
playCount / likeCount / commentCount / shareCount / gmv 数据指标
cpm / roi 千次曝光成本 / 投资回报率 注意 §7.4 的 ROI 公式：（成交GMV−达人费用）/达人费用，与旧字段 Javadoc 公式描述一致，但务必用基线口径重算，不要信旧数据里已存的值（0701 表 ROI 公式实测是错的）
reviewStatus 0待审核/1通过/2驳回

⚠️ reviewType 字段实体类注释自相矛盾（本次调研发现）：类级 Javadoc 说"该表用于记录三种 类型的审核"，却列出 4 条（作品审核/回填链接/补发链接/数据审核）；字段级 Javadoc 又只写 2 条 （1-作品审核，2-数据审核）。权威口径以 system-and-data.md 实测为准： review_type 1=作品审稿（未发布视频原始文件）、2=回填链接（正片）、3=补发链接（随拍）—— "数据审核"实际不是本表的独立 reviewType 值，而是订单状态维度的概念（10=数据审核中）。 TaskOrder.mainVideoUrl/casualVideoUrl 的关联查询注释（reviewType=2/reviewType=3）与此一致， 可交叉验证。迁移与新模型设计一律以此为准，忽略实体 Javadoc。

preselected_order / product（死表）/ material / proof_image

preselected_order 结构简单（orderId/remark/createdBy）。product 已确认死表（0 行）弃用。 material 用 type（image/video）+ category（reference/live_clip）两级分类，对应任务表单的 "商家素材"分组。

2.3 结算域

payment_request（付款申请主表，135 行，1 对 1 对应飞书审批实例）

字段 含义 口径备注
batchNo 批次号（同一次"合并发起"共享） 对应基线 §6.2/finance-ops：按「客户+月份」分组合并
feishuUuid / approvalInstanceCode / approvalSerialNumber 飞书审批幂等键/实例编码/单号
approvalStatus CREATED/PENDING/APPROVED/REJECTED/CANCELED ⚠️ 生产实际存在第 6 个值 SUBMIT_FAIL（297 条），实体注释没有（system-and-data.md）。分布：SUBMIT_FAIL 297 / APPROVED 251 / PENDING 222 / CANCELED 206 / REJECTED 62——新模型状态枚举必须包含 SUBMIT_FAIL
amount 付款金额 ⚠️ finance-ops.md 说"飞书审批金额=实付×1.06"，但基线 §7.6 说"灵工金额=实际金额×1.062"——两份材料系数不一致，需向业务确认权威值（见 §5 开放问题#4）
customerName 合作客户 自由文本，无客户主数据表（finance-ops.md 核心结论），新项目域上线后需建立映射/迁移策略
payeeIdCard / payeeBankCardNo 收款人身份证/卡号 与 serviceshare_signing_current 的匹配/校准依赖此二字段
submitterId / actualSubmitterOpenId 提交人 / 代发起兜底人 提交人不在审批租户内时降级代发
remarkFilled 是否已回写飞书表备注 撤回后需清空此备注，属于双向同步动作
version 乐观锁

⚠️ 人工付款删除接口曾因逻辑删除字段生成坏 SQL（已修）（gotchas 第 18 条）： ManualPaymentServiceImpl.delete 曾用只 set id+deleted 的 updateById 做软删，deleted 是全局 逻辑删除字段不进 SET 子句，生成没有 SET 的 UPDATE 直接报错——删除功能曾长期不可用。新模型 的软删实现要走标准 ORM 逻辑删除机制，不要手写局部 UPDATE。

payment_request_log

事件类型：CREATE / SUBMIT_OK / SUBMIT_FAIL / STATUS_CHANGE / CANCEL / RECONCILE_FIX / REMARK_WRITEBACK / TAX_ACCUMULATE。operatorType：USER/SYSTEM/FEISHU_EVENT/RECONCILE—— 新模型的流转留痕设计（P0-5.2 要求"每次流转留痕：谁/何时/从→到"）可直接参考这张表的字段设计。

serviceshare_signing（身边云签约全量原始留档）

唯一键是 (user_no, provider_id)，不是身份证：同一用户会与多个服务商主体分别签约，实测 939 行 = 311 人 × 3 个服务商，按身份证去重会丢数据（源码注释明确记录）。只增不删：导入 清单不含某条不代表已解约。

serviceshare_signing_current（消解结果表）

下游（手机号/卡号校准、未签约拦截）只查这张表。消解规则：同一身份证多个 user_no 时取 remote_create_time 最新的一条；manual_override=1 的记录消解时跳过（人工修正不被下次导入冲掉）。 测试库导入时的脱敏坑（gotchas 第 19 条）：feishu_execution_record.payee_id_card 与 serviceshare_signing.id_card 靠值匹配（交集 671 人，匹配率 82.7% 是签约页核心指标）；user_no 同理是"多账号冲突"判定依据——按行 id 脱敏会打散映射关系，把真实数据关系破坏。 新模型的映射导入脚本必须使用统一 idmap/usermap（脱敏时保持跨表值一致），并在导入后触发一次 "重算生效记录"逻辑（对应旧接口 POST /admin/finance/signing/resolve）。

approval_tax_accumulation

按身份证+归属月累计已批准金额，用于个税预警（基线未展开具体阈值，¥6250/月阈值来自 finance-ops.md 前端 UI 文案，是否为可配置项待核实，见 §5 开放问题#5）。

settlement（死表）/ settlement_invoice / withdrawal（死表）

settlement 与 withdrawal 均确认为 0 行死表，弃用不迁。settlement_invoice 是真正生效的发票 表：orderId+influencerId/managerId，reviewStatus 0待审核/1通过/2驳回——对公结算硬关卡 （order-state-machine.md：CORPORATE 账户必须存在此表记录且 reviewStatus != 2 才允许批量结算）。 一对多设计（同订单可因驳回重新上传），历史记录不物理删除（涉税凭证）。

2.4 数据域（高量级只读表）

video_data/live_data/order_data 三表字段高度相似（播放/点赞/评论/分享 + 各类 GMV 分项 + 达人佣金分项 + 广告 ROI 分项），来自"林客视频数据同步"外部管道，不建议逐字段照搬进新演进域 表——新数据域（datasync 域，P1 排期）应设计更精简的聚合模型，原始明细表继续跨库只读消费。

feishu_execution_record 表名保留 feishu_ 前缀是有意为之（源码注释：改名涉及大量代码引用， 收益小于风险），字段含 source（FEISHU/MANUAL）区分数据来源；MANUAL 记录用 MANUAL_yyyyMMdd_000001 格式与飞书 rec 前缀记录 ID 天然隔离（回写 bitable 时的 MANUAL_ 前缀跳过 规则与此对应，见 xijian/CLAUDE.md 借鉴地图）。/admin/feishu/** 相关端点不能动 （gotchas 第 20 条，27 个端点是飞书多维表格自动化在调），本表的读写路径若被新系统接管需格外 小心不打断线上自动化。

2.5 项目 / 计划域

project/merchant 均为 0 行死表——项目/客户概念在旧系统里从未真正落地，customerName 全靠 payment_request/feishu_execution_record 里的自由文本字段承载，29 个客户名里 14 个匹配不上中台 项目（finance-ops.md 实测）。新项目域（P0-4.1）是从零设计，不是"迁移 project 表"。

life_account/life_account_poi 是来客商家账户/门店 POI 同步表，字段包含 GCJ02 坐标、 省市区代码——P0-4.1 场次的"允许 POI 集合"配置（基线 §7.3）预计依赖这两张表的同步结果。

3. 三分法落位（汇总）

已在 §1 各表分类列标注；快速索引（36 张核心业务表，§1.1–1.5）：

§1.6 系统辅助域（RBAC 五表/operation_log/sys_request_log/change_log/app_config/feishu_user/ feishu_table_manage/data_sync_log/invite_record/sys_config/sys_log/sys_file，均弃用不迁）+ banner（新域新表，功能保留但当前 0 行无历史负担）不计入上述 36 张统计，明细见 §1.6。

4. 迁移地雷清单（19 坑 + 文档实测发现，逐条标出处）

以下按"是否涉及数据结构/单位/语义"筛选自 19 条 backend-gotchas.md（略去纯前端/纯 API 参数类的 5 条：分页参数不统一、CORS 白名单、导出接口参数比列表少、付款筛选参数名、预选单批量接口不对称） + 三份 legacy 文档的实测发现：

  1. 枚举大小写/命名不一致：后端枚举大写下划线（UNSIGNED/FACE_EXPIRED），前端小写连字符； 字段名也不同（后端 actualCost，前端 amount）。[gotchas]
  2. 单条结算接口是 bug：POST /{id}/settle 代码写 status=12，注释写"已结算"；新模型只认 /batch-settle 的正确定义。[gotchas][order-state-machine]
  3. task.accepted_count/signed_up_count 计数字段会漂移：多条加减路径口径不一致，不要迁移 这两个冗余计数字段的历史值当真实数，改为实时查询。[gotchas]
  4. 时间格式两种：任务返回 ISO，达人返回空格分隔——展示层坑，落库层都是 DATETIME，无需处理 但字段命名/序列化约定要统一。[gotchas]
  5. task_order 没有 projectId：只能靠 taskId 间接关联项目，项目维度需新建不是迁移。 [gotchas][finance-ops]
  6. 任务状态 2（已结束）在数据库里永远不存在：是前端按 endTime 派生的展示态，DB 值仍是 1； 新模型若要落库这个态，需重新设计状态定义。[gotchas]
  7. 达人的"作品数"是死字段：老 account.workCount 接口从不返回；本次翻查 DouyinAccount 实体已确认没有这个字段（已随代码演进移除），不要在新模型里找它。[gotchas]
  8. 百分比标度两套并存（0-1 与 0-100 混用于不同接口）：非数据库结构问题，但迁移时若把旧 接口返回值直接落库要注意标度换算。[gotchas]
  9. 达人档案两个标签字段格式不同：tags 是 JSON 数组字符串，accountTypes 是逗号分隔—— douyin_account 表内三套标签体系（tags/specialtyCategories/accountTypes）两种格式两种 解析函数，新模型建议统一为单一 JSON 数组格式。[gotchas][core-modules]
  10. 达人年龄可能是 -1：抖音开放平台拿不到年龄时的哨兵值，是 truthy，判断需 age > 0。[gotchas]
  11. 部分响应含无效 UTF-8 字节：达人自我介绍等自由文本历史数据有脏字节，迁移导入脚本用 严格 UTF-8 解码会失败，需要容错处理（替换或跳过）。[gotchas]
  12. 测试库导入脱敏必须保持跨表映射一致：feishu_execution_record.payee_id_card 与 serviceshare_signing.id_card 靠值匹配（交集 671 人/82.7% 匹配率是核心指标）；user_no 同理，按行 id 打散会把真冲突/假冲突弄反。映射导入脚本要用统一 idmap/usermap。[gotchas]
  13. 人工付款删除接口曾因逻辑删除字段生成坏 SQL：新模型软删要走标准 ORM 逻辑删除，不要手写 局部 UPDATE。[gotchas]
  14. /admin/feishu/** 27 个端点不能动：飞书多维表格自动化在调，配置不在本仓库，新系统不用 但也不要碰这批表/端点背后的自动化。[gotchas]
  15. 0701 现有达人库表 ROI 公式实测是错的（算成了费用 MAX）：迁移/重算必须按基线 §7.4 公式 (成交GMV−达人费用)/达人费用 重新计算，不能照搬旧值。[baseline §2/§7.4][0701 实测]
  16. work_review_record.review_type 实体注释已过时：类注释与字段注释自相矛盾且都不完整， 权威口径 1=审稿/2=回填正片/3=补发随拍，以代码实际引用（TaskOrder.mainVideoUrl/casualVideoUrl） 为准。[system-and-data 实测][本次调研交叉核对]
  17. payment_request.approval_status 生产存在第 6 个值 SUBMIT_FAIL（297 条），实体注释没有—— 新模型状态枚举必须覆盖。[system-and-data 实测]
  18. task_order 与 feishu_execution_record 没有外键，只能靠 session_name + douyin_id 软关联对账——新模型若要建强关联，需先解决这批历史数据两侧字段不完全对齐的问题。[system-and-data]
  19. 视频时长（毫秒）与出镜时长（秒）单位不同（同在 work_review_record 一张表内），迁移新 模型时建议统一单位或在字段名里显式标注单位。[finance-ops.md published-links 同源问题]
  20. 上线前必补索引（若新模型仍需回查这些高量级表）：task.session_name、live_data 的 douyin_id/live_time、feishu_execution_record.session_name、 change_log(entity_type, entity_id)。[system-and-data]
  21. 灵工金额换算系数两份材料不一致（1.06 vs 1.062，见 §5 开放问题#4）——不要在没有确认前把 任一数字当权威硬编码进新模型（本身也违反"判定数字集中配置"铁律）。[finance-ops.md][baseline §7.6]

5. 给 P0-2.3 的开放问题

  1. 表总数对不上：system-and-data.md 称生产库 61 张业务表，本次清点到 49 个 JPA 实体 + 4 类 无实体表（shengyijing 系列记 1 项、sys_config、sys_log、sys_file）= 53 项。差额 8 张的可能原因： shengyijing 系列可能不止本次找到的 1 张（文档提"五张表"，本次未逐张确认表名）、或存在更多无 实体层的表未被本次搜索命中。需连测试库跑一次 information_schema.tables 全量核对（P0-2.3 或专门的库探查任务再连库）。
  2. 达人广场"19,299 行"采集数据具体落在哪张表：基线 §8 提到"达人广场采集全量进后台（已在抓， 实测 19,299 行）"，字段描述（昵称/等级/主页/30天销售额/核销额/播放量）与 douyin_account 高度 吻合，但 douyin_account.influencerId 未建联时是否允许为 null 需确认（若不允许，说明存在 另一张未被本次找到的采集表）。
  3. task_requirement.gender 字段是否已真正落库：实体 Javadoc 明确写"数据库表暂无此字段， 等待 Flyway V61 迁移执行后移除此注解"——本次未连库/未逐条核对 V61 迁移脚本内容与执行状态， 需确认该字段当前是否可用（若已跑过 V61 则已落库）。
  4. 灵工打款金额换算系数：finance-ops.md（旧后台梳理，2026-08-13）写"审批金额=实付×1.06"， 基线 v2.1 §7.6（2026-08-17）写"灵工金额=实际金额×1.062"——两者相差 0.2 个百分点，需向业务 确认权威系数，并确保它是配置中心可配项而非硬编码（无论哪个数字）。
  5. 个税预警阈值 ¥6250/月是否为固定值：finance-ops.md UI 文案提及"本月累计将超 ¥6250 个税 阈值"，基线文档未见对应条目，需确认这是固定政策值还是应纳入 §12A 配置清单。
  6. quality_douyin_account（人工优质池）与基线新"优质"分级的关系：本次判定为语义冲突建议 弃用旧表，但业务是否仍需要一个"运营手动重点关注名单"的独立概念（不叫"优质"）需产品确认， 避免调研判断替代了业务决策。
  7. task_tag 表是否还有实际消费场景：翻查 legacy 文档未见后台前端有标签筛选/展示的引用， 本次列为"待评估弃用"，建议 P0-2.3 阶段用 grep 或连测试库查一次该表当前行数辅助判断（若为 0 行且无代码引用可直接弃用不迁）。
  8. life_account/life_account_poi 与来客计划同步（P0-4.2）的数据通道关系：这两张表是否就是 P0-4.2"来客计划同步器"要复用/参照的表结构，还是独立的另一条同步链路，需要在设计商单/项目域 模型时与产品/已有同步代码（LinkeLifeAccountSyncServiceImpl.java，本次仅确认其存在未展开读） 进一步核实。

附：本文档信息来源清单