考点13：大文件上传需求和常见问题
-
普遍需求：在云存储、视频分享、在线教育等领域，用户上传大文件的需求日益普遍。
-
核心挑战：网络波动、不稳定性及客户端资源限制，常给用户带来不佳体验；传统整文件上传易因中断失败，还会占用大量内存和宽带资源，对用户设备和服务器造成负担。
-
网络中断风险
- 上传过程中网络不稳定或意外中断会导致整个上传任务失败，用户需从头重新上传，浪费时间和宽带。
-
客户端资源消耗
- 大文件上传会占用大量内存和宽带资源，尤其在低配设备（如移动设备）上，容易导致设备卡顿或资源耗尽。
-
服务器负担
- 若无有效的分片管理和断点续传机制，大文件上传失败后，服务器会存储许多不完整或重复的文件，浪费存储资源并增加维护难度。
-
用户体验不佳
- 上传过程中缺乏实时反馈（如进度条），或因频繁失败而无法继续上传，会严重影响用户的满意度和使用意愿。
考点14：大文件上传常见解决方案
-
文件分片
-
将大文件切成多个小的分片，每个分片单独上传到服务器。
-
此方式可提高上传的可靠性和效率，尤其在网络环境不稳定时。
-
-
分片的标识与管理
- 为每个分片分配唯一标识（如索引或哈希值），以便前后端协作追踪上传状态和重建文件。
-
分片大小的选择策略
-
分片大小的选择需综合考虑网络条件、文件大小和服务器性能。
-
通常，分片大小在几 MB 到几十 MB 之间较为合适。
-
-
分片文件合并
- 文件上传到服务器临时存储空间，等待全部分片上传完成后，进行合并以生成最终文件。
考点15：断点续传
-
分片上传的剩余风险
-
网络中断风险：上传过程中网络不稳定或意外中断，仍可能导致整个文件上传失败，用户需从头上传，浪费时间和带宽。
-
用户体验不佳：上传过程缺乏实时反馈，或因频繁失败无法继续，严重影响用户满意度。
-
-
断点续传的定义
-
是一种在数据传输过程中，若发送中断或失败，可从中断位置继续传输的技术。
-
避免从头重新传输文件，节省时间、宽带和资源，广泛应用于文件传输和下载，以提高可靠性和效率。
-
-
工作原理
-
记录传输状态
-
在数据传输过程中，系统记录已成功传输的数据量或位置。
-
避免从头重新传输，节省时间、带宽和资源，广泛应用于文件传输和下载以提高可靠性和效率。
-
-
中断检测
-
当数据传输中断时，系统会检测到该情况，并保存当前传输状态。
-
中断可能由网络问题、客户端或服务器故障等原因引起。
-
-
恢复传输
-
传输恢复时，系统读取之前保存的状态信息，从中断点开始传输未完成的数据。
-
减少重复传输部分，提高传输效率。
-
-
数据完整性校验
- 为确保数据完整性，客户端在恢复传输时可能进行数据校验（如 MD5 校验），确保已传输数据未损坏。
-
-
大文件上传中断后的实现步骤
-
文件分片：将大文件分割成多个固定大小的片段（如 2MB）。
-
上传请求：客户端逐个发送片段上传请求，附带片段和文件唯一标识。
-
状态记录：服务端接收片段，记录上传状态到数据库。
-
断点检测：上传中断后，客户端查询服务器已上传片段状态（需查询已上传数据）。
-
续传处理：从最后一个成功上传的片段继续上传剩余片段。
-
文件合并：所有片段上传完成后，服务器合并片段生成完整文件。
-
考点16：大文件上传的交互流程
前端传到服务器，服务器再传到 Minio
-
优点
-
集中管理
-
所有文件上传操作通过后端集中管理，便于实现身份验证、权限控制、文件处理等业务逻辑。
-
例如，可在文件上传到 Minio 之前生成缩减图或提取元数据。
-
-
安全性
- 后端可作为中间层，对上传文件进行安全检查和过滤，防止恶意文件上传到 Minio。
-
业务扩展逻辑
- 可在文件上传过程中加入更多业务逻辑，如文件内容预处理、格式转换。
-
-
缺点
-
性能压力
-
后端服务器需处理文件中转，增加服务器负载和响应时间。
-
尤其对于大文件，后端需先接收文件再传输到 Minio，会显著增加延迟。
-
-
单点故障
- 若后端服务端出现故障，整个文件上传流程将受影响，即使 Minio 正常，也无法完成上传。
-
资源占用
- 后端服务器需额外资源处理文件，在高并发下易导致服务器资源紧张。
-
前端直接传到 Minio
-
优点
-
减少延迟: 前端直接上传文件到Minio,减少了文件在后端的中转时间,显著提高了上传效率
-
减轻后端压力: 后端服务器不需要处理文件的中转, 可以专注业务逻辑处理,减少服务器的负载
-
高可用性 : 即使后端服务器出现故障,只要Minio服务器正常运行, 文件上传仍可以继续进行,提高了系统的高可用性
-
-
缺点
-
安全性
-
前端直接上传到Minio,需要生成并返回一个有效事情的凭证
-
增加了安全风险,需要确保上传凭证的安全性,防止被恶意利用
-
-
权限控制
- 虽然可以通过上传凭证实现一定程度的权限控制,但是相比后端集中管理,权限控制的灵活性和安全性可能会稍落
-
业务逻辑限制
- 前端直接上传文件到Minio, 后端无法在文件上传过程中加入复制的业务逻辑, 如文件内容的预处理, 格式转换等
-
考点17：大文件上传选择
大文件分片上传基本原理
文件上传: 将客户端的文件通过HTTP协议上传到服务器,并在服务器进行运行
分片上传: 将大文件拆分为多个小模块,逐一上传,最后在服务器端进行整合
前端实现
使用HTML5的File API 和Blob 对象来读取文件并分割成小块
使用AJAX技术将文件分块发送给后端,也可以采用其他方式
优缺点对比
原生方法:
-
后端实现:
-
使用javxa.servlet和javax.servlet.http 包中的类来处理文件上传
-
获取request 对象中的文件夹, 通过getInputStream() 方法获取输入流, 将文件内容写入服务器上的位置
-
-
优点
- 灵活度高: 可以根据具体需求进行定制,列如断点续传,文件读取,分块,传输,合并
-
缺点
- 复杂度高: 需要手动处理文件的分块,传输,合并,代码复制度较高
使用AWS-S3的API
-
后端实现
-
aws-java-sdk-s3 已经封装了相关API,直接调用即可
-
包括初始化上传任务,查询已经传输的分片,获取临时上传的预签名地址,合并分片文件等相关API
-
-
优点
- 开发效率高: SDK提供了丰富的API, 简化了大文件上传的开发过程,利用现场的解决方法,具有良好的兼容性和稳定性
-
缺点
- 学习曲线: 需要学习AWS S3的API 和相关概念, 有一定的学习成本
相关API
//==================大文件分片上传相关接口========================= /** * 查询分片数据 * @param bucketName 存储桶名称 * @param objectKey 对象名称 * @param uploadId 分片上传ID * @return 分片列表对象 */ PartListing listMultipart(String bucketName, String objectKey, String uploadId); /** * 1-初始化分片上传任务,获取uploadId,如果初始化时有 uploadId，说明是断点续传，不能重新生成 uploadId * @param bucketName 存储桶名称 * @param objectKey 对象名称 * @param metadata 对象元数据 * @return 初始化分片上传结果对象，包含uploadId等信息 */ InitiateMultipartUploadResult initMultipartUploadTask(String bucketName, String objectKey, ObjectMetadata metadata); /** * 2-生成分片上传地址，返回给前端 * @param bucketName 存储桶名称 * @param objectKey 对象名称 * @param httpMethod HTTP方法，如GET、PUT等 * @param expiration 签名过期时间 * @param params 签名中包含的参数 * @return 生成的预签名URL */ URL genePreSignedUrl(String bucketName, String objectKey, HttpMethod httpMethod, Date expiration, Map<String,Object> params); /** * 3-合并分片 * @param bucketName 存储桶名称 * @param objectKey 对象名称 * @param uploadId 分片上传ID * @param partETags 分片ETag列表，用于验证分片的完整性 * @return 完成分片上传结果对象 */ CompleteMultipartUploadResult mergeChunks(String bucketName, String objectKey, String uploadId, List<PartETag> partETags);}
考点18：查看别人分享怎么开发
需求
-
通过别人分享的文件链接,查看对应分享的文件 (要先登录自己的网盘才可以)
-
选择部分或全部分享文件, 或进入对应的文件夹, 转存到自己的网盘
前后端交互逻辑和解决方案
-
用户点击分享链接，一般调用后台基本分享信息 接口
GET /api/share/v1/visit?shareToken=XXXX -
上述接口会返回基本分享信息，包括：是否需要提取码、分享人信息等
-
前端根据返回的基本分享信息，是否需要提取码，分两个情况
-
情况一
-
免提取码，基本分享信息里面带有 token，请求头携带过去即可直接使用访问对应的分享文件
-
调用
GET /api/share/v1/detail接口，访问短链之后进入文件列表
-
-
情况二
-
需要提取码，基本分享信息里面无 token，先进入提取码界面，可以看到分享人信息
-
输入提取码校验，成功则后端会返回 token，请求头携带过去即可直接使用访问对应的分享文件
-
调用
GET /api/share/v1/detail接口，访问短链之后进入文件列表
-
-
-
进入分享文件的子文件，则统一调用接口
GET /api/share/v1/list_share_file（需要携带 token）
考点19：自定义注解的基础知识
-
起源：JDK 1.5 引入，用于补充元数据（MetaData），替代传统配置文件。
-
作用 ：代码里的特殊标记，常见如
@Override（重写）、@Deprecated（废弃）等。
|-------------|---------------------|------------------------------------------------------------------------------------------|
| 元注解 | 作用说明 | 关键属性 / 值 |
| @Target | 限定注解可作用的目标位置 | 取值为 ElementType 枚举，如： - METHOD：作用于方法 - TYPE：作用于类 / 接口 - FIELD：作用于属性 - CONSTRUCTOR：作用于构造器 |
| @Retention | 控制注解保留周期（编译 / 运行阶段） | 取值为 RetentionPolicy 枚举，如： - RUNTIME：保留到运行时（可反射获取，常用） - CLASS：保留到字节码 - SOURCE：仅源码保留 |
| @Documented | 生成 Javadoc 时包含此注解 | 无额外属性，标记用 |
| @Inherited | 允许子类继承父类的注解 | 无额外属性，标记用 |
语法：
-
声明格式：
public @interface 注解名 { ... }，自动继承Annotation接口。 -
支持默认值 ：通过
default关键字设置参数默认值，如String value() default "默认值";。 -
反射获取 ：运行时可通过反射 API（如
Method.getAnnotation()）读取注解信息。
考点20：Aop相关知识
核心思想 ：分离 "业务逻辑" 与 "横切逻辑"（如 token 校验），不入侵原有代码，通过切面（Aspect） 统一处理。
关键流程：
-
标记需校验的接口 ：在 Controller 方法上添加自定义注解（如
@CheckToken）。 -
定义切面（Aspect）：
-
用
@Aspect标记切面类，通过@Pointcut关联自定义注解（如@annotation(自定义注解全类名)）。 -
在
@Before/@Around通知中实现token校验逻辑（解析token、关联分享ID等）。
-
-
执行流程 ：请求进入
Controller时，AOP 拦截注解标记的方法，先执行切面逻辑，再走原有业务（Service → Mapper → 数据库）。
考点21：回收站是怎么设计的？
需求说明
-
回收站文件再手动操作删除的文件
-
彻底删除回收站文件执行后，原文件不可恢复
-
用户可以从回收站中恢复误删的文件或文件夹，恢复到原来的位置。
-
支持批量恢复操作，提高用户操作效率
注意
- 彻底删除文件是指删除关联关系，实际物理存储数据不删除（不清空物理存储内容，方便做分析和后续有人重新上传）
考点22：推理大模型和指令大模型怎么选择？
|------|------------------|----------------|
| 对比维度 | 指令大模型 | 推理大模型 |
| 核心能力 | 执行明确指令 | 解决复杂逻辑 / 数学问题 |
| 适用场景 | 客服对话、文案生成、API 文档 | 异常分析、财务解读、病症鉴别 |
| 输出特点 | 流畅自然 | 严谨、含推导步骤 |
| 资源消耗 | 轻量（可部署小参数模型） | 需大参数支持，消耗高 |
| 典型错误 | 偏离指令、生成无关内容 | 逻辑漏洞、计算错误 |
选择核心原则
-
任务复杂度：简单指令→通用模型，深度推理→专用模型。
-
容错成本：高风险场景（医疗 / 金融）优先选可解释性强的推理模型。
-
混合策略：前端用指令模型交互，后端用推理模型处理复杂任务。