1. 项目概述：从“传文件”到“瞬传”的蜕变

那天下午，同事在群里喊：“谁有最新的测试报告？发我一下，急！”紧接着就是一连串的“文件已过期”、“链接失效了”、“网盘太慢，还得登录”。这场景，是不是太熟悉了？一个看似简单的“传文件”需求，背后却是一地鸡毛：局域网共享文件夹权限复杂、微信/QQ有大小限制且容易失效、网盘需要账号且上传下载速度感人。作为一个有点“技术洁癖”的开发者，我决定不再忍受。我的目标很明确：做一个工具，让我和我的团队能在任何有网络的地方，像在本地拖拽一样，瞬间完成文件分享。这就是“瞬传”项目最初的萌芽。

这个项目，我把它命名为“瞬传”，核心诉求就三点： 极简 （点开即用，无需复杂配置）、 快速 （充分利用带宽，点对点直传优先）、 可靠 （链接可管理，传输稳定）。听起来简单，但实现路径却充满选择。我最初的想法是用最纯粹的HTML+JavaScript写个单页应用，利用WebRTC尝试点对点传输，快速验证想法。这就是项目的第一阶段。但随着我想把它做得更健壮、功能更完整（比如用户管理、历史记录、公网访问），技术栈开始膨胀，最终演进成了一个基于Spring Boot的完整后端服务，并用Docker封装以便于部署。整个历程，就是一部微型的“个人全栈开发演进史”，而WorkBuddy作为我的AI编程伙伴，在其中扮演了从“代码提示器”到“系统架构顾问”的关键角色。

2. 技术选型与架构演进之路

2.1 为什么起点是纯HTML/JS？

很多项目一开始就想着用重框架，但我认为对于验证核心创新点（这里是P2P文件传输）来说，轻量起步至关重要。选择纯静态HTML+JavaScript作为V1.0，基于几个非常实际的考虑：

1. 零环境依赖，极致简单 ：一个 index.html 文件，用浏览器打开就能运行。这对于向非技术同事演示、快速收集第一手反馈来说，门槛几乎为零。我不需要跟他们解释如何安装Node.js、配置开发环境。
2. 聚焦核心协议 ：WebRTC是实现浏览器端点对点传输的基石。在纯前端环境中，我可以集中精力研究 RTCPeerConnection 、 RTCDataChannel 这些API，而不被后端框架、数据库等无关问题干扰。最初的版本，就是一个页面同时扮演信令服务器（用简单的 BroadcastChannel 或手动交换SDP）和文件收发端。
3. 快速试错与迭代 ：想法行不行，半小时出原型。我用WorkBuddy直接描述需求：“用原生JavaScript写一个通过WebRTC传输文件的页面，要有拖拽上传和进度显示。”它能快速生成基础代码骨架，我只需调整UI和调试连接逻辑。这种即时反馈的开发节奏，对于探索性项目是无价的。

注意 ：纯前端P2P的致命弱点在于“信令”(Signaling)。你需要一个第三方服务器来帮助两个浏览器交换网络信息（SDP/ICE候选）。在V1.0，我用了非常取巧但 仅限局域网 的方式：让用户手动复制粘贴一大段文本（SDP信息）到聊天窗口来完成“握手”。这虽然笨拙，但完美验证了技术可行性。

2.2 为何最终锚定Spring Boot + Docker？

当“能用”的Demo出来后，更多现实需求涌现：“我想发个链接给别人就能收文件”、“昨天传的文件我想删掉”、“怎么知道谁传了什么”。这时，纯前端的玩具就不够用了。技术栈的升级是必然的。

1. 后端选择Spring Boot的理由 ：

   • 生态与效率 ：我需要快速构建RESTful API（用于文件元数据管理、用户会话）、集成WebSocket（用于更优雅的信令交换）、操作数据库（记录文件、用户）。Spring Boot的“约定大于配置”和丰富的Starter（如 spring-boot-starter-web , spring-boot-starter-websocket , spring-boot-starter-data-jpa ）让我能像搭积木一样快速组装出健壮的后端服务。向WorkBuddy提问：“用Spring Boot创建一个提供文件上传元信息接口的Demo，使用H2内存数据库”，它能立刻给出包含实体、仓库、控制器、配置的完整代码块，我只需填充业务逻辑。
   • 稳定性与成熟度 ：对于可能长期运行、承受一定并发的小型服务，Spring Boot的稳定性、监控（Spring Boot Actuator）和庞大的社区支持是定心丸。我不需要在底层连接池、事务管理上耗费太多精力。

2. 容器化选择Docker的理由 ：

   • 环境一致性 ：“在我机器上好好的，怎么到你那就挂了？”——Docker镜像从根本上解决了这个问题。我将Spring Boot应用、它的Java运行环境、甚至前端构建后的静态资源，全部打包进一个镜像。
   • 简化部署与扩展 ：无论是在本地测试，还是在云服务器上部署，一行 docker run 命令（或一个 docker-compose.yml 文件）就能启动整个“瞬传”服务。未来如果需要添加Redis做缓存、Nginx做反向代理，在Docker Compose中编排也变得非常清晰。
   • 资源隔离与安全 ：数据库（如PostgreSQL）可以运行在独立的容器中，与应用容器隔离。通过配置网络和卷，既能保证数据持久化，又能限制容器间的访问权限，比直接在宿主机上安装一堆服务要清爽和安全得多。

架构演进图示 ： 最终，“瞬传”的架构可以简单理解为前后端分离模式：

• 前端 ：仍然是HTML/JS/CSS，但已从“全功能单页”退化为“专注于UI交互的应用”。它通过WebSocket与后端信令服务器通信，通过HTTP API获取文件列表，通过生成的链接分享文件。
• 后端（Spring Boot应用） ：
  • WebSocketConfig & SignalingController : 处理WebRTC信令交换。
  • FileInfoController : 处理文件元数据（名称、大小、上传者、过期时间、唯一访问码）的CRUD。
  • UserController : 简单的用户认证（基于Token或Session）。
  • 数据库：存储文件元数据和用户信息。
• 基础设施（Docker） ：一个 Dockerfile 定义应用镜像，一个 docker-compose.yml 可能定义应用容器、数据库容器、以及Nginx容器（负责静态文件服务和SSL反向代理）。

3. 核心模块拆解与实现细节

3.1 前端核心：WebRTC文件传输的实现与优化

前端是整个体验的门面，也是技术难点最集中的地方。核心流程是：用户A选择文件 -> 前端创建 RTCDataChannel -> 通过信令服务器协商建立P2P连接 -> 通过 DataChannel 分片发送文件数据 -> 用户B接收并重组文件。

关键代码与逻辑 ：

// 1. 创建PeerConnection，配置STUN服务器（帮助穿透NAT）
const pc = new RTCPeerConnection({
  iceServers: [{ urls: 'stun:stun.l.google.com:19302' }]
});

// 2. 创建DataChannel用于传输文件二进制数据
const dataChannel = pc.createDataChannel('fileTransfer', {
  ordered: true, // 保证数据包顺序，文件传输必须
  maxRetransmits: 30 // 增加重传次数，提升弱网可靠性
});

// 3. 处理DataChannel事件
dataChannel.onopen = () => {
  console.log('数据通道已打开，开始传输');
  sendFileInChunks(file); // 将文件分片发送
};
dataChannel.onmessage = (event) => {
  // 接收方：接收数据块并重组
  receiveFileChunk(event.data);
};

// 4. 文件分片发送函数（发送方）
function sendFileInChunks(file) {
  const chunkSize = 16 * 1024; // 16KB 一个分片，平衡效率和实时性
  const totalChunks = Math.ceil(file.size / chunkSize);
  let offset = 0;

  function sendNextChunk() {
    if (offset >= file.size) {
      dataChannel.send(JSON.stringify({ type: 'EOF' }));
      return;
    }
    const chunk = file.slice(offset, offset + chunkSize);
    const reader = new FileReader();
    reader.onload = (e) => {
      // 发送分片数据，可以附加序号用于重组
      dataChannel.send(JSON.stringify({
        type: 'chunk',
        index: offset / chunkSize,
        total: totalChunks,
        data: e.target.result
      }));
      offset += chunkSize;
      updateProgress(offset / file.size);
      // 使用setTimeout控制发送节奏，避免阻塞
      setTimeout(sendNextChunk, 0);
    };
    reader.readAsArrayBuffer(chunk);
  }
  sendNextChunk();
}

注意事项与心得 ：

• 分片大小的权衡 ：分片太小（如1KB），协议头开销比例大，效率低；分片太大（如1MB），一个包丢失重传影响大，且 DataChannel 单次发送有大小限制（通常约16KB）。经过测试，16KB-64KB是一个比较理想的区间。
• 传输可靠性 ： RTCDataChannel 默认配置可能不是完全可靠的。对于文件传输，必须将 ordered 设为 true ，并适当增加 maxRetransmits 或设置 maxPacketLifeTime 。对于极端重要的文件，可以在应用层自己实现确认和重传机制。
• 进度显示 ：进度计算不能简单用已发送分片数/总分片数。因为网络缓冲，发送方很快发完，但接收方可能还在接收。更佳实践是接收方每收到一个分片，向发送方回传一个确认，由发送方根据确认数计算进度，或由接收方计算自己的接收进度。
• 大文件内存管理 ：前端不要试图将整个大文件（比如几个G的视频）一次性读入内存。一定要使用 File.slice() 和 FileReader 分片读取。接收方重组时，可以使用 Blob 对象来收集分片，最后通过 URL.createObjectURL() 生成下载链接。

3.2 后端核心：信令服务器与业务逻辑

后端主要承担两个核心职责： 信令中继 和 业务管理 。

1. WebSocket信令服务器实现 ： 信令服务器的代码相对模式化，但关键在于状态的维护。

// 简化的WebSocket处理器
@Component
@ServerEndpoint("/signaling/{sessionId}")
public class SignalingEndpoint {
    private static Map<String, Session> sessions = new ConcurrentHashMap<>();

    @OnOpen
    public void onOpen(Session session, @PathParam("sessionId") String sessionId) {
        sessions.put(sessionId, session);
        // 可以将sessionId与用户绑定
    }

    @OnMessage
    public void onMessage(String message, Session session) {
        // 解析消息，例如：{ "to": "targetSessionId", "type": "offer", "sdp": "..." }
        JsonObject json = JsonParser.parseString(message).getAsJsonObject();
        String targetSessionId = json.get("to").getAsString();
        Session targetSession = sessions.get(targetSessionId);
        if (targetSession != null && targetSession.isOpen()) {
            // 将消息转发给目标客户端
            targetSession.getAsyncRemote().sendText(message);
        }
    }

    @OnClose
    public void onClose(Session session, @PathParam("sessionId") String sessionId) {
        sessions.remove(sessionId);
        // 清理相关资源
    }
}

2. 文件元数据管理与分享链接生成 ： 当P2P传输失败或用户希望生成一个可离线分享的链接时，就需要后端提供传统的“上传-下载”服务。这里的关键是安全与效率。

• 文件存储 ：不建议直接使用数据库存储文件二进制内容（BLOB），这会让数据库急剧膨胀。通常的做法是，文件本身存储在服务器的文件系统或对象存储（如MinIO、阿里云OSS）中，数据库中只存它的元数据（ID、原始文件名、存储路径、大小、MIME类型、上传者、哈希值、过期时间等）。
• 分享链接 ：生成一个唯一的、难以猜测的字符串（如UUID）作为文件访问码。分享链接格式为 https://你的公网域名/download/{fileId}?code=访问码 。后端在提供下载前，需验证访问码和文件是否过期。
• 防止盗链 ：除了访问码，还可以结合一次性Token、Referer检查（简单但可伪造）、IP频率限制等手段。

// 文件上传接口（用于P2P失败后的备用方案）
@PostMapping("/upload")
public ResponseEntity<FileUploadResponse> uploadFile(@RequestParam("file") MultipartFile file,
                                                     @RequestHeader("X-User-Id") String userId) {
    // 1. 检查文件大小、类型
    // 2. 生成唯一文件名（防止冲突）
    String storedFileName = UUID.randomUUID() + "_" + file.getOriginalFilename();
    Path filePath = Paths.get(uploadDir, storedFileName);
    // 3. 保存文件
    Files.copy(file.getInputStream(), filePath, StandardCopyOption.REPLACE_EXISTING);
    // 4. 保存元数据到数据库
    FileMetadata metadata = new FileMetadata();
    metadata.setOriginalName(file.getOriginalFilename());
    metadata.setStoredPath(storedFileName);
    metadata.setSize(file.getSize());
    metadata.setUploaderId(userId);
    metadata.setAccessCode(generateAccessCode()); // 生成8位随机码
    metadata.setExpiresAt(LocalDateTime.now().plusHours(24)); // 24小时后过期
    fileMetadataRepository.save(metadata);
    // 5. 返回包含访问码的响应
    return ResponseEntity.ok(new FileUploadResponse(metadata.getId(), metadata.getAccessCode()));
}

3.3 Docker化部署：从开发到生产

将Spring Boot应用Docker化是保证环境一致性的关键。 Dockerfile 的编写有很多优化点。

# 使用多阶段构建，减小最终镜像体积
# 第一阶段：构建
FROM maven:3.8-eclipse-temurin-17 AS builder
WORKDIR /app
COPY pom.xml .
# 利用层缓存，先下载依赖
RUN mvn dependency:go-offline -B
COPY src ./src
RUN mvn clean package -DskipTests

# 第二阶段：运行
FROM eclipse-temurin:17-jre-alpine
WORKDIR /app
# 创建非root用户运行，增强安全
RUN addgroup -S spring && adduser -S spring -G spring
USER spring:spring
# 从构建阶段拷贝jar包
COPY --from=builder /app/target/*.jar app.jar
# 暴露端口
EXPOSE 8080
# 使用环境变量定义JVM参数，便于调整
ENV JAVA_OPTS="-Xmx512m -Xms256m"
ENTRYPOINT ["sh", "-c", "java $JAVA_OPTS -jar /app/app.jar"]

更进一步的 docker-compose.yml ，可以集成数据库和反向代理：

version: '3.8'
services:
  app:
    build: .
    container_name: instant-transfer-app
    ports:
      - "8080:8080"
    environment:
      - SPRING_DATASOURCE_URL=jdbc:postgresql://db:5432/transferdb
      - SPRING_DATASOURCE_USERNAME=admin
      - SPRING_DATASOURCE_PASSWORD=your_secure_password
    depends_on:
      - db
    volumes:
      - ./uploads:/app/uploads # 挂载上传目录，数据持久化
    networks:
      - app-network

  db:
    image: postgres:15-alpine
    container_name: instant-transfer-db
    environment:
      - POSTGRES_DB=transferdb
      - POSTGRES_USER=admin
      - POSTGRES_PASSWORD=your_secure_password
    volumes:
      - postgres_data:/var/lib/postgresql/data
    networks:
      - app-network

  nginx:
    image: nginx:alpine
    container_name: instant-transfer-nginx
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - ./nginx.conf:/etc/nginx/nginx.conf:ro
      - ./ssl:/etc/nginx/ssl:ro # SSL证书目录
    depends_on:
      - app
    networks:
      - app-network

volumes:
  postgres_data:

networks:
  app-network:
    driver: bridge

部署心得 ：

• 镜像体积 ：使用Alpine Linux基础镜像和JRE（而不是JDK），结合多阶段构建，能将一个Spring Boot应用的镜像从500MB+轻松压缩到150MB以内，上传和部署速度飞快。
• 配置外化 ：所有可能变动的配置（数据库连接、文件存储路径、过期时间）都应通过环境变量或配置文件注入，而不是硬编码在镜像里。Spring Boot的 @ConfigurationProperties 和Docker的 environment 指令是绝配。
• 数据持久化 ：务必通过 volumes 将数据库数据、上传的文件目录挂载到宿主机，否则容器重启后数据就丢失了。
• 健康检查 ：可以在 docker-compose.yml 中为 app 服务添加 healthcheck 指令，让编排工具能感知应用状态。

4. 开发历程中WorkBuddy的实战应用

在整个项目中，WorkBuddy（或其他同类AI编程助手）绝不仅仅是“更智能的代码补全”。它在我不同的开发阶段，扮演了不同的角色。

1. 探索与学习阶段（HTML/JS原型期） ：

• 场景 ：“WebRTC的DataChannel怎么发送二进制文件？”
• 提问 ：我不会直接问“怎么写文件传输”，而是拆解成更具体的问题。我会问WorkBuddy：“给出一个JavaScript示例，使用FileReader将本地文件分片，并通过RTCDataChannel发送每个分片。”
• 收获 ：它给出的代码通常包含了 File.slice() 、 FileReader.onload 、 dataChannel.send() 等关键环节，我就能快速理解流程，并在此基础上调试和优化（比如添加分片序号、进度回调）。

2. 设计与架构阶段（Spring Boot升级期） ：

• 场景 ：“我想用Spring Boot WebSocket做信令服务器，客户端如何与其交互？”
• 提问 ：我会提供上下文：“我有一个Spring Boot 3.x应用，需要创建一个WebSocket端点，路径是 /signaling ，客户端连接时会传递一个 userId 参数。请给出服务端 @ServerEndpoint 配置的示例，并展示如何向特定用户发送消息。”
• 收获 ：WorkBuddy不仅能生成注解配置和基础方法，还会提醒我注意 ConcurrentHashMap 存储会话、线程安全、以及 @Autowired 在端点类中的特殊处理方式（需要 @Component 且通过静态方法注入）。这帮我规避了初期的设计坑。

3. 实现与调试阶段（业务逻辑编码期） ：

• 场景 ：“Spring Boot中如何优雅地处理全局异常，并返回统一的JSON格式？”
• 提问 ：我会要求更具体的风格：“使用 @ControllerAdvice 和 @ExceptionHandler ，定义一个通用的 ApiResponse 包装类，对业务异常返回 code 和 message ，对系统异常记录日志并返回模糊信息。”
• 收获 ：它生成的代码结构清晰，包含了自定义业务异常类、全局异常处理器、以及响应体封装。我稍作修改（比如添加更详细的日志记录）就能集成到项目中，大大提升了开发效率和代码规范性。

4. 部署与运维阶段（Docker化期） ：

• 场景 ：“如何编写一个高效的Dockerfile来构建Spring Boot应用？”
• 提问 ：我会明确约束：“使用多阶段构建，基于 eclipse-temurin:17-jre-alpine 作为运行镜像，以非root用户运行，并通过环境变量 JAVA_OPTS 传递JVM参数。”
• 收获 ：WorkBuddy给出的 Dockerfile 模板通常是最佳实践的集合，我无需再自己搜索和拼凑。它还会解释每一层指令的作用（比如 RUN adduser 是为了安全），让我知其所以然。

使用技巧 ：

• 问题要具体 ：越具体的问题，得到的答案越有针对性。不要问“怎么做文件上传”，而是问“在Spring Boot中，如何用 MultipartFile 接收文件，并保存到 /var/uploads 目录，同时记录元信息到MySQL？”
• 要求解释 ：在它生成代码后，可以追问“为什么这里要用 @Async ？”或者“这种做法的潜在缺点是什么？”，这能帮助你更深入地理解。
• 结合官方文档 ：WorkBuddy的答案有时可能基于稍旧的版本或通用模式。对于关键配置（如Spring Security、WebSocket），一定要与官方文档进行交叉验证。

5. 遇到的典型问题与排查实录

在开发“瞬传”的过程中，踩坑是必然的。以下是几个记忆犹新的问题及其解决方案。

问题一：WebRTC连接失败，一直停留在 checking 状态。

• 现象 ：前端日志显示 RTCPeerConnection 的 iceConnectionState 卡在 checking ，无法变为 connected 。
• 排查 ：
  1. 首先检查信令服务器，确认SDP（Offer/Answer）和ICE候选（ICE Candidate）在两个客户端之间正确交换。
  2. 检查STUN服务器配置。免费的公共STUN服务器（如Google的）有时不稳定。可以尝试更换或添加多个： { urls: ['stun:stun1.l.google.com:19302', 'stun:stun2.l.google.com:19302'] } 。
  3. 如果双方都在复杂的公司网络或对称型NAT后，STUN可能失效，此时需要TURN服务器进行中继。这是最复杂的情况。
• 解决 ：对于内网使用，可以暂时忽略。对于公网，我部署了一个简单的Coturn服务器作为TURN中继，并在创建 RTCPeerConnection 时配置进去。代码中需要同时处理 onicecandidate 事件，将收集到的候选信息通过信令服务器转发。
• 心得 ：WebRTC的NAT穿透不是100%成功的。一个健壮的产品必须要有“降级方案”。我的策略是：优先尝试P2P直连（通过STUN），如果超过10秒未成功，则自动切换到通过后端服务器中转的模式（即传统的上传/下载）。虽然速度可能慢点，但保证了功能的可用性。

问题二：大文件传输时，浏览器内存占用飙升，甚至崩溃。

• 现象 ：传输一个2GB的视频文件，发送方浏览器标签页内存占用超过几个G，然后崩溃。
• 排查 ：审查发送方代码，发现最初为了“简单”，在 FileReader 的 onload 事件中，试图将所有分片先收集到一个大数组里，等全部读完再一次性发送。这导致整个文件被完整地加载到了内存中。
• 解决 ：彻底改为流式处理。如3.1节代码所示，使用递归或循环，一次只读取一个分片（如16KB），发送出去后，立即释放对该分片的引用，再读取下一个。这样内存中最多只保留一个分片的数据。
• 心得 ：前端处理大文件的核心原则是“分而治之”和“流式处理”。任何时候都不要用 FileReader.readAsDataURL 或试图把整个 File 对象转换成 ArrayBuffer 放在内存里。 File.slice() 和 Blob 是你的好朋友。

问题三：Docker容器内应用无法写入挂载的卷。

• 现象 ：Spring Boot应用在Docker容器中运行，上传文件时抛出 Permission denied 异常。
• 排查 ：宿主机上的 uploads 目录权限是 755 ，属主是当前用户（如 ubuntu ）。但Docker容器内的进程默认以 root 用户运行，或者以随机的高位用户ID运行，与宿主机用户ID不匹配，导致没有写入权限。
• 解决 ：
  1. （推荐）在Dockerfile中指定非root用户 ：如前面 Dockerfile 所示，创建 spring 用户并 USER spring:spring 。同时，确保宿主机挂载目录对该用户ID（或组ID）有写权限。可以通过 ls -ln 查看目录的UID/GID，在Dockerfile中用 -u 参数指定相同的UID。
  2. （临时）修改宿主机目录权限 ： chmod 777 ./uploads （ 不安全，仅用于测试 ）。
  3. （高级）使用命名卷并管理权限 ：Docker命名卷由Docker管理，可以避免一些权限问题。
• 心得 ：Docker的权限问题是经典坑。最佳实践是：容器内应用使用非root用户运行，并通过 -u 参数或精心设计的用户组，与宿主机目录的权限对齐。安全与功能需要兼顾。

问题四：公网访问时，混合内容（HTTP/HTTPS）阻塞。

• 现象 ：在公网用HTTPS访问站点，但WebSocket连接（ ws:// ）失败，浏览器控制台报混合内容错误。
• 排查 ：现代浏览器出于安全考虑，会阻止HTTPS页面加载非安全的HTTP资源（包括WebSocket）。我的Nginx配置了SSL，但应用内部的WebSocket端点还在用 ws:// 。
• 解决 ：将WebSocket也升级为安全的 wss:// 。
  1. 在Spring Boot中，如果使用内嵌容器，当应用以HTTPS方式运行时，WebSocket会自动支持 wss 。
  2. 更常见的做法是，在Nginx反向代理处统一处理SSL，并将 wss 连接代理到后端的 ws 服务。

  # nginx.conf 片段
  location /signaling {
      proxy_pass http://app:8080/signaling; # 代理到后端应用
      proxy_http_version 1.1;
      proxy_set_header Upgrade $http_upgrade;
      proxy_set_header Connection "upgrade";
      proxy_set_header Host $host;
      proxy_set_header X-Real-IP $remote_addr;
      # 重要：设置较长的超时时间，因为WebSocket是长连接
      proxy_read_timeout 3600s;
      proxy_send_timeout 3600s;
  }
  

  前端连接时，URL应写为 wss://你的域名/signaling 。
• 心得 ：公网部署一定要考虑全站HTTPS。这不仅关乎安全，也是很多现代浏览器API（如Service Worker、部分WebRTC功能）的前置要求。反向代理（如Nginx）是处理SSL终止和协议转发的标准组件。

6. 性能优化与安全考量

一个可用的工具和一个好用的工具之间，差的就是细节的打磨。

性能优化点 ：

1. 前端传输优化 ：

   • 压缩 ：在传输前，可以使用 pako 等库对文本类文件（如JSON、代码）进行gzip压缩，减少传输量。
   • 并发控制 ：虽然 DataChannel 本身有序，但可以同时创建多个 DataChannel 传输同一个文件的不同部分，理论上能提升吞吐量，但复杂度剧增，需谨慎评估。
   • 本地存储缓存 ：对于重复传输的文件，可以利用 IndexedDB 在本地缓存文件哈希和分片信息，实现“秒传”效果。

2. 后端优化 ：

   • 异步处理 ：文件上传、删除等IO密集型操作，使用 @Async 或消息队列（如RabbitMQ）异步处理，避免阻塞HTTP线程。
   • 连接池 ：确保数据库连接池（如HikariCP）配置合理，监控连接数。
   • 静态资源缓存 ：对于前端页面、JS、CSS等，配置Nginx的强缓存（ Cache-Control: max-age=31536000 ）。

安全加固措施 ：

1. 输入验证与过滤 ：
   • 对用户上传的文件名进行严格过滤，防止路径遍历攻击（如 ../../../etc/passwd ）。可以统一重命名为UUID。
   • 检查文件MIME类型和后缀，防止上传可执行脚本。
   • 对文件内容进行病毒扫描（可集成ClamAV等）。
2. 访问控制 ：
   • 分享链接的访问码必须足够随机且有时效性。
   • 提供“阅后即焚”功能：文件下载一次后自动删除或使链接失效。
   • 实现简单的速率限制（Rate Limiting），防止链接被暴力枚举。
3. 资源隔离 ：
   • 使用Docker的资源限制（ cpus , memory ）防止单个容器耗尽主机资源。
   • 将上传文件存储在容器外的独立目录，并通过Nginx等直接提供下载，减轻应用服务器压力。
4. 日志与审计 ：
   • 记录所有文件上传、下载、删除操作，包括操作者、时间、IP、文件ID。便于事后追溯。

从最初那个为了解决“传文件”痛点的简单HTML页面，到如今这个能跑在公网、支持P2P与中转混合模式、拥有基础管理功能的“瞬传”服务，这个项目带给我的远不止一个工具。它是一次完整的技术栈串联实践，让我对从前端协议到后端架构，再到部署运维的整个链条有了更感性的认识。而像WorkBuddy这样的AI助手，在整个过程中就像一位不知疲倦的副驾，它能快速帮你查地图（找API）、提醒你交规（最佳实践）、甚至在你困顿时提供几条新路线（解决方案），但最终的方向盘和目的地，始终掌握在你自己手里。技术的价值，终究在于解决真实世界的问题。下次再遇到同事问我要文件，我只需要发给他一个“瞬传”的链接。