后端应按文件语义划分独立处理通道：布局配置、原始数据、媒体文件、加密凭证四类通道分别使用适配的线程池与策略，通过fileType路由分发，保障资源隔离、失败不扩散及可观测性。

后端接收拖拽大屏上传的文件（如布局快照、导出配置、截图、Excel数据源等）时，不能用一个通用线程池硬吞所有类型——因为PDF解析、CSV解析、JSON Schema校验、图片缩略图生成的资源消耗模式完全不同。多态通道编排的核心，是让每类文件流按语义隔离处理：谁该用CPU密集型线程池、谁该走IO等待型调度、谁需要熔断降级、谁必须保证顺序，都由通道自己决定。

按文件语义划分物理处理通道
不同文件触发的后端动作差异极大，应为每类建立独立通道：

• 布局配置通道：接收 .json 或 .yaml 类型，校验 schema 后存入 MongoDB；走轻量同步校验 + 异步写库，主链路控制在 150ms 内
• 原始数据通道：接收 .csv / .xlsx，需逐行解析、字段映射、空值填充；用 ForkJoinPool.commonPool() 并行分片，单任务超时设为 30s，失败自动转为异步重试队列
• 媒体文件通道：接收 .png / .jpg / .pdf，做格式识别、DPI归一化、缩略图生成；绑定专用 IO 线程池（Executors.newCachedThreadPool()），每个任务自带 InputStream 和 MultipartFile 元信息
• 加密凭证通道：接收 .pem / .jks，只做密钥格式校验与权限绑定，不落地存储；走高安全等级线程池，启用 JVM 级别 SecurityManager 检查

用策略路由实现动态分发
前端上传时必须携带 fileType 字段（如 "fileType": "layout_config"），后端 Controller 不直接解析，而是交由 FileChannelRouter 路由：

• Router 根据 fileType 查策略注册表，匹配到对应 FileHandler（如 LayoutConfigFileHandler）
• Handler 将 MultipartFile 封装为标准 AsyncFileTask<FileResult>，投递至对应 BlockingQueue<FileTask> 或 Flux<FileTask>
• 各通道消费端使用独立线程池或 Schedulers.boundedElastic()，互不抢占资源，也避免线程饥饿

通道间协同与失败隔离
某些场景需跨通道联动，例如上传 Excel 后自动触发布局配置更新：

• Excel 解析成功 → 发布 DataImportSuccessEvent → 布局通道监听并拉取最新字段元数据
• 但媒体文件生成失败，不影响布局通道运行；仅记录告警并返回 FileResult.error("thumbnail_gen_failed")
• 所有通道缓存 Key 前缀按 channelName 隔离（如 layout:cache: vs media:cache:），不共享 ConcurrentHashMap 实例
• 通过 /actuator/file-channels 端点暴露各通道积压数、平均耗时、失败率，支持运行时启停某通道

避免常见误用陷阱

• 不要用同一个 ExecutorService 混跑 CPU 密集型（如 PDF 文字提取）和 IO 密集型（如 S3 上传）任务
• 不在 Callable 内部持有静态变量或共享 InputStream，每个任务应独占输入流并及时关闭
• fileType 必须由前端明确声明，后端不做 MIME 推断（防绕过校验），未识别类型直接拒收并返回 400 UnsupportedFileType

不复杂但容易忽略