当决定在什么时机将上传的文件转换时，需要权衡用户的体验和后台的资源消耗。以下是一些常见的方案及其利弊：

1. 即时转换（上传后立即转换）:
   • 优点：用户体验较好，上传后用户就可以直接预览文件，不需要等待。
   • 缺点：如果文件较大或者同时有多个用户上传文件，可能导致服务器资源紧张或响应延迟。
2. 异步转换（后台任务进行转换）:
   • 优点：不会影响用户的上传体验，服务器资源可以更平稳地分配。
   • 缺点：用户可能需要稍后再来查看转换后的文件。
3. 按需转换（用户预览时转换）:
   • 优点：只对真正需要预览的文件进行转换，节省资源。
   • 缺点：预览时需要等待，可能导致用户不太好的体验。

考虑到上述的优缺点，以下是一个推荐的流程：

1. 用户上传文件：用户将文件上传到服务器。
2. 文件存储：文件被存储在服务器的某个目录或者云存储上，并记录文件的元数据到数据库（例如，文件路径、上传时间、转换状态等）。
3. 异步转换：
   • 使用消息队列（如 RabbitMQ, Kafka）或者任务调度器（如 Spring @Scheduled, Quartz）来处理异步任务。
   • 上传成功后，将文件添加到待转换的任务队列中。
   • 后台有专门的服务或线程监听这个队列，取出文件并进行转换。
   • 转换成功后，更新数据库中的文件元数据，例如，转换状态、转换后的文件路径等。
4. 用户预览文件：
   • 用户选择一个文件进行预览。
   • 检查文件是否已经转换。如果已转换，直接显示；如果还在转换队列中，告知用户“文件正在处理中”。
   • 如果你采用的是按需转换策略，这时开始转换，并在转换完成后展示给用户。
5. 文件管理：
   • 可以定期清理老的、不再需要的文件，或者转换失败的文件。
   • 如果用户明确表示不再需要某个文件，可以立即删除原始文件和转换后的文件。

这个流程是一个综合考虑用户体验和服务器资源的推荐流程，但具体实现还需要根据你的应用场景和用户需求进行调整。