背景
在 #42 及用户反馈（524 配置复现）中确认：用户可能将 SDXL 等其它模型类型的训练配置（TOML / JSON / 专家模式 / 历史参数 / 预设）导入到 Anima 等不匹配的 WebUI 训练页面。
当前导入逻辑（findChangedDataBySchema）只做「字段是否在 schema 中存在」的过滤，不校验 model_train_type 与当前页面是否一致。大量共享字段（学习率、batch size、数据集等）能正常 merge，界面提示「导入成功」，但 hidden 的 model_train_type 可能被静默覆盖（例如 Anima 页默认 anima-lora 被改成 sdxl-lora），直到点击「开始训练」才在后端暴露问题。
期望行为
当用户将 A 模型训练页 的配置导入到 B 模型训练页 时：
1. 类型匹配 → 允许导入
配置的 model_train_type（或可推断的训练类型）与当前页面一致时，正常导入。
仅含共享通用字段、缺少 model_train_type 的旧配置，应能按当前页面类型补全并导入（向后兼容 ）。
2. 类型不匹配 → 引导跳转，而非静默成功
检测到配置来自其它训练类型（如 sdxl-lora 导入 Anima 页）时，不应 仅提示「导入成功」。
应弹出明确引导，例如：
「检测到这是 SDXL LoRA 配置，是否跳转到 SDXL 训练页？」
提供「跳转并应用配置」/「取消导入」选项。
3. 配置有问题 → 拒绝导入并说明原因
以下情况应 拒绝导入 （或拒绝应用），并给出 具体、可操作的错误信息 ，而非 generic「导入失败」：
场景
示例错误提示
训练类型与当前页不匹配且用户拒绝跳转
「配置为 sdxl-lora，当前页面为 Anima LoRA，请在 SDXL 训练页导入」
缺少当前页必填字段
「Anima 训练需要 qwen3 与 vae 路径，当前配置未包含」
含当前页不支持的专有字段且无对应页面
「配置含 flux 专用字段，请前往 Flux 训练页」
TOML/JSON 语法错误
指出解析失败位置（行号/字段名）
字段类型不合法
「max_train_epochs 应为数字，当前值为 "abc"」
向后兼容要求（必须保留）
本次及后续相关改动 必须继续支持旧版本导出的 TOML / JSON ，包括但不限于：
config/autosave/ 下的历史 autosave JSON专家模式导出的 .toml 文件
旧版 model_train_type 命名（如 sd3-lora 对应 Anima）
缺少 model_train_type 但含 Anima 专用字段（qwen3、vae、networks.lora_anima 等）的配置 — 后端已有推断逻辑（resolve_model_train_type），前端导入时不应因此拒绝纯 SDXL / SD1.5 旧配置在对应页面导入仍应正常工作
不应 因新增校验而破坏：用户在正确页面 导入同类型 旧配置的正常路径。
现状与已有兜底
层级
现状
前端导入
schema 字段过滤，无 train_type 交叉校验；Anima 的 model_train_type 为 .hidden()，易被覆盖
后端提交
已有 resolve_model_train_type()：Anima markers 存在时覆盖 stale sdxl-lora（#42 相关修复）
Flux/Lumina
model_train_type 为 .disabled()，相对不易被误改
后端兜底应保留为最后一道保险 ，不能替代前端第一道门。
建议实现方案（供讨论）
P0 — 导入守门
导入 / 应用预设 / 读历史 / 读 autosave 时，解析 model_train_type 或从字段推断训练类型。
与当前页 trainType（frontmatter）比对：
一致 → 导入；对 hidden/disabled 的 model_train_type 强制写入当前页默认值 ，忽略文件中的冲突值（同页旧配置兼容）。
不一致 → 弹窗引导跳转对应训练页；用户拒绝则拒绝导入并说明原因。
Anima schema：model_train_type 考虑从 .hidden() 改为 .disabled()（与 Flux 一致）。
P1 — 校验增强
专家模式保存/训练前做同样校验。
统一 frontmatter sd3-lora 与 schema anima-lora 命名，减少歧义。
验收标准
关联
v2.3.0 及更早整合包中 Anima 官方模型被误判为非 SD/Flux/Lumina 模型 #42 复现配置：docs/issues/16/20260521-105322.toml（用户 524 场景）
相关代码：frontend/dist/assets/layout.*.js（findChangedDataBySchema）、mikazuki/schema/sd3-lora.ts、mikazuki/app/api.py（resolve_model_train_type）
标签建议
enhancement frontend ux good first issue（若拆分前端子任务）
背景
在 #42 及用户反馈（524 配置复现）中确认：用户可能将 SDXL 等其它模型类型的训练配置（TOML / JSON / 专家模式 / 历史参数 / 预设）导入到 Anima 等不匹配的 WebUI 训练页面。
当前导入逻辑（
findChangedDataBySchema）只做「字段是否在 schema 中存在」的过滤，不校验model_train_type与当前页面是否一致。大量共享字段（学习率、batch size、数据集等）能正常 merge，界面提示「导入成功」，但 hidden 的model_train_type可能被静默覆盖（例如 Anima 页默认anima-lora被改成sdxl-lora），直到点击「开始训练」才在后端暴露问题。期望行为
当用户将 A 模型训练页 的配置导入到 B 模型训练页 时：
1. 类型匹配 → 允许导入
model_train_type（或可推断的训练类型）与当前页面一致时，正常导入。model_train_type的旧配置，应能按当前页面类型补全并导入（向后兼容）。2. 类型不匹配 → 引导跳转，而非静默成功
sdxl-lora导入 Anima 页）时，不应仅提示「导入成功」。3. 配置有问题 → 拒绝导入并说明原因
以下情况应 拒绝导入（或拒绝应用），并给出 具体、可操作的错误信息，而非 generic「导入失败」：
向后兼容要求（必须保留）
本次及后续相关改动 必须继续支持旧版本导出的 TOML / JSON，包括但不限于：
config/autosave/下的历史 autosave JSON.toml文件model_train_type命名（如sd3-lora对应 Anima）model_train_type但含 Anima 专用字段（qwen3、vae、networks.lora_anima等）的配置 — 后端已有推断逻辑（resolve_model_train_type），前端导入时不应因此拒绝不应因新增校验而破坏：用户在正确页面导入同类型旧配置的正常路径。
现状与已有兜底
model_train_type为.hidden()，易被覆盖resolve_model_train_type()：Anima markers 存在时覆盖 stalesdxl-lora（#42 相关修复）model_train_type为.disabled()，相对不易被误改后端兜底应保留为最后一道保险，不能替代前端第一道门。
建议实现方案（供讨论）
P0 — 导入守门
model_train_type或从字段推断训练类型。trainType（frontmatter）比对：model_train_type强制写入当前页默认值，忽略文件中的冲突值（同页旧配置兼容）。model_train_type考虑从.hidden()改为.disabled()（与 Flux 一致）。P1 — 校验增强
sd3-lora与 schemaanima-lora命名，减少歧义。验收标准
model_train_type的 Anima 旧配置在 Anima 页：仍可导入并成功训练sd3-lora旧命名配置在 Anima 页：仍可识别并兼容关联
docs/issues/16/20260521-105322.toml（用户 524 场景）frontend/dist/assets/layout.*.js（findChangedDataBySchema）、mikazuki/schema/sd3-lora.ts、mikazuki/app/api.py（resolve_model_train_type）标签建议
enhancementfrontenduxgood first issue（若拆分前端子任务）