完整的导入导出功能

[gmij]

从1.10升级到1.13， 发现存在数据库变更 。 但并没有提供数据迁移脚本， 以及自动迁移能力。 沟通后发现， 目前只能逐个应用、逐个环境的导出再导入来实现迁移。 目前有超20个应用，每个应用有5个环境， 就要做100次的导出导入， 很麻烦。 希望提供一个一键导出和一键导入应用配置的能力。

[kklldog]

感谢反馈，这个需求我先按实现角度做一个初步判断：

1. 是否可行

从描述上看，这类需求通常是有实现空间的，但还需要结合 AgileConfig 当前的数据模型、接口兼容性以及控制台交互方式进一步确认边界。

2. 对现有项目的影响

主要需要评估以下几点：

• 是否会影响现有配置读取/发布流程
• 是否会引入兼容性变化，尤其是已有客户端或接口行为
• 是否需要新增配置项、数据库字段或管理界面入口
• 是否会增加运维复杂度、权限控制成本或性能开销

3. 可行方案的简单描述

如果要推进，比较稳妥的方式通常是：

• 先明确具体使用场景和预期行为
• 再确定是扩展现有能力，还是增加独立开关/模块
• 尽量保持默认行为不变，通过可选配置或渐进式方式落地

如果方便的话，欢迎补充更具体的业务场景、预期效果，以及你希望如何使用这个能力，这样可以更准确地评估设计方案。

[kklldog]

@super-niuma-001
请按我给的方案，给出更详细的设计方案
方案：

1. 第一步先做导出，导入功能在导出稳定后再说
2. 在应用列表的action bar 添加导出按钮
3. 选中的 app 可以被导出
4. 导出的内容包括 app 的属性字段，以及这个 app 最新的配置（分环境），历史版本信息不管
5. 导出的文件格式为json

[super-niuma-001]

@kklldog
我看了现有代码，当前仓库里已经有两个可以直接复用的基础能力：

• ConfigController.ExportJson(appId, env)：已经能导出单个 app + 单个环境的当前配置 JSON
• PreViewJsonFile + AddRange：已经有 JSON 导入预览/批量写入的基础形态

所以这次第一步我建议不要从“完整导入导出平台”起步，而是先补一个 应用维度的批量导出闭环，范围尽量收敛到你列的 5 点。

一、第一期目标

只做导出，不做导入；入口放在应用列表页 action bar；支持勾选多个 app 后一次导出成一个 JSON 文件。

导出内容包含：

1. app 自身属性
2. 该 app 在各环境下的最新配置
3. 不包含历史版本 / 发布流水 / 审计日志

这里“最新配置”我建议直接取 agc_config 当前有效数据，而不是 agc_config_published：

• 这样导出的就是控制台里此刻维护的最新状态
• 更符合“迁移/备份”场景
• 后续如果要支持“仅导出已发布版本”，可以再单独加选项，不要在第一期混进去

二、UI 方案

1）应用列表页增加多选

当前 src/pages/Apps/index.tsx 里还没有 rowSelection，所以第一步是在 ProTable 上补多选状态，例如：

• selectedRowKeys
• selectedRows
• rowSelection

2）在 action bar 增加“导出”按钮

位置和“新增应用”并列，建议行为：

• 未选择 app 时按钮置灰
• 选择 1 个或多个 app 后可点击
• 点击后直接下载一个 JSON 文件

按钮文案可以直接叫：导出
如果想更明确一点，也可以叫：导出选中应用

3）导出交互尽量简单

第一期不建议再弹复杂表单：

• 不做环境筛选
• 默认导出系统当前所有环境（通过 ISettingService.GetEnvironmentList() 获取）
• 不做历史版本选项
• 不做压缩包

这样能把流程压到最短：勾选 -> 点击导出 -> 下载 JSON。

三、后端接口设计

建议新增一个批量导出接口，不要复用单 app 的 ExportJson 硬塞参数。

接口建议

POST /app/Export

请求体：

{
  "appIds": ["app1", "app2", "app3"]
}

返回：

• application/json 文件流
• 文件名建议：agileconfig-export-yyyyMMddHHmmss.json

原因：

• 多个 app id 不适合继续走 query string
• 后续如果加导出选项（例如是否导出 secret、是否导出 inheritance、是否只导出指定环境）也更容易扩展

四、导出 JSON 结构建议

建议不要继续沿用当前单环境 key-value 的扁平 JSON 结构，因为现在是“多 app + 多环境 + app 属性”一起导出，必须显式分层。

我建议结构类似下面：

{
  "schemaVersion": 1,
  "exportedAt": "2026-04-10T01:23:45Z",
  "apps": [
    {
      "app": {
        "id": "sample-app",
        "name": "sample-app",
        "group": "default",
        "secret": "xxxx",
        "enabled": true,
        "type": 0,
        "inheritanced": false,
        "inheritancedApps": ["base-app"]
      },
      "envs": {
        "DEV": [
          {
            "group": "Redis",
            "key": "Host",
            "value": "127.0.0.1",
            "description": ""
          }
        ],
        "TEST": [],
        "PROD": []
      }
    }
  ]
}

字段建议说明

app 节点建议保留

• id
• name
• group
• secret
• enabled
• type
• inheritancedApps

这里我建议把 inheritancedApps 也一起带上，虽然你原话里说的是“app 的属性字段”，但如果后续做导入，不把继承关系导出来，导入后 app 结构会是不完整的。

config 节点建议只保留

• group
• key
• value
• description

第一期不要导出这些运行态/历史态字段：

• id
• createTime
• updateTime
• status
• onlineStatus
• editStatus

因为这些字段更像数据库内部状态，不适合作为跨实例迁移格式；后续导入时重新生成更安全。

五、服务层实现建议

方案上尽量复用现有服务，不要重写一套

后端可以在 AppController 或单独的 export service 里组装数据，大致流程：

1. 校验 appIds 非空
2. 根据当前用户权限过滤可见 app
3. 读取环境列表 ISettingService.GetEnvironmentList()
4. 对每个 app：
   • 读取 app 基础信息
   • 读取继承 app 列表
   • 遍历每个 env，调用现有 _configService.GetByAppIdAsync(appId, env)
5. 组装导出 DTO
6. 序列化为 JSON 并返回文件流

这样改动面最小，而且和现有存储模型是一致的。

六、权限建议

这个接口虽然挂在 app 维度，但导出的内容里包含配置值，所以权限上不能只看 App_Read。

我建议：

• 控制器至少要求用户具备 app/config 的读权限
• 同时对每个 app 再做一次当前用户是否可见的校验，避免“手工构造 appIds 导出未授权应用”

也就是说，前端按钮控制只是第一层，后端一定还要兜底。

七、和现有单环境导出的关系

现有 config/ExportJson 先保留，不动。

两者职责区分：

• config/ExportJson：单 app + 单 env 的配置导出
• 新的 app/Export：多 app + 全环境 + app 属性的迁移导出

这样兼容性最好，已有使用方式不会受影响。

八、第一期先不要做的内容

为了避免第一步做得太重，我建议以下内容都放到后续：

• 导入
• 导出 zip
• 导出历史版本
• 导出发布记录
• 环境筛选
• 字段级过滤
• 导出已发布配置 / 当前草稿二选一

先把“多 app 一键导出”做稳，用户痛点就已经解决一大半了。

九、如果按这个方案落地，代码层面大概会动到这些地方

• src/AgileConfig.Server.UI/react-ui-antd/src/pages/Apps/index.tsx
  • 增加表格多选
  • 增加导出按钮
  • 调用新的导出接口并下载文件
• src/AgileConfig.Server.UI/react-ui-antd/src/pages/Apps/service.ts
  • 增加批量导出请求方法
• src/AgileConfig.Server.Apisite/Controllers/AppController.cs
  • 新增导出 action
• 可能新增 export DTO / request model
• 复用 ISettingService、IAppService、IConfigService

如果你认可，我下一步可以直接按这个设计开始编码。

reply-to-comment-id: 4216076071

[kklldog]

@super-niuma-001
请开始开发

[super-niuma-001]

@kklldog 编码完成，PR已推送：#237

reply-to-comment-id: 4221560958

[kklldog]

@super-niuma-001
导出功能已经合并到 master 分支。后面我想完善导入功能，请先帮忙设计详细方案。

[super-niuma-001]

@kklldog
我重新梳理了一下现有代码和上一步导出方案，导入这一步我建议不要继续复用现在配置页里的 PreViewJsonFile + AddRange 来硬扩，而是单独做一套面向“导出包”的应用级导入流程。原因是两者目标已经不一样了：

• 现有配置页导入：本质是单 app + 单 env + 追加配置
• 现在要做的导入：本质是多 app + 多 env + app 元数据/继承关系 + 配置快照恢复

如果还沿用旧导入模型，会马上遇到几个问题：

1. 只能导当前 env，不能表达多环境
2. 只能新增，不能表达“覆盖/删除缺失项”
3. 不能导 app 属性和继承关系
4. 导入后默认还是待发布状态，无法真正解决迁移场景

所以我建议第二阶段导入按下面的结构做。

---

一、导入目标（和导出方案保持闭环）

导入输入直接复用导出生成的 JSON 结构，也就是把上一步的导出文件作为这一步的唯一正式输入。

也就是说：

• app/Export 导出的文件，可以直接喂给新的 app/ImportPreview / app/Import
• 不再把“应用级导入”设计成任意 JSON 结构
• 配置页现有的“导入 JSON”功能继续保留，作为轻量编辑工具，不和这次混在一起

这样好处很明显：

• 格式闭环，不会出现“能导出但不能原样导回”
• 后续如果 schema 升级，可以靠 schemaVersion 做兼容
• 用户理解成本最低：导出来的文件，就是可回放的快照

---

二、导入语义建议：以“快照恢复”而不是“仅追加”为核心

我建议这次应用级导入的核心语义定义成：

把导入文件里的 app + env 最新配置快照，同步到目标实例。

这里我更倾向于做成 replace/sync snapshot 语义，而不是 merge-only。

原因是这个 issue 的真实诉求是迁移/恢复：

• 如果只做 merge，不删除目标端多余配置
• 那么导入完成后目标实例会残留旧 key
• 最终配置并不等于导出时的快照，迁移语义是不成立的

所以我建议第一版应用级导入，对文件中出现的 app/env按“快照同步”处理：

• 文件里有、目标端没有 → 新增
• 文件里有、目标端也有但值不同 → 更新
• 目标端有、文件里没有 → 删除或标记删除

但这个“删除”一定要放在预览页明确展示，不能静默执行。

边界建议

为了降低风险，我建议删除范围只限定在：

• 导入文件中出现的 app
• 这些 app 下 导入文件中出现的 env

不要去碰：

• 文件里根本没出现的 app
• 文件里没列出的 env

这样不会因为一次导入把整库误清掉。

---

三、导入后是否自动发布：我建议支持，而且最好做成可选项

这个点我觉得很关键。

因为上一步导出方案导的是 agc_config 当前最新配置，不是历史版本；而 AgileConfig 里真正对客户端生效的通常还是发布后的数据链路。

如果导入只是把数据写回 agc_config，但不发布，那么迁移场景里用户还是要逐个 app/逐个 env 再点一次发布，痛点并没有真正消掉。

所以我建议导入时提供一个选项：

• publishAfterImport = true/false

默认建议

我倾向于：

• 应用级导入默认勾选“导入后自动发布”
• 但允许用户取消

执行语义

• 如果勾选：每个受影响的 app + env 在导入完成后自动触发一次 publish
• 如果不勾选：则只导入到当前配置，保持待发布状态

为什么这样更合理

• 迁移/备份恢复场景，通常希望导入后尽快可用
• 测试/演练场景，又可能只想先导入再人工核对
• 做成选项，兼顾两类诉求

---

四、接口设计建议

我建议不要把导入做成一个一步到位接口，而是拆成预览和执行两步。

1）预览接口

POST /app/ImportPreview

输入：

• multipart 上传导出 JSON 文件
• 可附带导入选项（比如是否自动发布）

输出建议：

{
  "success": true,
  "data": {
    "schemaVersion": 1,
    "apps": [
      {
        "appId": "sample-app",
        "appAction": "create|update|skip",
        "inheritanceAction": "replace|skip",
        "envs": [
          {
            "env": "DEV",
            "addCount": 10,
            "updateCount": 3,
            "deleteCount": 2,
            "conflictCount": 0,
            "publishWillRun": true
          }
        ],
        "warnings": []
      }
    ],
    "warnings": [],
    "errors": []
  }
}

2）执行接口

POST /app/Import

输入建议两种方式里选一种：

方案 A：再次上传原文件执行

优点：无服务端预览缓存，简单直接
缺点：预览和执行之间会重复解析一次

方案 B：预览后返回 previewId，执行时只传 previewId

优点：预览结果和执行参数完全一致，体验更稳
缺点：要维护临时缓存

我个人更倾向 方案 B，因为导入是高风险操作，预览和执行最好绑定在同一份解析结果上，避免用户在预览后又换了文件。

---

五、后端执行顺序建议

执行顺序我建议这样排：

第一步：校验整个导入包

先做完整校验，不要边导边报。

校验点至少包括：

• schemaVersion 是否支持
• appId 是否重复
• 同一 app 下 env 是否重复
• 同一 env 下 (group,key) 是否重复
• 继承 app 是否存在于系统或导入包中
• 继承关系是否形成环
• 当前用户是否有这些 app 的读/写权限
• app 类型与继承关系是否匹配

只要有阻断性错误，就不进入执行。

第二步：先处理 app 元数据

按 app 维度先做 upsert：

• 不存在则创建
• 存在则更新允许覆盖的字段

我建议第一版允许覆盖这些字段：

• name
• group
• enabled
• secret
• type/inheritanced

保留这些系统字段由服务端自己控制：

• creator
• createTime
• updateTime

第三步：再处理继承关系

因为继承关系依赖 app 已存在，所以应在 app upsert 之后执行。

这里建议语义为：

• 对导入文件中出现的 app，用导入文件里的继承关系替换目标端当前继承关系

原因很简单：

• 导出已经把 app 快照导出来了
• 导入时如果不替换继承关系，那恢复后的最终配置链可能不一致

第四步：按 app + env 同步配置快照

这里建议单元粒度是 app + env，每个单元内做：

• 加载目标端当前 agc_config
• 和导入快照做 diff
• 算出 add / update / delete 三类变更
• 落库

这里我建议不要复用现在的 AddRange 直接硬做，因为它只支持新增且遇到重复 key 就失败；更适合新增一个应用级 import service，把 diff 和批量更新/删除封进去。

第五步：按选项决定是否自动发布

如果 publishAfterImport = true：

• 对本次有变更的 app + env 批量调用发布逻辑
• 发布日志可以统一写成类似：
  • import from agileconfig export package
  • 或带时间/文件摘要

---

六、事务边界建议

这个项目里 env 很可能对应不同仓储/不同数据源访问器，所以我不建议一上来追求“整个导入包全局事务”。实现成本高，失败恢复也复杂。

更稳妥的事务边界建议是：

• 以单个 app + env 为事务单元
• app 元数据和继承关系单独一组事务
• 每个 env 导入成功/失败都记录结果

这样做的好处：

• 实现复杂度可控
• 某个 env 失败不会把整个任务的状态搞得完全不可见
• UI 上可以清楚展示“哪些成功、哪些失败”

如果后面要做更强的一致性，再考虑任务补偿机制。

---

七、前端交互建议

既然导出入口已经在应用列表 action bar，那导入我建议也放在应用列表页，而不是塞回配置页。

UI 流程建议

1. Apps 页 action bar 增加“导入”按钮
2. 打开导入弹窗
3. 上传导出文件
4. 调用 ImportPreview
5. 展示预览结果
6. 用户确认后执行 Import
7. 展示执行结果（成功多少 app/env，失败多少）

预览页建议至少展示这些信息

• 涉及多少个 app
• 每个 app 是创建还是更新
• 每个 env 的 add/update/delete 数量
• 是否会更新继承关系
• 是否会自动发布
• 风险提示（例如将删除多少个现有 key）

这样用户在点确定前，知道系统到底要改什么。

---

八、和现有配置页导入功能的关系

我建议明确分层，不要混淆：

保留现有能力

config/PreViewJsonFile + AddRange

• 继续服务于“在某个 app 的某个 env 下手工导一份 JSON”
• 语义仍然是轻量编辑/批量新增

新增应用级能力

app/ImportPreview + app/Import

• 服务于“导出包回放 / 跨实例迁移 / 备份恢复”
• 语义是应用级快照导入

这两套能力共存比较合理，用户也容易理解。

---

九、第一版我建议暂时不做的内容

为了避免导入一期过重，我建议这些先别进第一版：

• 字段级冲突交互编辑
• 跨 appId 重命名导入
• 选择性只导某几个 env
• zip/多文件包
• 历史版本导入
• 发布历史/审计日志恢复
• 失败回滚到导入前快照

第一版只要把下面这条主链路打通，就已经很有价值：

导出包上传 → 预览变更 → 导入 app/继承/多环境配置 → 可选自动发布

---

十、如果按这个方案落地，代码上我预估会动到这些地方

• src/AgileConfig.Server.UI/react-ui-antd/src/pages/Apps/index.tsx
  • 增加导入按钮和导入预览弹窗
• src/AgileConfig.Server.UI/react-ui-antd/src/pages/Apps/service.ts
  • 增加 importPreview / importApps
• src/AgileConfig.Server.Apisite/Controllers/AppController.cs
  • 新增导入预览 / 导入执行接口
• 新增 import request / preview result DTO
• AgileConfig.Server.Service
  • 新增应用级 import service，负责校验、diff、执行、可选自动发布
• 可能复用：
  • IAppService
  • IConfigService
  • ISettingService
  • 现有 publish 逻辑

如果你认可，我下一步可以按这个设计继续拆实现任务，先把 preview + import service DTO/流程 定下来，再开始编码会更稳。

reply-to-comment-id: 4229594260

[kklldog]

@super-niuma-001
这一版的导入建议继续简化难点。

1. 导入的应用必须是新建的，如果已经存在相同名字，相同Id的应用直接拒绝导入
2. 所有导入的配置项目全部初始化成新增
3. 不要默认勾选导入后自动发布，默认不勾选

[super-niuma-001]

@kklldog

收到，你这次是把导入的语义继续往“保守、可落地”方向收了。我觉得这 3 条收得对，这样第二阶段就不再是“迁移同步器”，而是一个基于导出包的新应用初始化工具，复杂度会低很多。

我按你这版要求，整理成一个更可执行的设计方案。

一、这期导入的目标重新定义

这期导入不再追求：

• 已有应用覆盖导入
• 配置 diff/merge
• 删除缺失项
• 默认自动发布

而是只做：

把导出文件里的 app + 各环境配置，作为一个“新应用模板”导入到当前系统。

核心语义就是两个字：新建。

也就是说，只要目标系统里已经存在：

• 相同 AppId 的应用，或者
• 相同 Name 的应用

就直接拒绝导入，不进入半成功状态。

---

二、导入规则建议明确成下面 5 条

1）导入对象必须是新应用

我建议按你说的直接做硬校验：

• 文件里的每个 app，在落库前都检查 Id 是否已存在
• 同时检查 Name 是否已存在
• 任一冲突即该 app 不允许导入

这里我建议预览阶段就把冲突查出来，不要到真正提交时才告诉用户。

2）所有配置项都初始化成“新增”

也就是不要复用“导入到现有 app 然后比对更新”的老逻辑。

导入时每条配置都按“新插入配置记录”处理：

• 直接写入 agc_config
• 状态等同于用户刚新增
• 不做 update/merge 分支

因为 app 本身就是新建的，所以这里天然不需要 diff。

3）默认不自动发布

UI 上提供一个 checkbox：导入后自动发布

• 默认：不勾选
• 用户手动勾选才执行发布

这样风险更低，也和你说的一致。

4）导入范围只处理导出文件里的“当前快照”

继续沿用上一步导出文件：

• 导入 app 基本属性
• 导入各环境下的最新配置
• 不处理历史版本
• 不处理发布历史
• 不处理审计记录

5）整个 app 级导入建议按“单 app 原子”执行

如果一个导出包里有多个 app，我建议粒度是：

• 每个 app 各自事务提交
• 单个 app 导入失败，不影响其他 app

这样更利于批量导入时排错。

---

三、UI 方案建议

我建议入口放在应用列表页 action bar，和导出形成闭环。

1）增加“导入”按钮

位置和“导出”并列。

点击后弹一个导入对话框，内容尽量简单：

• 上传 JSON 文件
• 预览结果
• 导入后自动发布 checkbox（默认不勾选）
• 确认导入

2）导入流程分两步

第一步：预览

上传文件后，调用预览接口，返回：

• 文件是否合法
• 包含多少个 app
• 哪些 app 可以导入
• 哪些 app 因 Id/Name 冲突被拒绝
• 每个 app 包含哪些 env、多少条配置

第二步：正式导入

用户确认后再真正落库。

这样用户在点“导入”前，就知道哪些 app 会失败，不会黑盒执行。

---

四、后端接口建议

我建议导入和预览分成两个接口。

1）预览接口

POST /app/ImportPreview

请求：multipart/form-data

• file: 导出 JSON 文件

返回结构建议：

{
  "schemaVersion": 1,
  "apps": [
    {
      "appId": "app1",
      "name": "app1",
      "canImport": true,
      "reason": null,
      "envCount": 3,
      "configCount": 120
    },
    {
      "appId": "app2",
      "name": "app2",
      "canImport": false,
      "reason": "AppId already exists"
    }
  ]
}

这里建议 reason 至少区分：

• AppId already exists
• AppName already exists
• Invalid schemaVersion
• Invalid file format

2）正式导入接口

POST /app/Import

请求：

• file: 导出 JSON 文件
• publishAfterImport: true/false

也可以做成：

• 前端先上传文件得到 preview token
• 再用 token 调 Import

但如果这期想省事，直接再次上传同一个文件也可以，先不引入临时存储。

---

五、导入执行顺序建议

对单个 app，我建议顺序如下：

1）先做校验

• schemaVersion 是否支持
• app 基本字段是否完整
• environments/configs 结构是否合法
• appId 是否存在
• appName 是否存在

2）创建 app

先插入 app 主记录。

3）按环境批量插入配置

遍历导出文件中的 env：

• 组装成新的 Config 实体
• Id 使用目标系统新生成值，不复用导出侧配置记录主键
• 标记为新增态
• 批量写入 agc_config

这里建议“新增态”的含义保持和当前系统已有逻辑一致，不要单独发明一套新状态。

4）按需自动发布

如果 publishAfterImport = true：

• 对导入到的每个 env 走一次现有发布流程

如果为 false：

• 到这里结束，保持未发布状态

---

六、数据字段处理建议

app 字段

建议导入：

• appId
• name
• group
• secret
• enabled/status（如果导出里有）
• inherit/parent 相关字段（如果导出结构已包含）

但这里我建议对“继承关系”单独加一个校验：

• 如果导入包里的 app 依赖某个 parent app
• 而该 parent 不在本次导入包里、目标系统里也不存在
• 那么预览时就提示风险或直接拒绝

否则会导入出一个悬空继承关系。

config 字段

建议只导业务必要字段：

• key
• value
• group
• status / desc / remark（如果有）
• env

不要导入源库里的数据库主键、审计字段、历史版本标识。

---

七、失败处理建议

这期我建议不要做“导入一半继续补偿”的复杂模型，直接收敛成：

单 app 内：事务回滚

一个 app 导入中只要：

• app 创建失败
• 某个 env 配置插入失败
• 自动发布失败（如果你希望发布也算导入的一部分）

就把这个 app 整体回滚。

多 app：逐个执行，分别返回结果

最终返回：

• 成功几个
• 失败几个
• 每个 app 的失败原因

这样前端结果页也容易展示。

---

八、我建议的第一版范围

为了尽快落地，我建议这一版先只做下面这些：

1. 应用列表页增加导入按钮
2. 支持上传导出 JSON 文件
3. 预览阶段校验 schema + appId/name 冲突
4. 仅允许导入“新应用”
5. 所有配置按新增插入
6. 导入后自动发布 默认不勾选
7. 单 app 事务、批量导入逐个执行

先不要做：

• 导入到已有 app
• 配置 merge/diff
• 冲突覆盖策略
• 历史版本恢复
• 跨实例复杂映射

---

九、如果按这个方案开发，代码层我建议拆成 3 块

1）Import file parser

负责：

• 解析导出 JSON
• schema 校验
• 转成内部 DTO

2）Import preview service

负责：

• 检查 appId/name 冲突
• 检查 parent/inherit 依赖是否可满足
• 生成前端预览结果

3）Import execute service

负责：

• 创建 app
• 批量插入 config
• 按需自动发布
• 返回逐 app 执行结果

这样后面如果你再放开“导入到已有 app”，只需要扩展 execute/preview 层，不用重写文件解析。

如果你认可这版收敛方案，我下一步可以直接继续细化成：

• 导出 JSON 对应的导入 DTO 结构
• ImportPreview / Import 的 controller & service 方法签名
• 前端导入弹窗和预览列表字段
• 哪些现有 service 可以直接复用

reply-to-comment-id: 4229744696